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 •
CVSS: 7.1EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48804 – vt_ioctl: fix array_index_nospec in vt_setactivate
https://notcve.org/view.php?id=CVE-2022-48804
In the Linux kernel, the following vulnerability has been resolved: vt_ioctl: fix array_index_nospec in vt_setactivate array_index_nospec ensures that an out-of-bounds value is set to zero on the transient path. Decreasing the value by one afterwards causes a transient integer underflow. vsa.console should be decreased first and then sanitized with array_index_nospec. Kasper Acknowledgements: Jakob Koschel, Brian Johannesmeyer, Kaveh Razavi, Herbert Bos, Cristiano Giuffrida from the VUSec group at VU Amsterdam. • https://git.kernel.org/stable/c/830c5aa302ec16b4ee641aec769462c37f802c90 https://git.kernel.org/stable/c/2a45a6bd1e6d651770aafff57ab3e1d3bb0b42e0 https://git.kernel.org/stable/c/170325aba4608bde3e7d21c9c19b7bc266ac0885 https://git.kernel.org/stable/c/ae3d57411562260ee3f4fd5e875f410002341104 https://git.kernel.org/stable/c/778302ca09498b448620edd372dc908bebf80bdf https://git.kernel.org/stable/c/ffe54289b02e9c732d6f04c8ebbe3b2d90d32118 https://git.kernel.org/stable/c/6550bdf52846f85a2a3726a5aa0c7c4399f2fc02 https://git.kernel.org/stable/c/61cc70d9e8ef5b042d4ed87994d20100e •