1. 24 May, 2021 7 commits
    • Hayes Wang's avatar
      r8152: check the informaton of the device · 1a44fb38
      Hayes Wang authored
      Verify some fields of the USB descriptor to make sure the driver
      could be used by the device.
      
      Besides, remove the check of endpoint number in rtl8152_probe().
      usb_find_common_endpoints() includes it.
      
      BugLink: https://syzkaller.appspot.com/bug?id=912c9c373656996801b4de61f1e3cb326fe940aa
      Reported-by: syzbot+95afd23673f5dd295c57@syzkaller.appspotmail.com
      Fixes: c2198943 ("r8152: search the configuration of vendor mode")
      Signed-off-by: default avatarHayes Wang <hayeswang@realtek.com>
      Reviewed-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1a44fb38
    • Taehee Yoo's avatar
      sch_dsmark: fix a NULL deref in qdisc_reset() · 9b76eade
      Taehee Yoo authored
      If Qdisc_ops->init() is failed, Qdisc_ops->reset() would be called.
      When dsmark_init(Qdisc_ops->init()) is failed, it possibly doesn't
      initialize dsmark_qdisc_data->q. But dsmark_reset(Qdisc_ops->reset())
      uses dsmark_qdisc_data->q pointer wihtout any null checking.
      So, panic would occur.
      
      Test commands:
          sysctl net.core.default_qdisc=dsmark -w
          ip link add dummy0 type dummy
          ip link add vw0 link dummy0 type virt_wifi
          ip link set vw0 up
      
      Splat looks like:
      KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
      CPU: 3 PID: 684 Comm: ip Not tainted 5.12.0+ #910
      RIP: 0010:qdisc_reset+0x2b/0x680
      Code: 1f 44 00 00 48 b8 00 00 00 00 00 fc ff df 41 57 41 56 41 55 41 54
      55 48 89 fd 48 83 c7 18 53 48 89 fa 48 c1 ea 03 48 83 ec 20 <80> 3c 02
      00 0f 85 09 06 00 00 4c 8b 65 18 0f 1f 44 00 00 65 8b 1d
      RSP: 0018:ffff88800fda6bf8 EFLAGS: 00010282
      RAX: dffffc0000000000 RBX: ffff8880050ed800 RCX: 0000000000000000
      RDX: 0000000000000003 RSI: ffffffff99e34100 RDI: 0000000000000018
      RBP: 0000000000000000 R08: fffffbfff346b553 R09: fffffbfff346b553
      R10: 0000000000000001 R11: fffffbfff346b552 R12: ffffffffc0824940
      R13: ffff888109e83800 R14: 00000000ffffffff R15: ffffffffc08249e0
      FS:  00007f5042287680(0000) GS:ffff888119800000(0000)
      knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 000055ae1f4dbd90 CR3: 0000000006760002 CR4: 00000000003706e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       ? rcu_read_lock_bh_held+0xa0/0xa0
       dsmark_reset+0x3d/0xf0 [sch_dsmark]
       qdisc_reset+0xa9/0x680
       qdisc_destroy+0x84/0x370
       qdisc_create_dflt+0x1fe/0x380
       attach_one_default_qdisc.constprop.41+0xa4/0x180
       dev_activate+0x4d5/0x8c0
       ? __dev_open+0x268/0x390
       __dev_open+0x270/0x390
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9b76eade
    • Aditya Srivastava's avatar
      NFC: nfcmrvl: fix kernel-doc syntax in file headers · 4dd649d1
      Aditya Srivastava authored
      The opening comment mark '/**' is used for highlighting the beginning of
      kernel-doc comments.
      The header for drivers/nfc/nfcmrvl follows this syntax, but the content
      inside does not comply with kernel-doc.
      
      This line was probably not meant for kernel-doc parsing, but is parsed
      due to the presence of kernel-doc like comment syntax(i.e, '/**'), which
      causes unexpected warnings from kernel-doc.
      For e.g., running scripts/kernel-doc -none on drivers/nfc/nfcmrvl/spi.c
      causes warning:
      warning: expecting prototype for Marvell NFC(). Prototype was for SPI_WAIT_HANDSHAKE() instead
      
      Provide a simple fix by replacing such occurrences with general comment
      format, i.e. '/*', to prevent kernel-doc from parsing it.
      Signed-off-by: default avatarAditya Srivastava <yashsri421@gmail.com>
      Acked-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4dd649d1
    • DENG Qingfang's avatar
      net: dsa: mt7530: fix VLAN traffic leaks · 474a2dda
      DENG Qingfang authored
      PCR_MATRIX field was set to all 1's when VLAN filtering is enabled, but
      was not reset when it is disabled, which may cause traffic leaks:
      
      	ip link add br0 type bridge vlan_filtering 1
      	ip link add br1 type bridge vlan_filtering 1
      	ip link set swp0 master br0
      	ip link set swp1 master br1
      	ip link set br0 type bridge vlan_filtering 0
      	ip link set br1 type bridge vlan_filtering 0
      	# traffic in br0 and br1 will start leaking to each other
      
      As port_bridge_{add,del} have set up PCR_MATRIX properly, remove the
      PCR_MATRIX write from mt7530_port_set_vlan_aware.
      
      Fixes: 83163f7d ("net: dsa: mediatek: add VLAN support for MT7530")
      Signed-off-by: default avatarDENG Qingfang <dqfext@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      474a2dda
    • David S. Miller's avatar
      Merge branch 'fq_pie-fixes' · 835744e8
      David S. Miller authored
      Davide Caratti says:
      
      ====================
      two fixes for the fq_pie scheduler
      
      - patch 1/2 restores the possibility to use 65536 flows with fq_pie,
        preserving the fix for an endless loop in the control plane
      - patch 2/2 fixes an OOB access that can be observed in the traffic
        path of fq_pie scheduler, when the classification selects a flow
        beyond the allocated space.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      835744e8
    • Davide Caratti's avatar
      net/sched: fq_pie: fix OOB access in the traffic path · e70f7a11
      Davide Caratti authored
      the following script:
      
        # tc qdisc add dev eth0 handle 0x1 root fq_pie flows 2
        # tc qdisc add dev eth0 clsact
        # tc filter add dev eth0 egress matchall action skbedit priority 0x10002
        # ping 192.0.2.2 -I eth0 -c2 -w1 -q
      
      produces the following splat:
      
       BUG: KASAN: slab-out-of-bounds in fq_pie_qdisc_enqueue+0x1314/0x19d0 [sch_fq_pie]
       Read of size 4 at addr ffff888171306924 by task ping/942
      
       CPU: 3 PID: 942 Comm: ping Not tainted 5.12.0+ #441
       Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014
       Call Trace:
        dump_stack+0x92/0xc1
        print_address_description.constprop.7+0x1a/0x150
        kasan_report.cold.13+0x7f/0x111
        fq_pie_qdisc_enqueue+0x1314/0x19d0 [sch_fq_pie]
        __dev_queue_xmit+0x1034/0x2b10
        ip_finish_output2+0xc62/0x2120
        __ip_finish_output+0x553/0xea0
        ip_output+0x1ca/0x4d0
        ip_send_skb+0x37/0xa0
        raw_sendmsg+0x1c4b/0x2d00
        sock_sendmsg+0xdb/0x110
        __sys_sendto+0x1d7/0x2b0
        __x64_sys_sendto+0xdd/0x1b0
        do_syscall_64+0x3c/0x80
        entry_SYSCALL_64_after_hwframe+0x44/0xae
       RIP: 0033:0x7fe69735c3eb
       Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 75 42 2c 00 41 89 ca 8b 00 85 c0 75 14 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 75 c3 0f 1f 40 00 41 57 4d 89 c7 41 56 41 89
       RSP: 002b:00007fff06d7fb38 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
       RAX: ffffffffffffffda RBX: 000055e961413700 RCX: 00007fe69735c3eb
       RDX: 0000000000000040 RSI: 000055e961413700 RDI: 0000000000000003
       RBP: 0000000000000040 R08: 000055e961410500 R09: 0000000000000010
       R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff06d81260
       R13: 00007fff06d7fb40 R14: 00007fff06d7fc30 R15: 000055e96140f0a0
      
       Allocated by task 917:
        kasan_save_stack+0x19/0x40
        __kasan_kmalloc+0x7f/0xa0
        __kmalloc_node+0x139/0x280
        fq_pie_init+0x555/0x8e8 [sch_fq_pie]
        qdisc_create+0x407/0x11b0
        tc_modify_qdisc+0x3c2/0x17e0
        rtnetlink_rcv_msg+0x346/0x8e0
        netlink_rcv_skb+0x120/0x380
        netlink_unicast+0x439/0x630
        netlink_sendmsg+0x719/0xbf0
        sock_sendmsg+0xe2/0x110
        ____sys_sendmsg+0x5ba/0x890
        ___sys_sendmsg+0xe9/0x160
        __sys_sendmsg+0xd3/0x170
        do_syscall_64+0x3c/0x80
        entry_SYSCALL_64_after_hwframe+0x44/0xae
      
       The buggy address belongs to the object at ffff888171306800
        which belongs to the cache kmalloc-256 of size 256
       The buggy address is located 36 bytes to the right of
        256-byte region [ffff888171306800, ffff888171306900)
       The buggy address belongs to the page:
       page:00000000bcfb624e refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x171306
       head:00000000bcfb624e order:1 compound_mapcount:0
       flags: 0x17ffffc0010200(slab|head|node=0|zone=2|lastcpupid=0x1fffff)
       raw: 0017ffffc0010200 dead000000000100 dead000000000122 ffff888100042b40
       raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
       page dumped because: kasan: bad access detected
      
       Memory state around the buggy address:
        ffff888171306800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        ffff888171306880: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc
       >ffff888171306900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                      ^
        ffff888171306980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
        ffff888171306a00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      
      fix fq_pie traffic path to avoid selecting 'q->flows + q->flows_cnt' as a
      valid flow: it's an address beyond the allocated memory.
      
      Fixes: ec97ecf1 ("net: sched: add Flow Queue PIE packet scheduler")
      CC: stable@vger.kernel.org
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e70f7a11
    • Davide Caratti's avatar
      net/sched: fq_pie: re-factor fix for fq_pie endless loop · 3a62fed2
      Davide Caratti authored
      the patch that fixed an endless loop in_fq_pie_init() was not considering
      that 65535 is a valid class id. The correct bugfix for this infinite loop
      is to change 'idx' to become an u32, like Colin proposed in the past [1].
      
      Fix this as follows:
       - restore 65536 as maximum possible values of 'flows_cnt'
       - use u32 'idx' when iterating on 'q->flows'
       - fix the TDC selftest
      
      This reverts commit bb2f930d.
      
      [1] https://lore.kernel.org/netdev/20210407163808.499027-1-colin.king@canonical.com/
      
      CC: Colin Ian King <colin.king@canonical.com>
      CC: stable@vger.kernel.org
      Fixes: bb2f930d ("net/sched: fix infinite loop in sch_fq_pie")
      Fixes: ec97ecf1 ("net: sched: add Flow Queue PIE packet scheduler")
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3a62fed2
  2. 23 May, 2021 3 commits
  3. 21 May, 2021 8 commits
  4. 20 May, 2021 7 commits
    • David S. Miller's avatar
      Merge branch 'stmmac-fixes' · 5cb4a593
      David S. Miller authored
      Joakim Zhang says:
      
      ====================
      net: fixes for stmmac
      
      Two clock fixes for stmmac driver.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5cb4a593
    • Joakim Zhang's avatar
      net: stmmac: fix system hang if change mac address after interface ifdown · 4691ffb1
      Joakim Zhang authored
      Fix system hang with below sequences:
      ~# ifconfig ethx down
      ~# ifconfig ethx hw ether xx:xx:xx:xx:xx:xx
      
      After ethx down, stmmac all clocks gated off and then register access causes
      system hang.
      
      Fixes: 5ec55823 ("net: stmmac: add clocks management for gmac driver")
      Signed-off-by: default avatarJoakim Zhang <qiangqing.zhang@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4691ffb1
    • Joakim Zhang's avatar
      net: stmmac: correct clocks enabled in stmmac_vlan_rx_kill_vid() · b3dcb312
      Joakim Zhang authored
      This should be a mistake to fix conflicts when removing RFC tag to
      repost the patch.
      
      Fixes: 5ec55823 ("net: stmmac: add clocks management for gmac driver")
      Signed-off-by: default avatarJoakim Zhang <qiangqing.zhang@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b3dcb312
    • Zheyu Ma's avatar
      net/qla3xxx: fix schedule while atomic in ql_sem_spinlock · 13a6f315
      Zheyu Ma authored
      When calling the 'ql_sem_spinlock', the driver has already acquired the
      spin lock, so the driver should not call 'ssleep' in atomic context.
      
      This bug can be fixed by using 'mdelay' instead of 'ssleep'.
      
      The KASAN's log reveals it:
      
      [    3.238124 ] BUG: scheduling while atomic: swapper/0/1/0x00000002
      [    3.238748 ] 2 locks held by swapper/0/1:
      [    3.239151 ]  #0: ffff88810177b240 (&dev->mutex){....}-{3:3}, at:
      __device_driver_lock+0x41/0x60
      [    3.240026 ]  #1: ffff888107c60e28 (&qdev->hw_lock){....}-{2:2}, at:
      ql3xxx_probe+0x2aa/0xea0
      [    3.240873 ] Modules linked in:
      [    3.241187 ] irq event stamp: 460854
      [    3.241541 ] hardirqs last  enabled at (460853): [<ffffffff843051bf>]
      _raw_spin_unlock_irqrestore+0x4f/0x70
      [    3.242245 ] hardirqs last disabled at (460854): [<ffffffff843058ca>]
      _raw_spin_lock_irqsave+0x2a/0x70
      [    3.242245 ] softirqs last  enabled at (446076): [<ffffffff846002e4>]
      __do_softirq+0x2e4/0x4b1
      [    3.242245 ] softirqs last disabled at (446069): [<ffffffff811ba5e0>]
      irq_exit_rcu+0x100/0x110
      [    3.242245 ] Preemption disabled at:
      [    3.242245 ] [<ffffffff828ca5ba>] ql3xxx_probe+0x2aa/0xea0
      [    3.242245 ] Kernel panic - not syncing: scheduling while atomic
      [    3.242245 ] CPU: 2 PID: 1 Comm: swapper/0 Not tainted
      5.13.0-rc1-00145
      -gee7dc339169-dirty #16
      [    3.242245 ] Call Trace:
      [    3.242245 ]  dump_stack+0xba/0xf5
      [    3.242245 ]  ? ql3xxx_probe+0x1f0/0xea0
      [    3.242245 ]  panic+0x15a/0x3f2
      [    3.242245 ]  ? vprintk+0x76/0x150
      [    3.242245 ]  ? ql3xxx_probe+0x2aa/0xea0
      [    3.242245 ]  __schedule_bug+0xae/0xe0
      [    3.242245 ]  __schedule+0x72e/0xa00
      [    3.242245 ]  schedule+0x43/0xf0
      [    3.242245 ]  schedule_timeout+0x28b/0x500
      [    3.242245 ]  ? del_timer_sync+0xf0/0xf0
      [    3.242245 ]  ? msleep+0x2f/0x70
      [    3.242245 ]  msleep+0x59/0x70
      [    3.242245 ]  ql3xxx_probe+0x307/0xea0
      [    3.242245 ]  ? _raw_spin_unlock_irqrestore+0x3a/0x70
      [    3.242245 ]  ? pci_device_remove+0x110/0x110
      [    3.242245 ]  local_pci_probe+0x45/0xa0
      [    3.242245 ]  pci_device_probe+0x12b/0x1d0
      [    3.242245 ]  really_probe+0x2a9/0x610
      [    3.242245 ]  driver_probe_device+0x90/0x1d0
      [    3.242245 ]  ? mutex_lock_nested+0x1b/0x20
      [    3.242245 ]  device_driver_attach+0x68/0x70
      [    3.242245 ]  __driver_attach+0x124/0x1b0
      [    3.242245 ]  ? device_driver_attach+0x70/0x70
      [    3.242245 ]  bus_for_each_dev+0xbb/0x110
      [    3.242245 ]  ? rdinit_setup+0x45/0x45
      [    3.242245 ]  driver_attach+0x27/0x30
      [    3.242245 ]  bus_add_driver+0x1eb/0x2a0
      [    3.242245 ]  driver_register+0xa9/0x180
      [    3.242245 ]  __pci_register_driver+0x82/0x90
      [    3.242245 ]  ? yellowfin_init+0x25/0x25
      [    3.242245 ]  ql3xxx_driver_init+0x23/0x25
      [    3.242245 ]  do_one_initcall+0x7f/0x3d0
      [    3.242245 ]  ? rdinit_setup+0x45/0x45
      [    3.242245 ]  ? rcu_read_lock_sched_held+0x4f/0x80
      [    3.242245 ]  kernel_init_freeable+0x2aa/0x301
      [    3.242245 ]  ? rest_init+0x2c0/0x2c0
      [    3.242245 ]  kernel_init+0x18/0x190
      [    3.242245 ]  ? rest_init+0x2c0/0x2c0
      [    3.242245 ]  ? rest_init+0x2c0/0x2c0
      [    3.242245 ]  ret_from_fork+0x1f/0x30
      [    3.242245 ] Dumping ftrace buffer:
      [    3.242245 ]    (ftrace buffer empty)
      [    3.242245 ] Kernel Offset: disabled
      [    3.242245 ] Rebooting in 1 seconds.
      Reported-by: default avatarZheyu Ma <zheyuma97@gmail.com>
      Signed-off-by: default avatarZheyu Ma <zheyuma97@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      13a6f315
    • Aditya Srivastava's avatar
      net: encx24j600: fix kernel-doc syntax in file headers · 503c599a
      Aditya Srivastava authored
      The opening comment mark '/**' is used for highlighting the beginning of
      kernel-doc comments.
      The header for drivers/net/ethernet/microchip/encx24j600 files follows
      this syntax, but the content inside does not comply with kernel-doc.
      
      This line was probably not meant for kernel-doc parsing, but is parsed
      due to the presence of kernel-doc like comment syntax(i.e, '/**'), which
      causes unexpected warning from kernel-doc.
      For e.g., running scripts/kernel-doc -none
      drivers/net/ethernet/microchip/encx24j600_hw.h emits:
      warning: expecting prototype for h(). Prototype was for _ENCX24J600_HW_H() instead
      
      Provide a simple fix by replacing such occurrences with general comment
      format, i.e. '/*', to prevent kernel-doc from parsing it.
      Signed-off-by: default avatarAditya Srivastava <yashsri421@gmail.com>
      Acked-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      503c599a
    • Jesse Brandeburg's avatar
      ixgbe: fix large MTU request from VF · 63e39d29
      Jesse Brandeburg authored
      Check that the MTU value requested by the VF is in the supported
      range of MTUs before attempting to set the VF large packet enable,
      otherwise reject the request. This also avoids unnecessary
      register updates in the case of the 82599 controller.
      
      Fixes: 872844dd ("ixgbe: Enable jumbo frames support w/ SR-IOV")
      Co-developed-by: default avatarPiotr Skajewski <piotrx.skajewski@intel.com>
      Signed-off-by: default avatarPiotr Skajewski <piotrx.skajewski@intel.com>
      Signed-off-by: default avatarJesse Brandeburg <jesse.brandeburg@intel.com>
      Co-developed-by: default avatarMateusz Palczewski <mateusz.palczewski@intel.com>
      Signed-off-by: default avatarMateusz Palczewski <mateusz.palczewski@intel.com>
      Tested-by: default avatarKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      63e39d29
    • David Matlack's avatar
      selftests: Add .gitignore for nci test suite · 8570e75a
      David Matlack authored
      Building the nci test suite produces a binary, nci_dev, that git then
      tries to track. Add a .gitignore file to tell git to ignore this binary.
      Signed-off-by: default avatarDavid Matlack <dmatlack@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8570e75a
  5. 19 May, 2021 15 commits