1. 08 Sep, 2020 1 commit
    • Eric Dumazet's avatar
      mac802154: tx: fix use-after-free · 0ff4628f
      Eric Dumazet authored
      syzbot reported a bug in ieee802154_tx() [1]
      
      A similar issue in ieee802154_xmit_worker() is also fixed in this patch.
      
      [1]
      BUG: KASAN: use-after-free in ieee802154_tx+0x3d2/0x480 net/mac802154/tx.c:88
      Read of size 4 at addr ffff8880251a8c70 by task syz-executor.3/928
      
      CPU: 0 PID: 928 Comm: syz-executor.3 Not tainted 5.9.0-rc3-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x198/0x1fd lib/dump_stack.c:118
       print_address_description.constprop.0.cold+0xae/0x497 mm/kasan/report.c:383
       __kasan_report mm/kasan/report.c:513 [inline]
       kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530
       ieee802154_tx+0x3d2/0x480 net/mac802154/tx.c:88
       ieee802154_subif_start_xmit+0xbe/0xe4 net/mac802154/tx.c:130
       __netdev_start_xmit include/linux/netdevice.h:4634 [inline]
       netdev_start_xmit include/linux/netdevice.h:4648 [inline]
       dev_direct_xmit+0x4e9/0x6e0 net/core/dev.c:4203
       packet_snd net/packet/af_packet.c:2989 [inline]
       packet_sendmsg+0x2413/0x5290 net/packet/af_packet.c:3014
       sock_sendmsg_nosec net/socket.c:651 [inline]
       sock_sendmsg+0xcf/0x120 net/socket.c:671
       ____sys_sendmsg+0x6e8/0x810 net/socket.c:2353
       ___sys_sendmsg+0xf3/0x170 net/socket.c:2407
       __sys_sendmsg+0xe5/0x1b0 net/socket.c:2440
       do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      RIP: 0033:0x45d5b9
      Code: 5d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 2b b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007fc98e749c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 000000000002ccc0 RCX: 000000000045d5b9
      RDX: 0000000000000000 RSI: 0000000020007780 RDI: 000000000000000b
      RBP: 000000000118d020 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 000000000118cfec
      R13: 00007fff690c720f R14: 00007fc98e74a9c0 R15: 000000000118cfec
      
      Allocated by task 928:
       kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48
       kasan_set_track mm/kasan/common.c:56 [inline]
       __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:461
       slab_post_alloc_hook mm/slab.h:518 [inline]
       slab_alloc_node mm/slab.c:3254 [inline]
       kmem_cache_alloc_node+0x136/0x3e0 mm/slab.c:3574
       __alloc_skb+0x71/0x550 net/core/skbuff.c:198
       alloc_skb include/linux/skbuff.h:1094 [inline]
       alloc_skb_with_frags+0x92/0x570 net/core/skbuff.c:5771
       sock_alloc_send_pskb+0x72a/0x880 net/core/sock.c:2348
       packet_alloc_skb net/packet/af_packet.c:2837 [inline]
       packet_snd net/packet/af_packet.c:2932 [inline]
       packet_sendmsg+0x19fb/0x5290 net/packet/af_packet.c:3014
       sock_sendmsg_nosec net/socket.c:651 [inline]
       sock_sendmsg+0xcf/0x120 net/socket.c:671
       ____sys_sendmsg+0x6e8/0x810 net/socket.c:2353
       ___sys_sendmsg+0xf3/0x170 net/socket.c:2407
       __sys_sendmsg+0xe5/0x1b0 net/socket.c:2440
       do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Freed by task 928:
       kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48
       kasan_set_track+0x1c/0x30 mm/kasan/common.c:56
       kasan_set_free_info+0x1b/0x30 mm/kasan/generic.c:355
       __kasan_slab_free+0xd8/0x120 mm/kasan/common.c:422
       __cache_free mm/slab.c:3418 [inline]
       kmem_cache_free.part.0+0x74/0x1e0 mm/slab.c:3693
       kfree_skbmem+0xef/0x1b0 net/core/skbuff.c:622
       __kfree_skb net/core/skbuff.c:679 [inline]
       consume_skb net/core/skbuff.c:838 [inline]
       consume_skb+0xcf/0x160 net/core/skbuff.c:832
       __dev_kfree_skb_any+0x9c/0xc0 net/core/dev.c:3107
       fakelb_hw_xmit+0x20e/0x2a0 drivers/net/ieee802154/fakelb.c:81
       drv_xmit_async net/mac802154/driver-ops.h:16 [inline]
       ieee802154_tx+0x282/0x480 net/mac802154/tx.c:81
       ieee802154_subif_start_xmit+0xbe/0xe4 net/mac802154/tx.c:130
       __netdev_start_xmit include/linux/netdevice.h:4634 [inline]
       netdev_start_xmit include/linux/netdevice.h:4648 [inline]
       dev_direct_xmit+0x4e9/0x6e0 net/core/dev.c:4203
       packet_snd net/packet/af_packet.c:2989 [inline]
       packet_sendmsg+0x2413/0x5290 net/packet/af_packet.c:3014
       sock_sendmsg_nosec net/socket.c:651 [inline]
       sock_sendmsg+0xcf/0x120 net/socket.c:671
       ____sys_sendmsg+0x6e8/0x810 net/socket.c:2353
       ___sys_sendmsg+0xf3/0x170 net/socket.c:2407
       __sys_sendmsg+0xe5/0x1b0 net/socket.c:2440
       do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      The buggy address belongs to the object at ffff8880251a8c00
       which belongs to the cache skbuff_head_cache of size 224
      The buggy address is located 112 bytes inside of
       224-byte region [ffff8880251a8c00, ffff8880251a8ce0)
      The buggy address belongs to the page:
      page:0000000062b6a4f1 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x251a8
      flags: 0xfffe0000000200(slab)
      raw: 00fffe0000000200 ffffea0000435c88 ffffea00028b6c08 ffff8880a9055d00
      raw: 0000000000000000 ffff8880251a80c0 000000010000000c 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff8880251a8b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff8880251a8b80: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc
      >ffff8880251a8c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                                   ^
       ffff8880251a8c80: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
       ffff8880251a8d00: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb
      
      Fixes: 409c3b0c ("mac802154: tx: move stats tx increment")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Cc: Alexander Aring <alex.aring@gmail.com>
      Cc: Stefan Schmidt <stefan@datenfreihafen.org>
      Cc: linux-wpan@vger.kernel.org
      Link: https://lore.kernel.org/r/20200908104025.4009085-1-edumazet@google.comSigned-off-by: default avatarStefan Schmidt <stefan@datenfreihafen.org>
      0ff4628f
  2. 03 Aug, 2020 1 commit
  3. 21 Jul, 2020 24 commits
  4. 20 Jul, 2020 5 commits
    • Zhang Changzhong's avatar
      net: bcmgenet: fix error returns in bcmgenet_probe() · 24a63fe6
      Zhang Changzhong authored
      The driver forgets to call clk_disable_unprepare() in error path after
      a success calling for clk_prepare_enable().
      
      Fix to goto err_clk_disable if clk_prepare_enable() is successful.
      
      Fixes: 99d55638 ("net: bcmgenet: enable NETIF_F_HIGHDMA flag")
      Signed-off-by: default avatarZhang Changzhong <zhangchangzhong@huawei.com>
      Acked-by: default avatarDoug Berger <opendmb@gmail.com>
      Acked-by: default avatarFlorian fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      24a63fe6
    • Alexander A. Klimov's avatar
      net: ieee802154: adf7242: Replace HTTP links with HTTPS ones · 19dc3654
      Alexander A. Klimov authored
      Rationale:
      Reduces attack surface on kernel devs opening the links for MITM
      as HTTPS traffic is much harder to manipulate.
      
      Deterministic algorithm:
      For each file:
        If not .svg:
          For each line:
            If doesn't contain `\bxmlns\b`:
              For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
      	  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
                  If both the HTTP and HTTPS versions
                  return 200 OK and serve the same content:
                    Replace HTTP with HTTPS.
      Signed-off-by: default avatarAlexander A. Klimov <grandmaster@al2klimov.de>
      Link: https://lore.kernel.org/r/20200719113142.58304-1-grandmaster@al2klimov.deSigned-off-by: default avatarStefan Schmidt <stefan@datenfreihafen.org>
      19dc3654
    • Taehee Yoo's avatar
      bonding: check error value of register_netdevice() immediately · 544f287b
      Taehee Yoo authored
      If register_netdevice() is failed, net_device should not be used
      because variables are uninitialized or freed.
      So, the routine should be stopped immediately.
      But, bond_create() doesn't check return value of register_netdevice()
      immediately. That will result in a panic because of using uninitialized
      or freed memory.
      
      Test commands:
          modprobe netdev-notifier-error-inject
          echo -22 > /sys/kernel/debug/notifier-error-inject/netdev/\
      actions/NETDEV_REGISTER/error
          modprobe bonding max_bonds=3
      
      Splat looks like:
      [  375.028492][  T193] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] SMP DEBUG_PAGEALLOC PTI
      [  375.033207][  T193] CPU: 2 PID: 193 Comm: kworker/2:2 Not tainted 5.8.0-rc4+ #645
      [  375.036068][  T193] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
      [  375.039673][  T193] Workqueue: events linkwatch_event
      [  375.041557][  T193] RIP: 0010:dev_activate+0x4a/0x340
      [  375.043381][  T193] Code: 40 a8 04 0f 85 db 00 00 00 8b 83 08 04 00 00 85 c0 0f 84 0d 01 00 00 31 d2 89 d0 48 8d 04 40 48 c1 e0 07 48 03 83 00 04 00 00 <48> 8b 48 10 f6 41 10 01 75 08 f0 80 a1 a0 01 00 00 fd 48 89 48 08
      [  375.050267][  T193] RSP: 0018:ffff9f8facfcfdd8 EFLAGS: 00010202
      [  375.052410][  T193] RAX: 6b6b6b6b6b6b6b6b RBX: ffff9f8fae6ea000 RCX: 0000000000000006
      [  375.055178][  T193] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9f8fae6ea000
      [  375.057762][  T193] RBP: ffff9f8fae6ea000 R08: 0000000000000000 R09: 0000000000000000
      [  375.059810][  T193] R10: 0000000000000001 R11: 0000000000000000 R12: ffff9f8facfcfe08
      [  375.061892][  T193] R13: ffffffff883587e0 R14: 0000000000000000 R15: ffff9f8fae6ea580
      [  375.063931][  T193] FS:  0000000000000000(0000) GS:ffff9f8fbae00000(0000) knlGS:0000000000000000
      [  375.066239][  T193] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  375.067841][  T193] CR2: 00007f2f542167a0 CR3: 000000012cee6002 CR4: 00000000003606e0
      [  375.069657][  T193] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  375.071471][  T193] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [  375.073269][  T193] Call Trace:
      [  375.074005][  T193]  linkwatch_do_dev+0x4d/0x50
      [  375.075052][  T193]  __linkwatch_run_queue+0x10b/0x200
      [  375.076244][  T193]  linkwatch_event+0x21/0x30
      [  375.077274][  T193]  process_one_work+0x252/0x600
      [  375.078379][  T193]  ? process_one_work+0x600/0x600
      [  375.079518][  T193]  worker_thread+0x3c/0x380
      [  375.080534][  T193]  ? process_one_work+0x600/0x600
      [  375.081668][  T193]  kthread+0x139/0x150
      [  375.082567][  T193]  ? kthread_park+0x90/0x90
      [  375.083567][  T193]  ret_from_fork+0x22/0x30
      
      Fixes: e826eafa ("bonding: Call netif_carrier_off after register_netdevice")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      544f287b
    • Russell King's avatar
      arm64: dts: clearfog-gt-8k: fix switch link configuration · 7c6719a1
      Russell King authored
      The commit below caused a regression for clearfog-gt-8k, where the link
      between the switch and the host does not come up.
      
      Investigation revealed two issues:
      - MV88E6xxx DSA no longer allows an in-band link to come up as the link
        is programmed to be forced down. Commit "net: dsa: mv88e6xxx: fix
        in-band AN link establishment" addresses this.
      
      - The dts configured dissimilar link modes at each end of the host to
        switch link; the host was configured using a fixed link (so has no
        in-band status) and the switch was configured to expect in-band
        status.
      
      With both issues fixed, the regression is resolved.
      
      Fixes: 34b5e6a3 ("net: dsa: mv88e6xxx: Configure MAC when using fixed link")
      Reported-by: default avatarMartin Rowe <martin.p.rowe@gmail.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7c6719a1
    • Russell King's avatar
      net: dsa: mv88e6xxx: fix in-band AN link establishment · fad58190
      Russell King authored
      If in-band negotiation or fixed-link modes are specified for a DSA
      port, the DSA code will force the link down during initialisation. For
      fixed-link mode, this is fine, as phylink will manage the link state.
      However, for in-band mode, phylink expects the PCS to detect link,
      which will not happen if the link is forced down.
      
      There is a related issue that in in-band mode, the link could come up
      while we are making configuration changes, so we should force the link
      down prior to reconfiguring the interface mode.
      
      This patch addresses both issues.
      
      Fixes: 3be98b2d ("net: dsa: Down cpu/dsa ports phylink will control")
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fad58190
  5. 19 Jul, 2020 9 commits