CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48809 – net: fix a memleak when uncloning an skb dst and its metadata
https://notcve.org/view.php?id=CVE-2022-48809
In the Linux kernel, the following vulnerability has been resolved: net: fix a memleak when uncloning an skb dst and its metadata When uncloning an skb dst and its associated metadata, a new dst+metadata is allocated and later replaces the old one in the skb. This is helpful to have a non-shared dst+metadata attached to a specific skb. The issue is the uncloned dst+metadata is initialized with a refcount of 1, which is increased to 2 before attaching it to the skb. When tun_dst_unclone returns, the dst+metadata is only referenced from a single place (the skb) while its refcount is 2. Its refcount will never drop to 0 (when the skb is consumed), leading to a memory leak. Fix this by removing the call to dst_hold in tun_dst_unclone, as the dst+metadata refcount is already 1. • https://git.kernel.org/stable/c/fc4099f17240767554ff3a73977acb78ef615404 https://git.kernel.org/stable/c/4ac84498fbe84a00e7aef185e2bb3e40ce71eca4 https://git.kernel.org/stable/c/c1ff27d100e2670b03cbfddb9117e5f9fc672540 https://git.kernel.org/stable/c/0be943916d781df2b652793bb2d3ae4f9624c10a https://git.kernel.org/stable/c/a80817adc2a4c1ba26a7aa5f3ed886e4a18dff88 https://git.kernel.org/stable/c/00e6d6c3bc14dfe32824e2c515f0e0f2d6ecf2f1 https://git.kernel.org/stable/c/fdcb263fa5cda15b8cb24a641fa2718c47605314 https://git.kernel.org/stable/c/8b1087b998e273f07be13dcb5f3ca4c30 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48808 – net: dsa: fix panic when DSA master device unbinds on shutdown
https://notcve.org/view.php?id=CVE-2022-48808
In the Linux kernel, the following vulnerability has been resolved: net: dsa: fix panic when DSA master device unbinds on shutdown Rafael reports that on a system with LX2160A and Marvell DSA switches, if a reboot occurs while the DSA master (dpaa2-eth) is up, the following panic can be seen: systemd-shutdown[1]: Rebooting. Unable to handle kernel paging request at virtual address 00a0000800000041 [00a0000800000041] address between user and kernel address ranges Internal error: Oops: 96000004 [#1] PREEMPT SMP CPU: 6 PID: 1 Comm: systemd-shutdow Not tainted 5.16.5-00042-g8f5585009b24 #32 pc : dsa_slave_netdevice_event+0x130/0x3e4 lr : raw_notifier_call_chain+0x50/0x6c Call trace: dsa_slave_netdevice_event+0x130/0x3e4 raw_notifier_call_chain+0x50/0x6c call_netdevice_notifiers_info+0x54/0xa0 __dev_close_many+0x50/0x130 dev_close_many+0x84/0x120 unregister_netdevice_many+0x130/0x710 unregister_netdevice_queue+0x8c/0xd0 unregister_netdev+0x20/0x30 dpaa2_eth_remove+0x68/0x190 fsl_mc_driver_remove+0x20/0x5c __device_release_driver+0x21c/0x220 device_release_driver_internal+0xac/0xb0 device_links_unbind_consumers+0xd4/0x100 __device_release_driver+0x94/0x220 device_release_driver+0x28/0x40 bus_remove_device+0x118/0x124 device_del+0x174/0x420 fsl_mc_device_remove+0x24/0x40 __fsl_mc_device_remove+0xc/0x20 device_for_each_child+0x58/0xa0 dprc_remove+0x90/0xb0 fsl_mc_driver_remove+0x20/0x5c __device_release_driver+0x21c/0x220 device_release_driver+0x28/0x40 bus_remove_device+0x118/0x124 device_del+0x174/0x420 fsl_mc_bus_remove+0x80/0x100 fsl_mc_bus_shutdown+0xc/0x1c platform_shutdown+0x20/0x30 device_shutdown+0x154/0x330 __do_sys_reboot+0x1cc/0x250 __arm64_sys_reboot+0x20/0x30 invoke_syscall.constprop.0+0x4c/0xe0 do_el0_svc+0x4c/0x150 el0_svc+0x24/0xb0 el0t_64_sync_handler+0xa8/0xb0 el0t_64_sync+0x178/0x17c It can be seen from the stack trace that the problem is that the deregistration of the master causes a dev_close(), which gets notified as NETDEV_GOING_DOWN to dsa_slave_netdevice_event(). But dsa_switch_shutdown() has already run, and this has unregistered the DSA slave interfaces, and yet, the NETDEV_GOING_DOWN handler attempts to call dev_close_many() on those slave interfaces, leading to the problem. The previous attempt to avoid the NETDEV_GOING_DOWN on the master after dsa_switch_shutdown() was called seems improper. Unregistering the slave interfaces is unnecessary and unhelpful. Instead, after the slaves have stopped being uppers of the DSA master, we can now reset to NULL the master->dsa_ptr pointer, which will make DSA start ignoring all future notifier events on the master. • https://git.kernel.org/stable/c/0650bf52b31ff35dc6430fc2e37969c36baba724 https://git.kernel.org/stable/c/ff45899e732e57088985e3a497b1d9100571c0f5 https://git.kernel.org/stable/c/89b60402d43cdab4387dbbf24afebda5cf092ae7 https://git.kernel.org/stable/c/ee534378f00561207656663d93907583958339ae •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48807 – ice: Fix KASAN error in LAG NETDEV_UNREGISTER handler
https://notcve.org/view.php?id=CVE-2022-48807
In the Linux kernel, the following vulnerability has been resolved: ice: Fix KASAN error in LAG NETDEV_UNREGISTER handler Currently, the same handler is called for both a NETDEV_BONDING_INFO LAG unlink notification as for a NETDEV_UNREGISTER call. This is causing a problem though, since the netdev_notifier_info passed has a different structure depending on which event is passed. The problem manifests as a call trace from a BUG: KASAN stack-out-of-bounds error. Fix this by creating a handler specific to NETDEV_UNREGISTER that only is passed valid elements in the netdev_notifier_info struct for the NETDEV_UNREGISTER event. Also included is the removal of an unbalanced dev_put on the peer_netdev and related braces. • https://git.kernel.org/stable/c/6a8b357278f5f8b9817147277ab8f12879dce8a8 https://git.kernel.org/stable/c/e83b3cce4722b880c277d44b13eebf2548cb2ebb https://git.kernel.org/stable/c/f9daedc3ab8f673e3a9374b91a89fbf1174df469 https://git.kernel.org/stable/c/faa9bcf700ca1a0d09f92502a6b65d3ce313fb46 https://git.kernel.org/stable/c/bea1898f65b9b7096cb4e73e97c83b94718f1fa1 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48806 – eeprom: ee1004: limit i2c reads to I2C_SMBUS_BLOCK_MAX
https://notcve.org/view.php?id=CVE-2022-48806
In the Linux kernel, the following vulnerability has been resolved: eeprom: ee1004: limit i2c reads to I2C_SMBUS_BLOCK_MAX Commit effa453168a7 ("i2c: i801: Don't silently correct invalid transfer size") revealed that ee1004_eeprom_read() did not properly limit how many bytes to read at once. In particular, i2c_smbus_read_i2c_block_data_or_emulated() takes the length to read as an u8. If count == 256 after taking into account the offset and page boundary, the cast to u8 overflows. And this is common when user space tries to read the entire EEPROM at once. To fix it, limit each read to I2C_SMBUS_BLOCK_MAX (32) bytes, already the maximum length i2c_smbus_read_i2c_block_data_or_emulated() allows. • https://git.kernel.org/stable/c/aca56c298e2a6d20ab6308e203a8d37f2a7759d3 https://git.kernel.org/stable/c/25714ad6bf5e98025579fa4c08ff2041a663910c https://git.kernel.org/stable/c/be9313f755a7bfa02230b15731d07074d5255ecb https://git.kernel.org/stable/c/07d9beb6e3c2e852e884113d6803ea4b3643ae38 https://git.kernel.org/stable/c/74650c34f93044d3ab441235f161f9e1e761e96b https://git.kernel.org/stable/c/a126a8c3dd51519513141b4fc94fd4813bca2c0f https://git.kernel.org/stable/c/202d0e22fe512df0f1cb6253d40ce1058e373247 https://git.kernel.org/stable/c/7414af7bdad9a9cddb3a765ca98ea2070 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48805 – net: usb: ax88179_178a: Fix out-of-bounds accesses in RX fixup
https://notcve.org/view.php?id=CVE-2022-48805
In the Linux kernel, the following vulnerability has been resolved: net: usb: ax88179_178a: Fix out-of-bounds accesses in RX fixup ax88179_rx_fixup() contains several out-of-bounds accesses that can be triggered by a malicious (or defective) USB device, in particular: - The metadata array (hdr_off..hdr_off+2*pkt_cnt) can be out of bounds, causing OOB reads and (on big-endian systems) OOB endianness flips. - A packet can overlap the metadata array, causing a later OOB endianness flip to corrupt data used by a cloned SKB that has already been handed off into the network stack. - A packet SKB can be constructed whose tail is far beyond its end, causing out-of-bounds heap data to be considered part of the SKB's data. I have tested that this can be used by a malicious USB device to send a bogus ICMPv6 Echo Request and receive an ICMPv6 Echo Reply in response that contains random kernel heap data. It's probably also possible to get OOB writes from this on a little-endian system somehow - maybe by triggering skb_cow() via IP options processing -, but I haven't tested that. • https://git.kernel.org/stable/c/e2ca90c276e1fc410d7cd3c1a4eee245ec902a20 https://git.kernel.org/stable/c/711b6bf3fb052f0a6b5b3205d50e30c0c2980382 https://git.kernel.org/stable/c/63f0cfb36c1f1964a59ce544156677601e2d8740 https://git.kernel.org/stable/c/1668781ed24da43498799aa4f65714a7de201930 https://git.kernel.org/stable/c/a0fd5492ee769029a636f1fb521716b022b1423d https://git.kernel.org/stable/c/758290defe93a865a2880d10c5d5abd288b64b5d https://git.kernel.org/stable/c/ffd0393adcdcefab7e131488e10dcfde5e02d6eb https://git.kernel.org/stable/c/9681823f96a811268265f35307072ad80 •