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: 3.3EPSS: 0%CPEs: 6EXPL: 0CVE-2022-48905 – ibmvnic: free reset-work-item when flushing
https://notcve.org/view.php?id=CVE-2022-48905
In the Linux kernel, the following vulnerability has been resolved: ibmvnic: free reset-work-item when flushing Fix a tiny memory leak when flushing the reset work queue. A memory leak flaw was found in the Linux kernel’s IBM Virtual Network Interface Controller (ibmvnic ) driver. This issue involved not properly freeing memory associated with a reset work item when the reset work queue is flushed, causing the reset-work-item not to be deallocated. This flaw allows an attacker with control over the virtual NIC to repeatedly trigger interface resets to cause small amounts of memory to leak. Over time, this can lead to memory exhaustion, especially in systems already resource-constrained or under heavy load, resulting in a possible denial of service (DoS) condition. • https://git.kernel.org/stable/c/2770a7984db588913e11a6dfcfe3461dbba9b7b2 https://git.kernel.org/stable/c/786576c03b313a9ff6585458aa0dfd039d897f51 https://git.kernel.org/stable/c/58b07100c20e95c78b8cb4d6d28ca53eb9ef81f2 https://git.kernel.org/stable/c/6acbc8875282d3ca8a73fa93cd7a9b166de5019c https://git.kernel.org/stable/c/39738a2346b270e8f72f88d8856de2c167bd2899 https://git.kernel.org/stable/c/4c26745e4576cec224092e6cc12e37829333b183 https://git.kernel.org/stable/c/8d0657f39f487d904fca713e0bc39c2707382553 https://access.redhat.com/security/cve/CVE-2022-48905 • CWE-401: Missing Release of Memory after Effective Lifetime •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48902 – btrfs: do not WARN_ON() if we have PageError set
https://notcve.org/view.php?id=CVE-2022-48902
In the Linux kernel, the following vulnerability has been resolved: btrfs: do not WARN_ON() if we have PageError set Whenever we do any extent buffer operations we call assert_eb_page_uptodate() to complain loudly if we're operating on an non-uptodate page. Our overnight tests caught this warning earlier this week WARNING: CPU: 1 PID: 553508 at fs/btrfs/extent_io.c:6849 assert_eb_page_uptodate+0x3f/0x50 CPU: 1 PID: 553508 Comm: kworker/u4:13 Tainted: G W 5.17.0-rc3+ #564 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 Workqueue: btrfs-cache btrfs_work_helper RIP: 0010:assert_eb_page_uptodate+0x3f/0x50 RSP: 0018:ffffa961440a7c68 EFLAGS: 00010246 RAX: 0017ffffc0002112 RBX: ffffe6e74453f9c0 RCX: 0000000000001000 RDX: ffffe6e74467c887 RSI: ffffe6e74453f9c0 RDI: ffff8d4c5efc2fc0 RBP: 0000000000000d56 R08: ffff8d4d4a224000 R09: 0000000000000000 R10: 00015817fa9d1ef0 R11: 000000000000000c R12: 00000000000007b1 R13: ffff8d4c5efc2fc0 R14: 0000000001500000 R15: 0000000001cb1000 FS: 0000000000000000(0000) GS:ffff8d4dbbd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff31d3448d8 CR3: 0000000118be8004 CR4: 0000000000370ee0 Call Trace: extent_buffer_test_bit+0x3f/0x70 free_space_test_bit+0xa6/0xc0 load_free_space_tree+0x1f6/0x470 caching_thread+0x454/0x630 ? rcu_read_lock_sched_held+0x12/0x60 ? rcu_read_lock_sched_held+0x12/0x60 ? rcu_read_lock_sched_held+0x12/0x60 ? • https://git.kernel.org/stable/c/e00077aa439f0e8f416699fa4e9600db6583db70 https://git.kernel.org/stable/c/9efcc83b33b576302147634eca9bece8e3737e34 https://git.kernel.org/stable/c/a50e1fcbc9b85fd4e95b89a75c0884cb032a3e06 •