1. 03 Nov, 2022 5 commits
  2. 02 Nov, 2022 24 commits
    • Luiz Augusto von Dentz's avatar
      Bluetooth: L2CAP: Fix attempting to access uninitialized memory · b1a2cd50
      Luiz Augusto von Dentz authored
      On l2cap_parse_conf_req the variable efs is only initialized if
      remote_efs has been set.
      
      CVE: CVE-2022-42895
      CC: stable@vger.kernel.org
      Reported-by: default avatarTamás Koczka <poprdi@google.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      Reviewed-by: default avatarTedd Ho-Jeong An <tedd.an@intel.com>
      b1a2cd50
    • Luiz Augusto von Dentz's avatar
      Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm · f937b758
      Luiz Augusto von Dentz authored
      l2cap_global_chan_by_psm shall not return fixed channels as they are not
      meant to be connected by (S)PSM.
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      Reviewed-by: default avatarTedd Ho-Jeong An <tedd.an@intel.com>
      f937b758
    • Luiz Augusto von Dentz's avatar
      Bluetooth: L2CAP: Fix accepting connection request for invalid SPSM · 711f8c3f
      Luiz Augusto von Dentz authored
      The Bluetooth spec states that the valid range for SPSM is from
      0x0001-0x00ff so it is invalid to accept values outside of this range:
      
        BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 3, Part A
        page 1059:
        Table 4.15: L2CAP_LE_CREDIT_BASED_CONNECTION_REQ SPSM ranges
      
      CVE: CVE-2022-42896
      CC: stable@vger.kernel.org
      Reported-by: default avatarTamás Koczka <poprdi@google.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      Reviewed-by: default avatarTedd Ho-Jeong An <tedd.an@intel.com>
      711f8c3f
    • Luiz Augusto von Dentz's avatar
      Bluetooth: hci_conn: Fix not restoring ISO buffer count on disconnect · 5638d9ea
      Luiz Augusto von Dentz authored
      When disconnecting an ISO link the controller may not generate
      HCI_EV_NUM_COMP_PKTS for unacked packets which needs to be restored in
      hci_conn_del otherwise the host would assume they are still in use and
      would not be able to use all the buffers available.
      
      Fixes: 26afbd82 ("Bluetooth: Add initial implementation of CIS connections")
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      Tested-by: default avatarFrédéric Danis <frederic.danis@collabora.com>
      5638d9ea
    • Hawkins Jiawei's avatar
      Bluetooth: L2CAP: Fix memory leak in vhci_write · 7c9524d9
      Hawkins Jiawei authored
      Syzkaller reports a memory leak as follows:
      ====================================
      BUG: memory leak
      unreferenced object 0xffff88810d81ac00 (size 240):
        [...]
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<ffffffff838733d9>] __alloc_skb+0x1f9/0x270 net/core/skbuff.c:418
          [<ffffffff833f742f>] alloc_skb include/linux/skbuff.h:1257 [inline]
          [<ffffffff833f742f>] bt_skb_alloc include/net/bluetooth/bluetooth.h:469 [inline]
          [<ffffffff833f742f>] vhci_get_user drivers/bluetooth/hci_vhci.c:391 [inline]
          [<ffffffff833f742f>] vhci_write+0x5f/0x230 drivers/bluetooth/hci_vhci.c:511
          [<ffffffff815e398d>] call_write_iter include/linux/fs.h:2192 [inline]
          [<ffffffff815e398d>] new_sync_write fs/read_write.c:491 [inline]
          [<ffffffff815e398d>] vfs_write+0x42d/0x540 fs/read_write.c:578
          [<ffffffff815e3cdd>] ksys_write+0x9d/0x160 fs/read_write.c:631
          [<ffffffff845e0645>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
          [<ffffffff845e0645>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
          [<ffffffff84600087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
      ====================================
      
      HCI core will uses hci_rx_work() to process frame, which is queued to
      the hdev->rx_q tail in hci_recv_frame() by HCI driver.
      
      Yet the problem is that, HCI core may not free the skb after handling
      ACL data packets. To be more specific, when start fragment does not
      contain the L2CAP length, HCI core just copies skb into conn->rx_skb and
      finishes frame process in l2cap_recv_acldata(), without freeing the skb,
      which triggers the above memory leak.
      
      This patch solves it by releasing the relative skb, after processing
      the above case in l2cap_recv_acldata().
      
      Fixes: 4d7ea8ee ("Bluetooth: L2CAP: Fix handling fragmented length")
      Link: https://lore.kernel.org/all/0000000000000d0b1905e6aaef64@google.com/
      Reported-and-tested-by: syzbot+8f819e36e01022991cfa@syzkaller.appspotmail.com
      Signed-off-by: default avatarHawkins Jiawei <yin31149@gmail.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      7c9524d9
    • Zhengchao Shao's avatar
      Bluetooth: L2CAP: fix use-after-free in l2cap_conn_del() · 0d0e2d03
      Zhengchao Shao authored
      When l2cap_recv_frame() is invoked to receive data, and the cid is
      L2CAP_CID_A2MP, if the channel does not exist, it will create a channel.
      However, after a channel is created, the hold operation of the channel
      is not performed. In this case, the value of channel reference counting
      is 1. As a result, after hci_error_reset() is triggered, l2cap_conn_del()
      invokes the close hook function of A2MP to release the channel. Then
       l2cap_chan_unlock(chan) will trigger UAF issue.
      
      The process is as follows:
      Receive data:
      l2cap_data_channel()
          a2mp_channel_create()  --->channel ref is 2
          l2cap_chan_put()       --->channel ref is 1
      
      Triger event:
          hci_error_reset()
              hci_dev_do_close()
              ...
              l2cap_disconn_cfm()
                  l2cap_conn_del()
                      l2cap_chan_hold()    --->channel ref is 2
                      l2cap_chan_del()     --->channel ref is 1
                      a2mp_chan_close_cb() --->channel ref is 0, release channel
                      l2cap_chan_unlock()  --->UAF of channel
      
      The detailed Call Trace is as follows:
      BUG: KASAN: use-after-free in __mutex_unlock_slowpath+0xa6/0x5e0
      Read of size 8 at addr ffff8880160664b8 by task kworker/u11:1/7593
      Workqueue: hci0 hci_error_reset
      Call Trace:
       <TASK>
       dump_stack_lvl+0xcd/0x134
       print_report.cold+0x2ba/0x719
       kasan_report+0xb1/0x1e0
       kasan_check_range+0x140/0x190
       __mutex_unlock_slowpath+0xa6/0x5e0
       l2cap_conn_del+0x404/0x7b0
       l2cap_disconn_cfm+0x8c/0xc0
       hci_conn_hash_flush+0x11f/0x260
       hci_dev_close_sync+0x5f5/0x11f0
       hci_dev_do_close+0x2d/0x70
       hci_error_reset+0x9e/0x140
       process_one_work+0x98a/0x1620
       worker_thread+0x665/0x1080
       kthread+0x2e4/0x3a0
       ret_from_fork+0x1f/0x30
       </TASK>
      
      Allocated by task 7593:
       kasan_save_stack+0x1e/0x40
       __kasan_kmalloc+0xa9/0xd0
       l2cap_chan_create+0x40/0x930
       amp_mgr_create+0x96/0x990
       a2mp_channel_create+0x7d/0x150
       l2cap_recv_frame+0x51b8/0x9a70
       l2cap_recv_acldata+0xaa3/0xc00
       hci_rx_work+0x702/0x1220
       process_one_work+0x98a/0x1620
       worker_thread+0x665/0x1080
       kthread+0x2e4/0x3a0
       ret_from_fork+0x1f/0x30
      
      Freed by task 7593:
       kasan_save_stack+0x1e/0x40
       kasan_set_track+0x21/0x30
       kasan_set_free_info+0x20/0x30
       ____kasan_slab_free+0x167/0x1c0
       slab_free_freelist_hook+0x89/0x1c0
       kfree+0xe2/0x580
       l2cap_chan_put+0x22a/0x2d0
       l2cap_conn_del+0x3fc/0x7b0
       l2cap_disconn_cfm+0x8c/0xc0
       hci_conn_hash_flush+0x11f/0x260
       hci_dev_close_sync+0x5f5/0x11f0
       hci_dev_do_close+0x2d/0x70
       hci_error_reset+0x9e/0x140
       process_one_work+0x98a/0x1620
       worker_thread+0x665/0x1080
       kthread+0x2e4/0x3a0
       ret_from_fork+0x1f/0x30
      
      Last potentially related work creation:
       kasan_save_stack+0x1e/0x40
       __kasan_record_aux_stack+0xbe/0xd0
       call_rcu+0x99/0x740
       netlink_release+0xe6a/0x1cf0
       __sock_release+0xcd/0x280
       sock_close+0x18/0x20
       __fput+0x27c/0xa90
       task_work_run+0xdd/0x1a0
       exit_to_user_mode_prepare+0x23c/0x250
       syscall_exit_to_user_mode+0x19/0x50
       do_syscall_64+0x42/0x80
       entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      Second to last potentially related work creation:
       kasan_save_stack+0x1e/0x40
       __kasan_record_aux_stack+0xbe/0xd0
       call_rcu+0x99/0x740
       netlink_release+0xe6a/0x1cf0
       __sock_release+0xcd/0x280
       sock_close+0x18/0x20
       __fput+0x27c/0xa90
       task_work_run+0xdd/0x1a0
       exit_to_user_mode_prepare+0x23c/0x250
       syscall_exit_to_user_mode+0x19/0x50
       do_syscall_64+0x42/0x80
       entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      Fixes: d0be8347 ("Bluetooth: L2CAP: Fix use-after-free caused by l2cap_chan_put")
      Signed-off-by: default avatarZhengchao Shao <shaozhengchao@huawei.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      0d0e2d03
    • Soenke Huster's avatar
      Bluetooth: virtio_bt: Use skb_put to set length · 160fbcf3
      Soenke Huster authored
      By using skb_put we ensure that skb->tail is set
      correctly. Currently, skb->tail is always zero, which
      leads to errors, such as the following page fault in
      rfcomm_recv_frame:
      
          BUG: unable to handle page fault for address: ffffed1021de29ff
          #PF: supervisor read access in kernel mode
          #PF: error_code(0x0000) - not-present page
          RIP: 0010:rfcomm_run+0x831/0x4040 (net/bluetooth/rfcomm/core.c:1751)
      
      Fixes: afd2daa2 ("Bluetooth: Add support for virtio transport driver")
      Signed-off-by: default avatarSoenke Huster <soenke.huster@eknoes.de>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      160fbcf3
    • Pauli Virtanen's avatar
      Bluetooth: hci_conn: Fix CIS connection dst_type handling · b36a234d
      Pauli Virtanen authored
      hci_connect_cis and iso_connect_cis call hci_bind_cis inconsistently
      with dst_type being either ISO socket address type or the HCI type, but
      these values cannot be mixed like this. Fix this by using only the HCI
      type.
      
      CIS connection dst_type was also not initialized in hci_bind_cis, even
      though it is used in hci_conn_hash_lookup_cis to find existing
      connections.  Set the value in hci_bind_cis, so that existing CIS
      connections are found e.g. when doing deferred socket connections, also
      when dst_type is not 0 (ADDR_LE_DEV_PUBLIC).
      
      Fixes: 26afbd82 ("Bluetooth: Add initial implementation of CIS connections")
      Signed-off-by: default avatarPauli Virtanen <pav@iki.fi>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      b36a234d
    • Maxim Mikityanskiy's avatar
      Bluetooth: L2CAP: Fix use-after-free caused by l2cap_reassemble_sdu · 3aff8aac
      Maxim Mikityanskiy authored
      Fix the race condition between the following two flows that run in
      parallel:
      
      1. l2cap_reassemble_sdu -> chan->ops->recv (l2cap_sock_recv_cb) ->
         __sock_queue_rcv_skb.
      
      2. bt_sock_recvmsg -> skb_recv_datagram, skb_free_datagram.
      
      An SKB can be queued by the first flow and immediately dequeued and
      freed by the second flow, therefore the callers of l2cap_reassemble_sdu
      can't use the SKB after that function returns. However, some places
      continue accessing struct l2cap_ctrl that resides in the SKB's CB for a
      short time after l2cap_reassemble_sdu returns, leading to a
      use-after-free condition (the stack trace is below, line numbers for
      kernel 5.19.8).
      
      Fix it by keeping a local copy of struct l2cap_ctrl.
      
      BUG: KASAN: use-after-free in l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
      Read of size 1 at addr ffff88812025f2f0 by task kworker/u17:3/43169
      
      Workqueue: hci0 hci_rx_work [bluetooth]
      Call Trace:
       <TASK>
       dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4))
       print_report.cold (mm/kasan/report.c:314 mm/kasan/report.c:429)
       ? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
       kasan_report (mm/kasan/report.c:162 mm/kasan/report.c:493)
       ? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
       l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
       l2cap_rx (net/bluetooth/l2cap_core.c:7236 net/bluetooth/l2cap_core.c:7271) bluetooth
       ret_from_fork (arch/x86/entry/entry_64.S:306)
       </TASK>
      
      Allocated by task 43169:
       kasan_save_stack (mm/kasan/common.c:39)
       __kasan_slab_alloc (mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469)
       kmem_cache_alloc_node (mm/slab.h:750 mm/slub.c:3243 mm/slub.c:3293)
       __alloc_skb (net/core/skbuff.c:414)
       l2cap_recv_frag (./include/net/bluetooth/bluetooth.h:425 net/bluetooth/l2cap_core.c:8329) bluetooth
       l2cap_recv_acldata (net/bluetooth/l2cap_core.c:8442) bluetooth
       hci_rx_work (net/bluetooth/hci_core.c:3642 net/bluetooth/hci_core.c:3832) bluetooth
       process_one_work (kernel/workqueue.c:2289)
       worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2437)
       kthread (kernel/kthread.c:376)
       ret_from_fork (arch/x86/entry/entry_64.S:306)
      
      Freed by task 27920:
       kasan_save_stack (mm/kasan/common.c:39)
       kasan_set_track (mm/kasan/common.c:45)
       kasan_set_free_info (mm/kasan/generic.c:372)
       ____kasan_slab_free (mm/kasan/common.c:368 mm/kasan/common.c:328)
       slab_free_freelist_hook (mm/slub.c:1780)
       kmem_cache_free (mm/slub.c:3536 mm/slub.c:3553)
       skb_free_datagram (./include/net/sock.h:1578 ./include/net/sock.h:1639 net/core/datagram.c:323)
       bt_sock_recvmsg (net/bluetooth/af_bluetooth.c:295) bluetooth
       l2cap_sock_recvmsg (net/bluetooth/l2cap_sock.c:1212) bluetooth
       sock_read_iter (net/socket.c:1087)
       new_sync_read (./include/linux/fs.h:2052 fs/read_write.c:401)
       vfs_read (fs/read_write.c:482)
       ksys_read (fs/read_write.c:620)
       do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
       entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)
      
      Link: https://lore.kernel.org/linux-bluetooth/CAKErNvoqga1WcmoR3-0875esY6TVWFQDandbVZncSiuGPBQXLA@mail.gmail.com/T/#u
      Fixes: d2a7ac5d ("Bluetooth: Add the ERTM receive state machine")
      Fixes: 4b51dae9 ("Bluetooth: Add streaming mode receive and incoming packet classifier")
      Signed-off-by: default avatarMaxim Mikityanskiy <maxtram95@gmail.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      3aff8aac
    • Jozsef Kadlecsik's avatar
      netfilter: ipset: enforce documented limit to prevent allocating huge memory · 510841da
      Jozsef Kadlecsik authored
      Daniel Xu reported that the hash:net,iface type of the ipset subsystem does
      not limit adding the same network with different interfaces to a set, which
      can lead to huge memory usage or allocation failure.
      
      The quick reproducer is
      
      $ ipset create ACL.IN.ALL_PERMIT hash:net,iface hashsize 1048576 timeout 0
      $ for i in $(seq 0 100); do /sbin/ipset add ACL.IN.ALL_PERMIT 0.0.0.0/0,kaf_$i timeout 0 -exist; done
      
      The backtrace when vmalloc fails:
      
              [Tue Oct 25 00:13:08 2022] ipset: vmalloc error: size 1073741848, exceeds total pages
              <...>
              [Tue Oct 25 00:13:08 2022] Call Trace:
              [Tue Oct 25 00:13:08 2022]  <TASK>
              [Tue Oct 25 00:13:08 2022]  dump_stack_lvl+0x48/0x60
              [Tue Oct 25 00:13:08 2022]  warn_alloc+0x155/0x180
              [Tue Oct 25 00:13:08 2022]  __vmalloc_node_range+0x72a/0x760
              [Tue Oct 25 00:13:08 2022]  ? hash_netiface4_add+0x7c0/0xb20
              [Tue Oct 25 00:13:08 2022]  ? __kmalloc_large_node+0x4a/0x90
              [Tue Oct 25 00:13:08 2022]  kvmalloc_node+0xa6/0xd0
              [Tue Oct 25 00:13:08 2022]  ? hash_netiface4_resize+0x99/0x710
              <...>
      
      The fix is to enforce the limit documented in the ipset(8) manpage:
      
      >  The internal restriction of the hash:net,iface set type is that the same
      >  network prefix cannot be stored with more than 64 different interfaces
      >  in a single set.
      
      Fixes: ccf0a4b7 ("netfilter: ipset: Add bucketsize parameter to all hash types")
      Reported-by: default avatarDaniel Xu <dxu@dxuuu.xyz>
      Signed-off-by: default avatarJozsef Kadlecsik <kadlec@netfilter.org>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      510841da
    • David S. Miller's avatar
      Merge branch 'misdn-fixes' · ba9169f5
      David S. Miller authored
      Yang Yingliang says:
      
      ====================
      two fixes for mISDN
      
      This patchset fixes two issues when device_add() returns error.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ba9169f5
    • Yang Yingliang's avatar
      isdn: mISDN: netjet: fix wrong check of device registration · bf00f542
      Yang Yingliang authored
      The class is set in mISDN_register_device(), but if device_add() returns
      error, it will lead to delete a device without added, fix this by using
      device_is_registered() to check if the device is registered.
      
      Fixes: a900845e ("mISDN: Add support for Traverse Technologies NETJet PCI cards")
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bf00f542
    • Yang Yingliang's avatar
      mISDN: fix possible memory leak in mISDN_register_device() · e7d1d4d9
      Yang Yingliang authored
      Afer commit 1fa5ae85 ("driver core: get rid of struct device's
      bus_id string array"), the name of device is allocated dynamically,
      add put_device() to give up the reference, so that the name can be
      freed in kobject_cleanup() when the refcount is 0.
      
      Set device class before put_device() to avoid null release() function
      WARN message in device_release().
      
      Fixes: 1fa5ae85 ("driver core: get rid of struct device's bus_id string array")
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e7d1d4d9
    • Zhang Qilong's avatar
      rose: Fix NULL pointer dereference in rose_send_frame() · e97c089d
      Zhang Qilong authored
      The syzkaller reported an issue:
      
      KASAN: null-ptr-deref in range [0x0000000000000380-0x0000000000000387]
      CPU: 0 PID: 4069 Comm: kworker/0:15 Not tainted 6.0.0-syzkaller-02734-g0326074f #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
      Workqueue: rcu_gp srcu_invoke_callbacks
      RIP: 0010:rose_send_frame+0x1dd/0x2f0 net/rose/rose_link.c:101
      Call Trace:
       <IRQ>
       rose_transmit_clear_request+0x1d5/0x290 net/rose/rose_link.c:255
       rose_rx_call_request+0x4c0/0x1bc0 net/rose/af_rose.c:1009
       rose_loopback_timer+0x19e/0x590 net/rose/rose_loopback.c:111
       call_timer_fn+0x1a0/0x6b0 kernel/time/timer.c:1474
       expire_timers kernel/time/timer.c:1519 [inline]
       __run_timers.part.0+0x674/0xa80 kernel/time/timer.c:1790
       __run_timers kernel/time/timer.c:1768 [inline]
       run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1803
       __do_softirq+0x1d0/0x9c8 kernel/softirq.c:571
       [...]
       </IRQ>
      
      It triggers NULL pointer dereference when 'neigh->dev->dev_addr' is
      called in the rose_send_frame(). It's the first occurrence of the
      `neigh` is in rose_loopback_timer() as `rose_loopback_neigh', and
      the 'dev' in 'rose_loopback_neigh' is initialized sa nullptr.
      
      It had been fixed by commit 3b3fd068
      ("rose: Fix Null pointer dereference in rose_send_frame()") ever.
      But it's introduced by commit 3c53cd65
      ("rose: check NULL rose_loopback_neigh->loopback") again.
      
      We fix it by add NULL check in rose_transmit_clear_request(). When
      the 'dev' in 'neigh' is NULL, we don't reply the request and just
      clear it.
      
      syzkaller don't provide repro, and I provide a syz repro like:
      r0 = syz_init_net_socket$bt_sco(0x1f, 0x5, 0x2)
      ioctl$sock_inet_SIOCSIFFLAGS(r0, 0x8914, &(0x7f0000000180)={'rose0\x00', 0x201})
      r1 = syz_init_net_socket$rose(0xb, 0x5, 0x0)
      bind$rose(r1, &(0x7f00000000c0)=@full={0xb, @dev, @null, 0x0, [@null, @null, @netrom, @netrom, @default, @null]}, 0x40)
      connect$rose(r1, &(0x7f0000000240)=@short={0xb, @dev={0xbb, 0xbb, 0xbb, 0x1, 0x0}, @remote={0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0x1}, 0x1, @netrom={0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0x0, 0x0}}, 0x1c)
      
      Fixes: 3c53cd65 ("rose: check NULL rose_loopback_neigh->loopback")
      Signed-off-by: default avatarZhang Qilong <zhangqilong3@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e97c089d
    • Chen Zhongjin's avatar
      netfilter: nf_nat: Fix possible memory leak in nf_nat_init() · cbc1dd5b
      Chen Zhongjin authored
      In nf_nat_init(), register_nf_nat_bpf() can fail and return directly
      without any error handling.
      Then nf_nat_bysource will leak and registering of &nat_net_ops,
      &follow_master_nat and nf_nat_hook won't be reverted.
      
      This leaves wild ops in linkedlists and when another module tries to
      call register_pernet_operations() or nf_ct_helper_expectfn_register()
      it triggers page fault:
      
       BUG: unable to handle page fault for address: fffffbfff81b964c
       RIP: 0010:register_pernet_operations+0x1b9/0x5f0
       Call Trace:
       <TASK>
        register_pernet_subsys+0x29/0x40
        ebtables_init+0x58/0x1000 [ebtables]
        ...
      
      Fixes: 820dc052 ("net: netfilter: move bpf_ct_set_nat_info kfunc in nf_nat_bpf.c")
      Signed-off-by: default avatarChen Zhongjin <chenzhongjin@huawei.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      cbc1dd5b
    • Zhengchao Shao's avatar
      ipvs: fix WARNING in ip_vs_app_net_cleanup() · 5663ed63
      Zhengchao Shao authored
      During the initialization of ip_vs_app_net_init(), if file ip_vs_app
      fails to be created, the initialization is successful by default.
      Therefore, the ip_vs_app file doesn't be found during the remove in
      ip_vs_app_net_cleanup(). It will cause WRNING.
      
      The following is the stack information:
      name 'ip_vs_app'
      WARNING: CPU: 1 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460
      Modules linked in:
      Workqueue: netns cleanup_net
      RIP: 0010:remove_proc_entry+0x389/0x460
      Call Trace:
      <TASK>
      ops_exit_list+0x125/0x170
      cleanup_net+0x4ea/0xb00
      process_one_work+0x9bf/0x1710
      worker_thread+0x665/0x1080
      kthread+0x2e4/0x3a0
      ret_from_fork+0x1f/0x30
      </TASK>
      
      Fixes: 457c4cbc ("[NET]: Make /proc/net per network namespace")
      Signed-off-by: default avatarZhengchao Shao <shaozhengchao@huawei.com>
      Acked-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      5663ed63
    • Zhengchao Shao's avatar
      ipvs: fix WARNING in __ip_vs_cleanup_batch() · 3d00c6a0
      Zhengchao Shao authored
      During the initialization of ip_vs_conn_net_init(), if file ip_vs_conn
      or ip_vs_conn_sync fails to be created, the initialization is successful
      by default. Therefore, the ip_vs_conn or ip_vs_conn_sync file doesn't
      be found during the remove.
      
      The following is the stack information:
      name 'ip_vs_conn_sync'
      WARNING: CPU: 3 PID: 9 at fs/proc/generic.c:712
      remove_proc_entry+0x389/0x460
      Modules linked in:
      Workqueue: netns cleanup_net
      RIP: 0010:remove_proc_entry+0x389/0x460
      Call Trace:
      <TASK>
      __ip_vs_cleanup_batch+0x7d/0x120
      ops_exit_list+0x125/0x170
      cleanup_net+0x4ea/0xb00
      process_one_work+0x9bf/0x1710
      worker_thread+0x665/0x1080
      kthread+0x2e4/0x3a0
      ret_from_fork+0x1f/0x30
      </TASK>
      
      Fixes: 61b1ab45 ("IPVS: netns, add basic init per netns.")
      Signed-off-by: default avatarZhengchao Shao <shaozhengchao@huawei.com>
      Acked-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      3d00c6a0
    • Jason A. Donenfeld's avatar
      ipvs: use explicitly signed chars · 5c26159c
      Jason A. Donenfeld authored
      The `char` type with no explicit sign is sometimes signed and sometimes
      unsigned. This code will break on platforms such as arm, where char is
      unsigned. So mark it here as explicitly signed, so that the
      todrop_counter decrement and subsequent comparison is correct.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Acked-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      5c26159c
    • Florian Westphal's avatar
      netlink: introduce bigendian integer types · ecaf75ff
      Florian Westphal authored
      Jakub reported that the addition of the "network_byte_order"
      member in struct nla_policy increases size of 32bit platforms.
      
      Instead of scraping the bit from elsewhere Johannes suggested
      to add explicit NLA_BE types instead, so do this here.
      
      NLA_POLICY_MAX_BE() macro is removed again, there is no need
      for it: NLA_POLICY_MAX(NLA_BE.., ..) will do the right thing.
      
      NLA_BE64 can be added later.
      
      Fixes: 08724ef6 ("netlink: introduce NLA_POLICY_MAX_BE")
      Reported-by: default avatarJakub Kicinski <kuba@kernel.org>
      Suggested-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Link: https://lore.kernel.org/r/20221031123407.9158-1-fw@strlen.deSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      ecaf75ff
    • Horatiu Vultur's avatar
      net: lan966x: Fix unmapping of received frames using FDMA · fc57062f
      Horatiu Vultur authored
      When lan966x was receiving a frame, then it was building the skb and
      after that it was calling dma_unmap_single with frame size as the
      length. This actually has 2 issues:
      1. It is using a length to map and a different length to unmap.
      2. When the unmap was happening, the data was sync for cpu but it could
         be that this will overwrite what build_skb was initializing.
      
      The fix for these two problems is to change the order of operations.
      First to sync the frame for cpu, then to build the skb and in the end to
      unmap using the correct size but without sync the frame again for cpu.
      
      Fixes: c8349639 ("net: lan966x: Add FDMA functionality")
      Signed-off-by: default avatarHoratiu Vultur <horatiu.vultur@microchip.com>
      Link: https://lore.kernel.org/r/20221031133421.1283196-1-horatiu.vultur@microchip.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      fc57062f
    • Jakub Kicinski's avatar
      Merge branch 'net-lan966x-fixes-for-when-mtu-is-changed' · 70644f72
      Jakub Kicinski authored
      Horatiu Vultur says:
      
      ====================
      net: lan966x: Fixes for when MTU is changed
      
      There were multiple problems in different parts of the driver when
      the MTU was changed.
      The first problem was that the HW was missing to configure the correct
      value, it was missing ETH_HLEN and ETH_FCS_LEN. The second problem was
      when vlan filtering was enabled/disabled, the MRU was not adjusted
      corretly. While the last issue was that the FDMA was calculated wrongly
      the correct maximum MTU.
      ====================
      
      Link: https://lore.kernel.org/r/20221030213636.1031408-1-horatiu.vultur@microchip.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      70644f72
    • Horatiu Vultur's avatar
      net: lan966x: Fix FDMA when MTU is changed · 872ad758
      Horatiu Vultur authored
      When MTU is changed, FDMA is required to calculate what is the maximum
      size of the frame that it can received. So it can calculate what is the
      page order needed to allocate for the received frames.
      The first problem was that, when the max MTU was calculated it was
      reading the value from dev and not from HW, so in this way it was
      missing L2 header + the FCS.
      The other problem was that once the skb is created using
      __build_skb_around, it would reserve some space for skb_shared_info.
      So if we received a frame which size is at the limit of the page order
      then the creating will failed because it would not have space to put all
      the data.
      
      Fixes: 2ea1cbac ("net: lan966x: Update FDMA to change MTU.")
      Signed-off-by: default avatarHoratiu Vultur <horatiu.vultur@microchip.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      872ad758
    • Horatiu Vultur's avatar
      net: lan966x: Adjust maximum frame size when vlan is enabled/disabled · 25f28bb1
      Horatiu Vultur authored
      When vlan filtering is enabled/disabled, it is required to adjust the
      maximum received frame size that it can received. When vlan filtering is
      enabled, it would all to receive extra 4 bytes, that are the vlan tag.
      So the maximum frame size would be 1522 with a vlan tag. If vlan
      filtering is disabled then the maximum frame size would be 1518
      regardless if there is or not a vlan tag.
      
      Fixes: 6d2c186a ("net: lan966x: Add vlan support.")
      Signed-off-by: default avatarHoratiu Vultur <horatiu.vultur@microchip.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      25f28bb1
    • Horatiu Vultur's avatar
      net: lan966x: Fix the MTU calculation · 486c2922
      Horatiu Vultur authored
      When the MTU was changed, the lan966x didn't take in consideration
      the L2 header and the FCS. So the HW was configured with a smaller
      value than what was desired. Therefore the correct value to configure
      the HW would be new_mtu + ETH_HLEN + ETH_FCS_LEN.
      The vlan tag is not considered here, because at the time when the
      blamed commit was added, there was no vlan filtering support. The
      vlan fix will be part of the next patch.
      
      Fixes: d28d6d2e ("net: lan966x: add port module support")
      Signed-off-by: default avatarHoratiu Vultur <horatiu.vultur@microchip.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      486c2922
  3. 01 Nov, 2022 5 commits
    • Christophe JAILLET's avatar
      sfc: Fix an error handling path in efx_pci_probe() · 6c412da5
      Christophe JAILLET authored
      If an error occurs after the first kzalloc() the corresponding memory
      allocation is never freed.
      
      Add the missing kfree() in the error handling path, as already done in the
      remove() function.
      
      Fixes: 7e773594 ("sfc: Separate efx_nic memory from net_device memory")
      Signed-off-by: default avatarChristophe JAILLET <christophe.jaillet@wanadoo.fr>
      Acked-by: default avatarMartin Habets <habetsm.xilinx@gmail.com>
      Link: https://lore.kernel.org/r/dc114193121c52c8fa3779e49bdd99d4b41344a9.1667077009.git.christophe.jaillet@wanadoo.frSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      6c412da5
    • Pablo Neira Ayuso's avatar
      netfilter: nf_tables: release flow rule object from commit path · 26b5934f
      Pablo Neira Ayuso authored
      No need to postpone this to the commit release path, since no packets
      are walking over this object, this is accessed from control plane only.
      This helped uncovered UAF triggered by races with the netlink notifier.
      
      Fixes: 9dd732e0 ("netfilter: nf_tables: memleak flow rule from commit path")
      Reported-by: syzbot+8f747f62763bc6c32916@syzkaller.appspotmail.com
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      26b5934f
    • Pablo Neira Ayuso's avatar
      netfilter: nf_tables: netlink notifier might race to release objects · d4bc8271
      Pablo Neira Ayuso authored
      commit release path is invoked via call_rcu and it runs lockless to
      release the objects after rcu grace period. The netlink notifier handler
      might win race to remove objects that the transaction context is still
      referencing from the commit release path.
      
      Call rcu_barrier() to ensure pending rcu callbacks run to completion
      if the list of transactions to be destroyed is not empty.
      
      Fixes: 6001a930 ("netfilter: nftables: introduce table ownership")
      Reported-by: syzbot+8f747f62763bc6c32916@syzkaller.appspotmail.com
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      d4bc8271
    • Ziyang Xuan's avatar
      net: tun: fix bugs for oversize packet when napi frags enabled · 363a5328
      Ziyang Xuan authored
      Recently, we got two syzkaller problems because of oversize packet
      when napi frags enabled.
      
      One of the problems is because the first seg size of the iov_iter
      from user space is very big, it is 2147479538 which is bigger than
      the threshold value for bail out early in __alloc_pages(). And
      skb->pfmemalloc is true, __kmalloc_reserve() would use pfmemalloc
      reserves without __GFP_NOWARN flag. Thus we got a warning as following:
      
      ========================================================
      WARNING: CPU: 1 PID: 17965 at mm/page_alloc.c:5295 __alloc_pages+0x1308/0x16c4 mm/page_alloc.c:5295
      ...
      Call trace:
       __alloc_pages+0x1308/0x16c4 mm/page_alloc.c:5295
       __alloc_pages_node include/linux/gfp.h:550 [inline]
       alloc_pages_node include/linux/gfp.h:564 [inline]
       kmalloc_large_node+0x94/0x350 mm/slub.c:4038
       __kmalloc_node_track_caller+0x620/0x8e4 mm/slub.c:4545
       __kmalloc_reserve.constprop.0+0x1e4/0x2b0 net/core/skbuff.c:151
       pskb_expand_head+0x130/0x8b0 net/core/skbuff.c:1654
       __skb_grow include/linux/skbuff.h:2779 [inline]
       tun_napi_alloc_frags+0x144/0x610 drivers/net/tun.c:1477
       tun_get_user+0x31c/0x2010 drivers/net/tun.c:1835
       tun_chr_write_iter+0x98/0x100 drivers/net/tun.c:2036
      
      The other problem is because odd IPv6 packets without NEXTHDR_NONE
      extension header and have big packet length, it is 2127925 which is
      bigger than ETH_MAX_MTU(65535). After ipv6_gso_pull_exthdrs() in
      ipv6_gro_receive(), network_header offset and transport_header offset
      are all bigger than U16_MAX. That would trigger skb->network_header
      and skb->transport_header overflow error, because they are all '__u16'
      type. Eventually, it would affect the value for __skb_push(skb, value),
      and make it be a big value. After __skb_push() in ipv6_gro_receive(),
      skb->data would less than skb->head, an out of bounds memory bug occurred.
      That would trigger the problem as following:
      
      ==================================================================
      BUG: KASAN: use-after-free in eth_type_trans+0x100/0x260
      ...
      Call trace:
       dump_backtrace+0xd8/0x130
       show_stack+0x1c/0x50
       dump_stack_lvl+0x64/0x7c
       print_address_description.constprop.0+0xbc/0x2e8
       print_report+0x100/0x1e4
       kasan_report+0x80/0x120
       __asan_load8+0x78/0xa0
       eth_type_trans+0x100/0x260
       napi_gro_frags+0x164/0x550
       tun_get_user+0xda4/0x1270
       tun_chr_write_iter+0x74/0x130
       do_iter_readv_writev+0x130/0x1ec
       do_iter_write+0xbc/0x1e0
       vfs_writev+0x13c/0x26c
      
      To fix the problems, restrict the packet size less than
      (ETH_MAX_MTU - NET_SKB_PAD - NET_IP_ALIGN) which has considered reserved
      skb space in napi_alloc_skb() because transport_header is an offset from
      skb->head. Add len check in tun_napi_alloc_frags() simply.
      
      Fixes: 90e33d45 ("tun: enable napi_gro_frags() for TUN/TAP driver")
      Signed-off-by: default avatarZiyang Xuan <william.xuanziyang@huawei.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Link: https://lore.kernel.org/r/20221029094101.1653855-1-william.xuanziyang@huawei.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      363a5328
    • Rick Lindsley's avatar
      ibmvnic: change maintainers for vnic driver · e230d36f
      Rick Lindsley authored
      Changed maintainers for vnic driver, since Dany has new responsibilities.
      Also added Nick Child as reviewer.
      Signed-off-by: default avatarRick Lindsley <ricklind@us.ibm.com>
      Link: https://lore.kernel.org/r/20221028203509.4070154-1-ricklind@us.ibm.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      e230d36f
  4. 31 Oct, 2022 2 commits
  5. 30 Oct, 2022 4 commits
    • David S. Miller's avatar
      Merge branch 'nfc-skb-leaks' · 5715a502
      David S. Miller authored
      Shang XiaoJing says:
      
      ====================
      nfc: Fix potential memory leak of skb
      
      There are 6 kinds of send functions can be called by nci_send_frame():
      	virtual_nci_send(),
      	fdp_nci_send(),
      	nxp_nci_send(),
      	s3fwrn5_nci_send(),
      	nfcmrvl_nci_send(),
      	st_nci_send();
      
      1. virtual_nci_send() will memleak the skb, and has been fixed before.
      
      2. fdp_nci_send() won't free the skb no matter whether write() succeed.
      
      3-4. nxp_nci_send() and s3fwrn5_nci_send() will only free the skb when
      write() failed, however write() will not free the skb by itself for when
      succeeds.
      
      5. nfcmrvl_nci_send() will call nfcmrvl_XXX_nci_send(), where some of
      them will free the skb, but nfcmrvl_i2c_nci_send() only free the skb
      when i2c_master_send() return >=0, and memleak will happen when
      i2c_master_send() failed in nfcmrvl_i2c_nci_send().
      
      6. st_nci_send() will queue the skb into other list and finally be
      freed.
      
      Fix the potential memory leak of skb.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5715a502
    • Shang XiaoJing's avatar
      nfc: nfcmrvl: Fix potential memory leak in nfcmrvl_i2c_nci_send() · 93d904a7
      Shang XiaoJing authored
      nfcmrvl_i2c_nci_send() will be called by nfcmrvl_nci_send(), and skb
      should be freed in nfcmrvl_i2c_nci_send(). However, nfcmrvl_nci_send()
      will only free skb when i2c_master_send() return >=0, which means skb
      will memleak when i2c_master_send() failed. Free skb no matter whether
      i2c_master_send() succeeds.
      
      Fixes: b5b3e23e ("NFC: nfcmrvl: add i2c driver")
      Signed-off-by: default avatarShang XiaoJing <shangxiaojing@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      93d904a7
    • Shang XiaoJing's avatar
      nfc: s3fwrn5: Fix potential memory leak in s3fwrn5_nci_send() · 3a146b7e
      Shang XiaoJing authored
      s3fwrn5_nci_send() will call s3fwrn5_i2c_write() or s3fwrn82_uart_write(),
      and free the skb if write() failed. However, even if the write() run
      succeeds, the skb will not be freed in write(). As the result, the skb
      will memleak. s3fwrn5_nci_send() should also free the skb when write()
      succeeds.
      
      Fixes: c04c674f ("nfc: s3fwrn5: Add driver for Samsung S3FWRN5 NFC Chip")
      Signed-off-by: default avatarShang XiaoJing <shangxiaojing@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3a146b7e
    • Shang XiaoJing's avatar
      nfc: nxp-nci: Fix potential memory leak in nxp_nci_send() · 7bf1ed6a
      Shang XiaoJing authored
      nxp_nci_send() will call nxp_nci_i2c_write(), and only free skb when
      nxp_nci_i2c_write() failed. However, even if the nxp_nci_i2c_write()
      run succeeds, the skb will not be freed in nxp_nci_i2c_write(). As the
      result, the skb will memleak. nxp_nci_send() should also free the skb
      when nxp_nci_i2c_write() succeeds.
      
      Fixes: dece4585 ("NFC: nxp-nci: Add support for NXP NCI chips")
      Signed-off-by: default avatarShang XiaoJing <shangxiaojing@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7bf1ed6a