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: 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 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48901 – btrfs: do not start relocation until in progress drops are done
https://notcve.org/view.php?id=CVE-2022-48901
In the Linux kernel, the following vulnerability has been resolved: btrfs: do not start relocation until in progress drops are done We hit a bug with a recovering relocation on mount for one of our file systems in production. I reproduced this locally by injecting errors into snapshot delete with balance running at the same time. This presented as an error while looking up an extent item WARNING: CPU: 5 PID: 1501 at fs/btrfs/extent-tree.c:866 lookup_inline_extent_backref+0x647/0x680 CPU: 5 PID: 1501 Comm: btrfs-balance Not tainted 5.16.0-rc8+ #8 RIP: 0010:lookup_inline_extent_backref+0x647/0x680 RSP: 0018:ffffae0a023ab960 EFLAGS: 00010202 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000000000 RBP: ffff943fd2a39b60 R08: 0000000000000000 R09: 0000000000000001 R10: 0001434088152de0 R11: 0000000000000000 R12: 0000000001d05000 R13: ffff943fd2a39b60 R14: ffff943fdb96f2a0 R15: ffff9442fc923000 FS: 0000000000000000(0000) GS:ffff944e9eb40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1157b1fca8 CR3: 000000010f092000 CR4: 0000000000350ee0 Call Trace: <TASK> insert_inline_extent_backref+0x46/0xd0 __btrfs_inc_extent_ref.isra.0+0x5f/0x200 ? btrfs_merge_delayed_refs+0x164/0x190 __btrfs_run_delayed_refs+0x561/0xfa0 ? btrfs_search_slot+0x7b4/0xb30 ? • https://git.kernel.org/stable/c/6599d5e8bd758d897fd2ef4dc388ae50278b1f7e https://git.kernel.org/stable/c/5e70bc827b563caf22e1203428cc3719643de5aa https://git.kernel.org/stable/c/b4be6aefa73c9a6899ef3ba9c5faaa8a66e333ef •