CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48910 – net: ipv6: ensure we call ipv6_mc_down() at most once
https://notcve.org/view.php?id=CVE-2022-48910
In the Linux kernel, the following vulnerability has been resolved: net: ipv6: ensure we call ipv6_mc_down() at most once There are two reasons for addrconf_notify() to be called with NETDEV_DOWN: either the network device is actually going down, or IPv6 was disabled on the interface. If either of them stays down while the other is toggled, we repeatedly call the code for NETDEV_DOWN, including ipv6_mc_down(), while never calling the corresponding ipv6_mc_up() in between. This will cause a new entry in idev->mc_tomb to be allocated for each multicast group the interface is subscribed to, which in turn leaks one struct ifmcaddr6 per nontrivial multicast group the interface is subscribed to. The following reproducer will leak at least $n objects: ip addr add ff2e::4242/32 dev eth0 autojoin sysctl -w net.ipv6.conf.eth0.disable_ipv6=1 for i in $(seq 1 $n); do ip link set up eth0; ip link set down eth0 done Joining groups with IPV6_ADD_MEMBERSHIP (unprivileged) or setting the sysctl net.ipv6.conf.eth0.forwarding to 1 (=> subscribing to ff02::2) can also be used to create a nontrivial idev->mc_list, which will the leak objects with the right up-down-sequence. Based on both sources for NETDEV_DOWN events the interface IPv6 state should be considered: - not ready if the network interface is not ready OR IPv6 is disabled for it - ready if the network interface is ready AND IPv6 is enabled for it The functions ipv6_mc_up() and ipv6_down() should only be run when this state changes. Implement this by remembering when the IPv6 state is ready, and only run ipv6_mc_down() if it actually changed from ready to not ready. The other direction (not ready -> ready) already works correctly, as: - the interface notification triggered codepath for NETDEV_UP / NETDEV_CHANGE returns early if ipv6 is disabled, and - the disable_ipv6=0 triggered codepath skips fully initializing the interface as long as addrconf_link_ready(dev) returns false - calling ipv6_mc_up() repeatedly does not leak anything • https://git.kernel.org/stable/c/3ce62a84d53cd3d3cc5377bbf339e9b08ddf9c36 https://git.kernel.org/stable/c/9a8736b2da28b24f01707f592ff059b9f90a058c https://git.kernel.org/stable/c/c71bf3229f9e9dd60ba02f5a5be02066edf57012 https://git.kernel.org/stable/c/24888915364cfa410de62d8abb5df95c3b67455d https://git.kernel.org/stable/c/9588ac2eddc2f223ebcebf6e9f5caed84d32922b https://git.kernel.org/stable/c/f4c63b24dea9cc2043ff845dcca9aaf8109ea38a https://git.kernel.org/stable/c/b11781515208dd31fbcd0b664078dce5dc44523f https://git.kernel.org/stable/c/72124e65a70b84e6303a5cd21b0ac1f27 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48909 – net/smc: fix connection leak
https://notcve.org/view.php?id=CVE-2022-48909
In the Linux kernel, the following vulnerability has been resolved: net/smc: fix connection leak There's a potential leak issue under following execution sequence : smc_release smc_connect_work if (sk->sk_state == SMC_INIT) send_clc_confirim tcp_abort(); ... sk.sk_state = SMC_ACTIVE smc_close_active switch(sk->sk_state) { ... case SMC_ACTIVE: smc_close_final() // then wait peer closed Unfortunately, tcp_abort() may discard CLC CONFIRM messages that are still in the tcp send buffer, in which case our connection token cannot be delivered to the server side, which means that we cannot get a passive close message at all. Therefore, it is impossible for the to be disconnected at all. This patch tries a very simple way to avoid this issue, once the state has changed to SMC_ACTIVE after tcp_abort(), we can actively abort the smc connection, considering that the state is SMC_INIT before tcp_abort(), abandoning the complete disconnection process should not cause too much problem. In fact, this problem may exist as long as the CLC CONFIRM message is not received by the server. Whether a timer should be added after smc_close_final() needs to be discussed in the future. But even so, this patch provides a faster release for connection in above case, it should also be valuable. • https://git.kernel.org/stable/c/39f41f367b08650e9aa314e3a13fb6dda1e9eec7 https://git.kernel.org/stable/c/2e8d465b83db307f04ad265848f8ab3f78f6918f https://git.kernel.org/stable/c/80895b6f9154fb22d36fab311ccbb75503a2c87b https://git.kernel.org/stable/c/e98d46ccfa84b35a9e4b1ccdd83961b41a5d7ce5 https://git.kernel.org/stable/c/9f1c50cf39167ff71dc5953a3234f3f6eeb8fcb5 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48908 – net: arcnet: com20020: Fix null-ptr-deref in com20020pci_probe()
https://notcve.org/view.php?id=CVE-2022-48908
In the Linux kernel, the following vulnerability has been resolved: net: arcnet: com20020: Fix null-ptr-deref in com20020pci_probe() During driver initialization, the pointer of card info, i.e. the variable 'ci' is required. However, the definition of 'com20020pci_id_table' reveals that this field is empty for some devices, which will cause null pointer dereference when initializing these devices. The following log reveals it: [ 3.973806] KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] [ 3.973819] RIP: 0010:com20020pci_probe+0x18d/0x13e0 [com20020_pci] [ 3.975181] Call Trace: [ 3.976208] local_pci_probe+0x13f/0x210 [ 3.977248] pci_device_probe+0x34c/0x6d0 [ 3.977255] ? pci_uevent+0x470/0x470 [ 3.978265] really_probe+0x24c/0x8d0 [ 3.978273] __driver_probe_device+0x1b3/0x280 [ 3.979288] driver_probe_device+0x50/0x370 Fix this by checking whether the 'ci' is a null pointer first. • https://git.kernel.org/stable/c/8c14f9c70327a6fb75534c4c61d7ea9c82ccf78f https://git.kernel.org/stable/c/8e3bc7c5bbf87e86e9cd652ca2a9166942d86206 https://git.kernel.org/stable/c/b1ee6b9340a38bdb9e5c90f0eac5b22b122c3049 https://git.kernel.org/stable/c/b838add93e1dd98210482dc433768daaf752bdef https://git.kernel.org/stable/c/e50c589678e50f8d574612e473ca60ef45190896 https://git.kernel.org/stable/c/5f394102ee27dbf051a4e283390cd8d1759dacea https://git.kernel.org/stable/c/ea372aab54903310756217d81610901a8e66cb7d https://git.kernel.org/stable/c/ca0bdff4249a644f2ca7a49d410d95b8d •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48907 – auxdisplay: lcd2s: Fix memory leak in ->remove()
https://notcve.org/view.php?id=CVE-2022-48907
In the Linux kernel, the following vulnerability has been resolved: auxdisplay: lcd2s: Fix memory leak in ->remove() Once allocated the struct lcd2s_data is never freed. Fix the memory leak by switching to devm_kzalloc(). • https://git.kernel.org/stable/c/8c9108d014c5bd0f0da2e3544eb45dc56a6da92b https://git.kernel.org/stable/c/5d53cd33f4253aa4cf02bf7e670b3c6a99674351 https://git.kernel.org/stable/c/3585ed5f9b11a6094dd991d76a1541e5d03b986a https://git.kernel.org/stable/c/898c0a15425a5bcaa8d44bd436eae5afd2483796 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48906 – mptcp: Correctly set DATA_FIN timeout when number of retransmits is large
https://notcve.org/view.php?id=CVE-2022-48906
In the Linux kernel, the following vulnerability has been resolved: mptcp: Correctly set DATA_FIN timeout when number of retransmits is large Syzkaller with UBSAN uncovered a scenario where a large number of DATA_FIN retransmits caused a shift-out-of-bounds in the DATA_FIN timeout calculation: ================================================================================ UBSAN: shift-out-of-bounds in net/mptcp/protocol.c:470:29 shift exponent 32 is too large for 32-bit type 'unsigned int' CPU: 1 PID: 13059 Comm: kworker/1:0 Not tainted 5.17.0-rc2-00630-g5fbf21c90c60 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Workqueue: events mptcp_worker Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 ubsan_epilogue+0xb/0x5a lib/ubsan.c:151 __ubsan_handle_shift_out_of_bounds.cold+0xb2/0x20e lib/ubsan.c:330 mptcp_set_datafin_timeout net/mptcp/protocol.c:470 [inline] __mptcp_retrans.cold+0x72/0x77 net/mptcp/protocol.c:2445 mptcp_worker+0x58a/0xa70 net/mptcp/protocol.c:2528 process_one_work+0x9df/0x16d0 kernel/workqueue.c:2307 worker_thread+0x95/0xe10 kernel/workqueue.c:2454 kthread+0x2f4/0x3b0 kernel/kthread.c:377 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 </TASK> ================================================================================ This change limits the maximum timeout by limiting the size of the shift, which keeps all intermediate values in-bounds. • https://git.kernel.org/stable/c/6477dd39e62c3a67cfa368ddc127410b4ae424c6 https://git.kernel.org/stable/c/0af76111c2a6326e4bb56f64a6e453c6ec6dd2da https://git.kernel.org/stable/c/0c3f34beb459753f9f80d0cc14c1b50ab615c631 https://git.kernel.org/stable/c/03ae283bd71f761feae3f402668d698b393b0e79 https://git.kernel.org/stable/c/877d11f0332cd2160e19e3313e262754c321fa36 •