CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-45003 – vfs: Don't evict inode under the inode lru traversing context
https://notcve.org/view.php?id=CVE-2024-45003
In the Linux kernel, the following vulnerability has been resolved: vfs: Don't evict inode under the inode lru traversing context The inode reclaiming process(See function prune_icache_sb) collects all reclaimable inodes and mark them with I_FREEING flag at first, at that time, other processes will be stuck if they try getting these inodes (See function find_inode_fast), then the reclaiming process destroy the inodes by function dispose_list(). Some filesystems(eg. ext4 with ea_inode feature, ubifs with xattr) may do inode lookup in the inode evicting callback function, if the inode lookup is operated under the inode lru traversing context, deadlock problems may happen. Case 1: In function ext4_evict_inode(), the ea inode lookup could happen if ea_inode feature is enabled, the lookup process will be stuck under the evicting context like this: 1. File A has inode i_reg and an ea inode i_ea 2. getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea 3. Then, following three processes running like this: PA PB echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // i_reg is added into lru, lru->i_ea->i_reg prune_icache_sb list_lru_walk_one inode_lru_isolate i_ea->i_state |= I_FREEING // set inode state inode_lru_isolate __iget(i_reg) spin_unlock(&i_reg->i_lock) spin_unlock(lru_lock) rm file A i_reg->nlink = 0 iput(i_reg) // i_reg->nlink is 0, do evict ext4_evict_inode ext4_xattr_delete_inode ext4_xattr_inode_dec_ref_all ext4_xattr_inode_iget ext4_iget(i_ea->i_ino) iget_locked find_inode_fast __wait_on_freeing_inode(i_ea) ----→ AA deadlock dispose_list // cannot be executed by prune_icache_sb wake_up_bit(&i_ea->i_state) Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file deleting process holds BASEHD's wbuf->io_mutex while getting the xattr inode, which could race with inode reclaiming process(The reclaiming process could try locking BASEHD's wbuf->io_mutex in inode evicting function), then an ABBA deadlock problem would happen as following: 1. File A has inode ia and a xattr(with inode ixa), regular file B has inode ib and a xattr. 2. getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa 3. • https://git.kernel.org/stable/c/e50e5129f384ae282adebfb561189cdb19b81cee https://git.kernel.org/stable/c/3525ad25240dfdd8c78f3470911ed10aa727aa72 https://git.kernel.org/stable/c/03880af02a78bc9a98b5a581f529cf709c88a9b8 https://git.kernel.org/stable/c/cda54ec82c0f9d05393242b20b13f69b083f7e88 https://git.kernel.org/stable/c/437741eba63bf4e437e2beb5583f8633556a2b98 https://git.kernel.org/stable/c/b9bda5f6012dd00372f3a06a82ed8971a4c57c32 https://git.kernel.org/stable/c/9063ab49c11e9518a3f2352434bb276cc8134c5f https://git.kernel.org/stable/c/2a0629834cd82f05d424bbc193374f9a4 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-44999 – gtp: pull network headers in gtp_dev_xmit()
https://notcve.org/view.php?id=CVE-2024-44999
In the Linux kernel, the following vulnerability has been resolved: gtp: pull network headers in gtp_dev_xmit() syzbot/KMSAN reported use of uninit-value in get_dev_xmit() [1] We must make sure the IPv4 or Ipv6 header is pulled in skb->head before accessing fields in them. Use pskb_inet_may_pull() to fix this issue. [1] BUG: KMSAN: uninit-value in ipv6_pdp_find drivers/net/gtp.c:220 [inline] BUG: KMSAN: uninit-value in gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline] BUG: KMSAN: uninit-value in gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 ipv6_pdp_find drivers/net/gtp.c:220 [inline] gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline] gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 __netdev_start_xmit include/linux/netdevice.h:4913 [inline] netdev_start_xmit include/linux/netdevice.h:4922 [inline] xmit_one net/core/dev.c:3580 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596 __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423 dev_queue_xmit include/linux/netdevice.h:3105 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3145 [inline] packet_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:3994 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674 alloc_skb include/linux/skbuff.h:1320 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815 packet_alloc_skb net/packet/af_packet.c:2994 [inline] packet_snd net/packet/af_packet.c:3088 [inline] packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 • https://git.kernel.org/stable/c/459aa660eb1d8ce67080da1983bb81d716aa5a69 https://git.kernel.org/stable/c/3d89d0c4a1c6d4d2a755e826351b0a101dbc86f3 https://git.kernel.org/stable/c/f5dda8db382c5751c4e572afc7c99df7da1f83ca https://git.kernel.org/stable/c/cbb9a969fc190e85195d1b0f08038e7f6199044e https://git.kernel.org/stable/c/1f6b62392453d8f36685d19b761307a8c5617ac1 https://git.kernel.org/stable/c/137d565ab89ce3584503b443bc9e00d44f482593 https://git.kernel.org/stable/c/34ba4f29f3d9eb52dee37512059efb2afd7e966f https://git.kernel.org/stable/c/3939d787139e359b77aaf9485d1e145d6 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-44998 – atm: idt77252: prevent use after free in dequeue_rx()
https://notcve.org/view.php?id=CVE-2024-44998
In the Linux kernel, the following vulnerability has been resolved: atm: idt77252: prevent use after free in dequeue_rx() We can't dereference "skb" after calling vcc->push() because the skb is released. • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/628ea82190a678a56d2ec38cda3addf3b3a6248d https://git.kernel.org/stable/c/09e086a5f72ea27c758b3f3b419a69000c32adc1 https://git.kernel.org/stable/c/1cece837e387c039225f19028df255df87a97c0d https://git.kernel.org/stable/c/24cf390a5426aac9255205e9533cdd7b4235d518 https://git.kernel.org/stable/c/379a6a326514a3e2f71b674091dfb0e0e7522b55 https://git.kernel.org/stable/c/ef23c18ab88e33ce000d06a5c6aad0620f219bfd https://git.kernel.org/stable/c/91b4850e7165a4b7180ef1e227733bcb4 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-44995 – net: hns3: fix a deadlock problem when config TC during resetting
https://notcve.org/view.php?id=CVE-2024-44995
In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix a deadlock problem when config TC during resetting When config TC during the reset process, may cause a deadlock, the flow is as below: pf reset start │ ▼ ...... setup tc │ │ ▼ ▼ DOWN: napi_disable() napi_disable()(skip) │ │ │ ▼ ▼ ...... ...... │ │ ▼ │ napi_enable() │ ▼ UINIT: netif_napi_del() │ ▼ ...... │ ▼ INIT: netif_napi_add() │ ▼ ...... global reset start │ │ ▼ ▼ UP: napi_enable()(skip) ...... │ │ ▼ ▼ ...... napi_disable() In reset process, the driver will DOWN the port and then UINIT, in this case, the setup tc process will UP the port before UINIT, so cause the problem. Adds a DOWN process in UINIT to fix it. • https://git.kernel.org/stable/c/bb6b94a896d4dd4dcdeccca87c3fd22521c652c0 https://git.kernel.org/stable/c/67492d4d105c0a6321b00c393eec96b9a7a97a16 https://git.kernel.org/stable/c/fc250eca15bde34c4c8f806b9d88f55bd56a992c https://git.kernel.org/stable/c/195918217448a6bb7f929d6a2ffffce9f1ece1cc https://git.kernel.org/stable/c/6ae2b7d63cd056f363045eb65409143e16f23ae8 https://git.kernel.org/stable/c/fa1d4de7265c370e673583ac8d1bd17d21826cd9 https://git.kernel.org/stable/c/de37408d5c26fc4a296a28a0c96dcb814219bfa1 https://git.kernel.org/stable/c/be5e816d00a506719e9dbb1a9c861c5ce •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-44988 – net: dsa: mv88e6xxx: Fix out-of-bound access
https://notcve.org/view.php?id=CVE-2024-44988
In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Fix out-of-bound access If an ATU violation was caused by a CPU Load operation, the SPID could be larger than DSA_MAX_PORTS (the size of mv88e6xxx_chip.ports[] array). • https://git.kernel.org/stable/c/27a2fa0098171199022affa76bdf15d77585457f https://git.kernel.org/stable/c/75c05a74e745ae7d663b04d75777af80ada2233c https://git.kernel.org/stable/c/1657d2814e83d3e338d6d60c5829d15d86645bc0 https://git.kernel.org/stable/c/4a88fca95c8df3746b71e31f44a02d35f06f9864 https://git.kernel.org/stable/c/d39f5be62f098fe367d672b4dd4bc4b2b80e08e7 https://git.kernel.org/stable/c/050e7274ab2150cd212b2372595720e7b83a15bd https://git.kernel.org/stable/c/a10d0337115a6d223a1563d853d4455f05d0b2e3 https://git.kernel.org/stable/c/18b2e833daf049223ab3c2efdf8cdee08 •