CVE-2024-56570 – ovl: Filter invalid inodes with missing lookup function
https://notcve.org/view.php?id=CVE-2024-56570
In the Linux kernel, the following vulnerability has been resolved: ovl: Filter invalid inodes with missing lookup function Add a check to the ovl_dentry_weird() function to prevent the processing of directory inodes that lack the lookup function. This is important because such inodes can cause errors in overlayfs when passed to the lowerstack. • https://git.kernel.org/stable/c/f9248e2f73fb4afe08324485e98c815ac084d166 https://git.kernel.org/stable/c/5f86e79c0b2287ffdabe6c1b305a36c4e0f40fe3 https://git.kernel.org/stable/c/749eac5a6687ec99116e0691d0d71225254654e3 https://git.kernel.org/stable/c/ff43d008bbf9b27ada434d6455f039a5ef6cee53 https://git.kernel.org/stable/c/065bf5dd21639f80e68450de16bda829784dbb8c https://git.kernel.org/stable/c/72014e7745cc8250bb8f27bd78694dfd3f1b5773 https://git.kernel.org/stable/c/c8b359dddb418c60df1a69beea01d1b3322bfe83 •
CVE-2024-56566 – mm/slub: Avoid list corruption when removing a slab from the full list
https://notcve.org/view.php?id=CVE-2024-56566
In the Linux kernel, the following vulnerability has been resolved: mm/slub: Avoid list corruption when removing a slab from the full list Boot with slub_debug=UFPZ. If allocated object failed in alloc_consistency_checks, all objects of the slab will be marked as used, and then the slab will be removed from the partial list. When an object belonging to the slab got freed later, the remove_full() function is called. Because the slab is neither on the partial list nor on the full list, it eventually lead to a list corruption (actually a list poison being detected). So we need to mark and isolate the slab page with metadata corruption, do not put it back in circulation. Because the debug caches avoid all the fastpaths, reusing the frozen bit to mark slab page with metadata corruption seems to be fine. [ 4277.385669] list_del corruption, ffffea00044b3e50->next is LIST_POISON1 (dead000000000100) [ 4277.387023] ------------[ cut here ]------------ [ 4277.387880] kernel BUG at lib/list_debug.c:56! [ 4277.388680] invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 4277.389562] CPU: 5 PID: 90 Comm: kworker/5:1 Kdump: loaded Tainted: G OE 6.6.1-1 #1 [ 4277.392113] Workqueue: xfs-inodegc/vda1 xfs_inodegc_worker [xfs] [ 4277.393551] RIP: 0010:__list_del_entry_valid_or_report+0x7b/0xc0 [ 4277.394518] Code: 48 91 82 e8 37 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 28 49 91 82 e8 26 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 58 49 91 [ 4277.397292] RSP: 0018:ffffc90000333b38 EFLAGS: 00010082 [ 4277.398202] RAX: 000000000000004e RBX: ffffea00044b3e50 RCX: 0000000000000000 [ 4277.399340] RDX: 0000000000000002 RSI: ffffffff828f8715 RDI: 00000000ffffffff [ 4277.400545] RBP: ffffea00044b3e40 R08: 0000000000000000 R09: ffffc900003339f0 [ 4277.401710] R10: 0000000000000003 R11: ffffffff82d44088 R12: ffff888112cf9910 [ 4277.402887] R13: 0000000000000001 R14: 0000000000000001 R15: ffff8881000424c0 [ 4277.404049] FS: 0000000000000000(0000) GS:ffff88842fd40000(0000) knlGS:0000000000000000 [ 4277.405357] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4277.406389] CR2: 00007f2ad0b24000 CR3: 0000000102a3a006 CR4: 00000000007706e0 [ 4277.407589] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4277.408780] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 4277.410000] PKRU: 55555554 [ 4277.410645] Call Trace: [ 4277.411234] <TASK> [ 4277.411777] ? die+0x32/0x80 [ 4277.412439] ? do_trap+0xd6/0x100 [ 4277.413150] ? • https://git.kernel.org/stable/c/643b113849d8faa68c9f01c3c9d929bfbffd50bd https://git.kernel.org/stable/c/33a213c04faff6c3a7fe77e947db81bc7270fe32 https://git.kernel.org/stable/c/943c0f601cd28c1073b92b5f944c6c6c2643e709 https://git.kernel.org/stable/c/dbc16915279a548a204154368da23d402c141c81 •
CVE-2024-56551 – drm/amdgpu: fix usage slab after free
https://notcve.org/view.php?id=CVE-2024-56551
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix usage slab after free [ +0.000021] BUG: KASAN: slab-use-after-free in drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000027] Read of size 8 at addr ffff8881b8605f88 by task amd_pci_unplug/2147 [ +0.000023] CPU: 6 PID: 2147 Comm: amd_pci_unplug Not tainted 6.10.0+ #1 [ +0.000016] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020 [ +0.000016] Call Trace: [ +0.000008] <TASK> [ +0.000009] dump_stack_lvl+0x76/0xa0 [ +0.000017] print_report+0xce/0x5f0 [ +0.000017] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000019] ? srso_return_thunk+0x5/0x5f [ +0.000015] ? kasan_complete_mode_report_info+0x72/0x200 [ +0.000016] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000019] kasan_report+0xbe/0x110 [ +0.000015] ? • https://git.kernel.org/stable/c/3990ef742c064e22189b954522930db04fc6b1a7 https://git.kernel.org/stable/c/6383199ada42d30562b4249c393592a2a9c38165 https://git.kernel.org/stable/c/b61badd20b443eabe132314669bb51a263982e5c •
CVE-2024-56544 – udmabuf: change folios array from kmalloc to kvmalloc
https://notcve.org/view.php?id=CVE-2024-56544
In the Linux kernel, the following vulnerability has been resolved: udmabuf: change folios array from kmalloc to kvmalloc When PAGE_SIZE 4096, MAX_PAGE_ORDER 10, 64bit machine, page_alloc only support 4MB. If above this, trigger this warn and return NULL. udmabuf can change size limit, if change it to 3072(3GB), and then alloc 3GB udmabuf, will fail create. [ 4080.876581] ------------[ cut here ]------------ [ 4080.876843] WARNING: CPU: 3 PID: 2015 at mm/page_alloc.c:4556 __alloc_pages+0x2c8/0x350 [ 4080.878839] RIP: 0010:__alloc_pages+0x2c8/0x350 [ 4080.879470] Call Trace: [ 4080.879473] <TASK> [ 4080.879473] ? __alloc_pages+0x2c8/0x350 [ 4080.879475] ? __warn.cold+0x8e/0xe8 [ 4080.880647] ? __alloc_pages+0x2c8/0x350 [ 4080.880909] ? report_bug+0xff/0x140 [ 4080.881175] ? • https://git.kernel.org/stable/c/2acc6192aa8570661ed37868c02c03002b1dc290 https://git.kernel.org/stable/c/85bb72397cb63649fe493c96e27e1d0e4ed2ff63 https://git.kernel.org/stable/c/1c0844c6184e658064e14c4335885785ad3bf84b •
CVE-2024-56533 – ALSA: usx2y: Use snd_card_free_when_closed() at disconnection
https://notcve.org/view.php?id=CVE-2024-56533
In the Linux kernel, the following vulnerability has been resolved: ALSA: usx2y: Use snd_card_free_when_closed() at disconnection The USB disconnect callback is supposed to be short and not too-long waiting. OTOH, the current code uses snd_card_free() at disconnection, but this waits for the close of all used fds, hence it can take long. It eventually blocks the upper layer USB ioctls, which may trigger a soft lockup. An easy workaround is to replace snd_card_free() with snd_card_free_when_closed(). This variant returns immediately while the release of resources is done asynchronously by the card device release at the last close. • https://git.kernel.org/stable/c/230cd5e24853ed4dd960461989b8ed0986d37a99 https://git.kernel.org/stable/c/24fe9f7ca83ec9acf765339054951f5cd9ae5c5d https://git.kernel.org/stable/c/befcca1777525e37c659b4129d8ac7463b07ef67 https://git.kernel.org/stable/c/7bd8838c0ea886679a32834fdcacab296d072fbe https://git.kernel.org/stable/c/e07605d855c4104d981653146a330ea48f6266ed https://git.kernel.org/stable/c/ffbfc6c4330fc233698529656798bee44fea96f5 https://git.kernel.org/stable/c/e869642a77a9b3b98b0ab2c8fec7af4385140909 https://git.kernel.org/stable/c/dafb28f02be407e07a6f679e922a62659 •