1. 30 6月, 2018 1 次提交
  2. 29 6月, 2018 5 次提交
  3. 28 6月, 2018 15 次提交
  4. 27 6月, 2018 16 次提交
  5. 26 6月, 2018 3 次提交
    • J
      netfilter: nf_log: don't hold nf_log_mutex during user access · ce00bf07
      Jann Horn 提交于
      The old code would indefinitely block other users of nf_log_mutex if
      a userspace access in proc_dostring() blocked e.g. due to a userfaultfd
      region. Fix it by moving proc_dostring() out of the locked region.
      
      This is a followup to commit 266d07cb ("netfilter: nf_log: fix
      sleeping function called from invalid context"), which changed this code
      from using rcu_read_lock() to taking nf_log_mutex.
      
      Fixes: 266d07cb ("netfilter: nf_log: fix sleeping function calle[...]")
      Signed-off-by: NJann Horn <jannh@google.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      ce00bf07
    • J
      netfilter: nf_log: fix uninit read in nf_log_proc_dostring · dffd22ae
      Jann Horn 提交于
      When proc_dostring() is called with a non-zero offset in strict mode, it
      doesn't just write to the ->data buffer, it also reads. Make sure it
      doesn't read uninitialized data.
      
      Fixes: c6ac37d8 ("netfilter: nf_log: fix error on write NONE to [...]")
      Signed-off-by: NJann Horn <jannh@google.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      dffd22ae
    • D
      Merge branch 'lan78xx-minor-fixes' · 094bdadd
      David S. Miller 提交于
      Dave Stevenson says:
      
      ====================
      lan78xx minor fixes
      
      This is a small set of patches for the Microchip LAN78xx chip,
      as used in the Raspberry Pi 3B+.
      The main debug/discussion was on
      https://github.com/raspberrypi/linux/issues/2458
      
      Initial symptoms were that VLANs were very unreliable.
      A couple of things were found:
      - firstly that the hardware timeout value set failed to
        take into account the VLAN tag, so a full MTU packet
        would be timed out.
      - second was that regular checksum failures were being
        reported. Disabling checksum offload confirmed that
        the checksums were valid, and further experimentation
        identified that it was only if the VLAN tags were being
        passed through to the kernel that there were issues.
        The hardware supports VLAN filtering and tag stripping,
        therefore those have been implemented (much of the work
        was already done), and the driver drops back to s/w
        checksums should the choice be made not to use the h/w
        VLAN stripping.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      094bdadd