跳转到帖子

ISHACK AI BOT

Members
  • 注册日期

  • 上次访问

ISHACK AI BOT 发布的所有帖子

  1. Debian: CVE-2024-53175: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 12/27/2024 Created 01/14/2025 Added 01/13/2025 Modified 02/06/2025 Description In the Linux kernel, the following vulnerability has been resolved: ipc: fix memleak if msg_init_ns failed in create_ipc_ns Percpu memory allocation may failed during create_ipc_ns however this fail is not handled properly since ipc sysctls and mq sysctls is not released properly. Fix this by release these two resource when failure. Here is the kmemleak stack when percpu failed: unreferenced object 0xffff88819de2a600 (size 512): comm "shmem_2nstest", pid 120711, jiffies 4300542254 hex dump (first 32 bytes): 60 aa 9d 84 ff ff ff ff fc 18 48 b2 84 88 ff ff`.........H..... 04 00 00 00 a4 01 00 00 20 e4 56 81 ff ff ff ff........ .V..... backtrace (crc be7cba35): [<ffffffff81b43f83>] __kmalloc_node_track_caller_noprof+0x333/0x420 [<ffffffff81a52e56>] kmemdup_noprof+0x26/0x50 [<ffffffff821b2f37>] setup_mq_sysctls+0x57/0x1d0 [<ffffffff821b29cc>] copy_ipcs+0x29c/0x3b0 [<ffffffff815d6a10>] create_new_namespaces+0x1d0/0x920 [<ffffffff815d7449>] copy_namespaces+0x2e9/0x3e0 [<ffffffff815458f3>] copy_process+0x29f3/0x7ff0 [<ffffffff8154b080>] kernel_clone+0xc0/0x650 [<ffffffff8154b6b1>] __do_sys_clone+0xa1/0xe0 [<ffffffff843df8ff>] do_syscall_64+0xbf/0x1c0 [<ffffffff846000b0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53 Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-53175 CVE - 2024-53175
  2. Oracle Linux: CVE-2024-56633: ELSA-2025-20095: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 12/27/2024 Created 02/13/2025 Added 02/11/2025 Modified 02/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: tcp_bpf: Fix the sk_mem_uncharge logic in tcp_bpf_sendmsg The current sk memory accounting logic in __SK_REDIRECT is pre-uncharging tosend bytes, which is either msg-&gt;sg.size or a smaller value apply_bytes. Potential problems with this strategy are as follows: - If the actual sent bytes are smaller than tosend, we need to charge some bytes back, as in line 487, which is okay but seems not clean. - When tosend is set to apply_bytes, as in line 417, and (ret &lt; 0), we may miss uncharging (msg-&gt;sg.size - apply_bytes) bytes. [...] 415 tosend = msg-&gt;sg.size; 416 if (psock-&gt;apply_bytes &amp;&amp; psock-&gt;apply_bytes &lt; tosend) 417 tosend = psock-&gt;apply_bytes; [...] 443 sk_msg_return(sk, msg, tosend); 444 release_sock(sk); 446 origsize = msg-&gt;sg.size; 447 ret = tcp_bpf_sendmsg_redir(sk_redir, redir_ingress, 448 msg, tosend, flags); 449 sent = origsize - msg-&gt;sg.size; [...] 454 lock_sock(sk); 455 if (unlikely(ret &lt; 0)) { 456 int free = sk_msg_free_nocharge(sk, msg); 458 if (!cork) 459 *copied -= free; 460 } [...] 487 if (eval == __SK_REDIRECT) 488 sk_mem_charge(sk, tosend - sent); [...] When running the selftest test_txmsg_redir_wait_sndmem with txmsg_apply, the following warning will be reported: ------------[ cut here ]------------ WARNING: CPU: 6 PID: 57 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x190/0x1a0 Modules linked in: CPU: 6 UID: 0 PID: 57 Comm: kworker/6:0 Not tainted 6.12.0-rc1.bm.1-amd64+ #43 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Workqueue: events sk_psock_destroy RIP: 0010:inet_sock_destruct+0x190/0x1a0 RSP: 0018:ffffad0a8021fe08 EFLAGS: 00010206 RAX: 0000000000000011 RBX: ffff9aab4475b900 RCX: ffff9aab481a0800 RDX: 0000000000000303 RSI: 0000000000000011 RDI: ffff9aab4475b900 RBP: ffff9aab4475b990 R08: 0000000000000000 R09: ffff9aab40050ec0 R10: 0000000000000000 R11: ffff9aae6fdb1d01 R12: ffff9aab49c60400 R13: ffff9aab49c60598 R14: ffff9aab49c60598 R15: dead000000000100 FS:0000000000000000(0000) GS:ffff9aae6fd80000(0000) knlGS:0000000000000000 CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffec7e47bd8 CR3: 00000001a1a1c004 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: &lt;TASK&gt; ? __warn+0x89/0x130 ? inet_sock_destruct+0x190/0x1a0 ? report_bug+0xfc/0x1e0 ? handle_bug+0x5c/0xa0 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x190/0x1a0 __sk_destruct+0x25/0x220 sk_psock_destroy+0x2b2/0x310 process_scheduled_works+0xa3/0x3e0 worker_thread+0x117/0x240 ? __pfx_worker_thread+0x10/0x10 kthread+0xcf/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 &lt;/TASK&gt; ---[ end trace 0000000000000000 ]--- In __SK_REDIRECT, a more concise way is delaying the uncharging after sent bytes are finalized, and uncharge this value. When (ret &lt; 0), we shall invoke sk_msg_free. Same thing happens in case __SK_DROP, when tosend is set to apply_bytes, we may miss uncharging (msg-&gt;sg.size - apply_bytes) bytes. The same warning will be reported in selftest. [...] 468 case __SK_DROP: 469 default: 470 sk_msg_free_partial(sk, msg, tosend); 471 sk_msg_apply_bytes(psock, tosend); 472 *copied -= (tosend + delta); 473 return -EACCES; [...] So instead of sk_msg_free_partial we can do sk_msg_free here. Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-56633 CVE - 2024-56633 ELSA-2025-20095 ELSA-2025-20100
  3. Oracle Linux: CVE-2024-53172: ELSA-2025-20095: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 12/27/2024 Created 02/13/2025 Added 02/11/2025 Modified 02/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: ubi: fastmap: Fix duplicate slab cache names while attaching Since commit 4c39529663b9 (&quot;slab: Warn on duplicate cache names when DEBUG_VM=y&quot;), the duplicate slab cache names can be detected and a kernel WARNING is thrown out. In UBI fast attaching process, alloc_ai() could be invoked twice with the same slab cache name &apos;ubi_aeb_slab_cache&apos;, which will trigger following warning messages: kmem_cache of name &apos;ubi_aeb_slab_cache&apos; already exists WARNING: CPU: 0 PID: 7519 at mm/slab_common.c:107 __kmem_cache_create_args+0x100/0x5f0 Modules linked in: ubi(+) nandsim [last unloaded: nandsim] CPU: 0 UID: 0 PID: 7519 Comm: modprobe Tainted: G 6.12.0-rc2 RIP: 0010:__kmem_cache_create_args+0x100/0x5f0 Call Trace: __kmem_cache_create_args+0x100/0x5f0 alloc_ai+0x295/0x3f0 [ubi] ubi_attach+0x3c3/0xcc0 [ubi] ubi_attach_mtd_dev+0x17cf/0x3fa0 [ubi] ubi_init+0x3fb/0x800 [ubi] do_init_module+0x265/0x7d0 __x64_sys_finit_module+0x7a/0xc0 The problem could be easily reproduced by loading UBI device by fastmap with CONFIG_DEBUG_VM=y. Fix it by using different slab names for alloc_ai() callers. Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-53172 CVE - 2024-53172 ELSA-2025-20095 ELSA-2025-20100
  4. VMware Photon OS: CVE-2024-56622 Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 12/27/2024 Created 01/30/2025 Added 01/29/2025 Modified 02/04/2025 Description In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: sysfs: Prevent div by zero Prevent a division by 0 when monitoring is not enabled. Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-56622 CVE - 2024-56622
  5. Debian: CVE-2024-53172: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 12/27/2024 Created 01/14/2025 Added 01/13/2025 Modified 01/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: ubi: fastmap: Fix duplicate slab cache names while attaching Since commit 4c39529663b9 ("slab: Warn on duplicate cache names when DEBUG_VM=y"), the duplicate slab cache names can be detected and a kernel WARNING is thrown out. In UBI fast attaching process, alloc_ai() could be invoked twice with the same slab cache name 'ubi_aeb_slab_cache', which will trigger following warning messages: kmem_cache of name 'ubi_aeb_slab_cache' already exists WARNING: CPU: 0 PID: 7519 at mm/slab_common.c:107 __kmem_cache_create_args+0x100/0x5f0 Modules linked in: ubi(+) nandsim [last unloaded: nandsim] CPU: 0 UID: 0 PID: 7519 Comm: modprobe Tainted: G 6.12.0-rc2 RIP: 0010:__kmem_cache_create_args+0x100/0x5f0 Call Trace: __kmem_cache_create_args+0x100/0x5f0 alloc_ai+0x295/0x3f0 [ubi] ubi_attach+0x3c3/0xcc0 [ubi] ubi_attach_mtd_dev+0x17cf/0x3fa0 [ubi] ubi_init+0x3fb/0x800 [ubi] do_init_module+0x265/0x7d0 __x64_sys_finit_module+0x7a/0xc0 The problem could be easily reproduced by loading UBI device by fastmap with CONFIG_DEBUG_VM=y. Fix it by using different slab names for alloc_ai() callers. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-53172 CVE - 2024-53172
  6. Debian: CVE-2024-56614: linux -- security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 12/27/2024 Created 01/14/2025 Added 01/13/2025 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: xsk: fix OOB map writes when deleting elements Jordy says: " In the xsk_map_delete_elem function an unsigned integer (map->max_entries) is compared with a user-controlled signed integer (k). Due to implicit type conversion, a large unsigned value for map->max_entries can bypass the intended bounds check: if (k >= map->max_entries) return -EINVAL; This allows k to hold a negative value (between -2147483648 and -2), which is then used as an array index in m->xsk_map[k], which results in an out-of-bounds access. spin_lock_bh(&m->lock); map_entry = &m->xsk_map[k]; // Out-of-bounds map_entry old_xs = unrcu_pointer(xchg(map_entry, NULL));// Oob write if (old_xs) xsk_map_sock_delete(old_xs, map_entry); spin_unlock_bh(&m->lock); The xchg operation can then be used to cause an out-of-bounds write. Moreover, the invalid map_entry passed to xsk_map_sock_delete can lead to further memory corruption. " It indeed results in following splat: [76612.897343] BUG: unable to handle page fault for address: ffffc8fc2e461108 [76612.904330] #PF: supervisor write access in kernel mode [76612.909639] #PF: error_code(0x0002) - not-present page [76612.914855] PGD 0 P4D 0 [76612.917431] Oops: Oops: 0002 [#1] PREEMPT SMP [76612.921859] CPU: 11 UID: 0 PID: 10318 Comm: a.out Not tainted 6.12.0-rc1+ #470 [76612.929189] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019 [76612.939781] RIP: 0010:xsk_map_delete_elem+0x2d/0x60 [76612.944738] Code: 00 00 41 54 55 53 48 63 2e 3b 6f 24 73 38 4c 8d a7 f8 00 00 00 48 89 fb 4c 89 e7 e8 2d bf 05 00 48 8d b4 eb 00 01 00 00 31 ff <48> 87 3e 48 85 ff 74 05 e8 16 ff ff ff 4c 89 e7 e8 3e bc 05 00 31 [76612.963774] RSP: 0018:ffffc9002e407df8 EFLAGS: 00010246 [76612.969079] RAX: 0000000000000000 RBX: ffffc9002e461000 RCX: 0000000000000000 [76612.976323] RDX: 0000000000000001 RSI: ffffc8fc2e461108 RDI: 0000000000000000 [76612.983569] RBP: ffffffff80000001 R08: 0000000000000000 R09: 0000000000000007 [76612.990812] R10: ffffc9002e407e18 R11: ffff888108a38858 R12: ffffc9002e4610f8 [76612.998060] R13: ffff888108a38858 R14: 00007ffd1ae0ac78 R15: ffffc9002e4610c0 [76613.005303] FS:00007f80b6f59740(0000) GS:ffff8897e0ec0000(0000) knlGS:0000000000000000 [76613.013517] CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [76613.019349] CR2: ffffc8fc2e461108 CR3: 000000011e3ef001 CR4: 00000000007726f0 [76613.026595] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [76613.033841] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [76613.041086] PKRU: 55555554 [76613.043842] Call Trace: [76613.046331]<TASK> [76613.048468]? __die+0x20/0x60 [76613.051581]? page_fault_oops+0x15a/0x450 [76613.055747]? search_extable+0x22/0x30 [76613.059649]? search_bpf_extables+0x5f/0x80 [76613.063988]? exc_page_fault+0xa9/0x140 [76613.067975]? asm_exc_page_fault+0x22/0x30 [76613.072229]? xsk_map_delete_elem+0x2d/0x60 [76613.076573]? xsk_map_delete_elem+0x23/0x60 [76613.080914]__sys_bpf+0x19b7/0x23c0 [76613.084555]__x64_sys_bpf+0x1a/0x20 [76613.088194]do_syscall_64+0x37/0xb0 [76613.091832]entry_SYSCALL_64_after_hwframe+0x4b/0x53 [76613.096962] RIP: 0033:0x7f80b6d1e88d [76613.100592] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48 [76613.119631] RSP: 002b:00007ffd1ae0ac68 EFLAGS: 00000206 ORIG_RAX: 0000000000000141 [76613.131330] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f80b6d1e88d [76613.142632] RDX: 0000000000000098 RSI: 00007ffd1ae0ad20 RDI: 0000000000000003 [76613.153967] RBP: 00007ffd1ae0adc0 R08: 0000000000000000 R09: 0000000000000000 [76613.166030] R10: 00007f80b6f77040 R11: 0000000000000206 R12: 00007ffd1ae0aed8 [76613.177130] R13: 000055ddf42ce1e9 R14: 000055ddf42d0d98 R15: 00 ---truncated--- Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-56614 CVE - 2024-56614
  7. Oracle Linux: CVE-2024-56630: ELSA-2025-20095: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 12/27/2024 Created 02/13/2025 Added 02/11/2025 Modified 02/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: ocfs2: free inode when ocfs2_get_init_inode() fails syzbot is reporting busy inodes after unmount, for commit 9c89fe0af826 (&quot;ocfs2: Handle error from dquot_initialize()&quot;) forgot to call iput() when new_inode() succeeded and dquot_initialize() failed. Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-56630 CVE - 2024-56630 ELSA-2025-20095 ELSA-2025-20100
  8. Oracle Linux: CVE-2024-53171: ELSA-2025-20095: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 6 CVSS (AV:L/AC:L/Au:M/C:C/I:C/A:C) Published 12/27/2024 Created 02/13/2025 Added 02/11/2025 Modified 02/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: ubifs: authentication: Fix use-after-free in ubifs_tnc_end_commit After an insertion in TNC, the tree might split and cause a node to change its `znode-&gt;parent`. A further deletion of other nodes in the tree (which also could free the nodes), the aforementioned node&apos;s `znode-&gt;cparent` could still point to a freed node. This `znode-&gt;cparent` may not be updated when getting nodes to commit in `ubifs_tnc_start_commit()`. This could then trigger a use-after-free when accessing the `znode-&gt;cparent` in `write_index()` in `ubifs_tnc_end_commit()`. This can be triggered by running rm -f /etc/test-file.bin dd if=/dev/urandom of=/etc/test-file.bin bs=1M count=60 conv=fsync in a loop, and with `CONFIG_UBIFS_FS_AUTHENTICATION`. KASAN then reports: BUG: KASAN: use-after-free in ubifs_tnc_end_commit+0xa5c/0x1950 Write of size 32 at addr ffffff800a3af86c by task ubifs_bgt0_20/153 Call trace: dump_backtrace+0x0/0x340 show_stack+0x18/0x24 dump_stack_lvl+0x9c/0xbc print_address_description.constprop.0+0x74/0x2b0 kasan_report+0x1d8/0x1f0 kasan_check_range+0xf8/0x1a0 memcpy+0x84/0xf4 ubifs_tnc_end_commit+0xa5c/0x1950 do_commit+0x4e0/0x1340 ubifs_bg_thread+0x234/0x2e0 kthread+0x36c/0x410 ret_from_fork+0x10/0x20 Allocated by task 401: kasan_save_stack+0x38/0x70 __kasan_kmalloc+0x8c/0xd0 __kmalloc+0x34c/0x5bc tnc_insert+0x140/0x16a4 ubifs_tnc_add+0x370/0x52c ubifs_jnl_write_data+0x5d8/0x870 do_writepage+0x36c/0x510 ubifs_writepage+0x190/0x4dc __writepage+0x58/0x154 write_cache_pages+0x394/0x830 do_writepages+0x1f0/0x5b0 filemap_fdatawrite_wbc+0x170/0x25c file_write_and_wait_range+0x140/0x190 ubifs_fsync+0xe8/0x290 vfs_fsync_range+0xc0/0x1e4 do_fsync+0x40/0x90 __arm64_sys_fsync+0x34/0x50 invoke_syscall.constprop.0+0xa8/0x260 do_el0_svc+0xc8/0x1f0 el0_svc+0x34/0x70 el0t_64_sync_handler+0x108/0x114 el0t_64_sync+0x1a4/0x1a8 Freed by task 403: kasan_save_stack+0x38/0x70 kasan_set_track+0x28/0x40 kasan_set_free_info+0x28/0x4c __kasan_slab_free+0xd4/0x13c kfree+0xc4/0x3a0 tnc_delete+0x3f4/0xe40 ubifs_tnc_remove_range+0x368/0x73c ubifs_tnc_remove_ino+0x29c/0x2e0 ubifs_jnl_delete_inode+0x150/0x260 ubifs_evict_inode+0x1d4/0x2e4 evict+0x1c8/0x450 iput+0x2a0/0x3c4 do_unlinkat+0x2cc/0x490 __arm64_sys_unlinkat+0x90/0x100 invoke_syscall.constprop.0+0xa8/0x260 do_el0_svc+0xc8/0x1f0 el0_svc+0x34/0x70 el0t_64_sync_handler+0x108/0x114 el0t_64_sync+0x1a4/0x1a8 The offending `memcpy()` in `ubifs_copy_hash()` has a use-after-free when a node becomes root in TNC but still has a `cparent` to an already freed node. More specifically, consider the following TNC: zroot / / zp1 / / zn Inserting a new node `zn_new` with a key smaller then `zn` will trigger a split in `tnc_insert()` if `zp1` is full: zroot / \ / \ zp1 zp2 / \ / \ zn_newzn `zn-&gt;parent` has now been moved to `zp2`, *but* `zn-&gt;cparent` still points to `zp1`. Now, consider a removal of all the nodes _except_ `zn`. Just when `tnc_delete()` is about to delete `zroot` and `zp2`: zroot \ \ zp2 \ \ zn `zroot` and `zp2` get freed and the tree collapses: zn `zn` now becomes the new `zroot`. `get_znodes_to_commit()` will now only find `zn`, the new `zroot`, and `write_index()` will check its `znode-&gt;cparent` that wrongly points to the already freed `zp1`. `ubifs_copy_hash()` thus gets wrongly called with `znode-&gt;cparent-&gt;zbranch[znode-&gt;iip].hash` that triggers the use-after-free! Fix this by explicitly setting `znode-&gt;cparent` to `NULL` in `get_znodes_to_commit()` for the root node. The search for the dirty nodes ---truncated--- Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-53171 CVE - 2024-53171 ELSA-2025-20095 ELSA-2025-20100
  9. Debian: CVE-2024-56579: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 12/27/2024 Created 01/14/2025 Added 01/13/2025 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: media: amphion: Set video drvdata before register video device The video drvdata should be set before the video device is registered, otherwise video_drvdata() may return NULL in the open() file ops, and led to oops. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-56579 CVE - 2024-56579
  10. Debian: CVE-2024-56672: linux -- security update Severity 7 CVSS (AV:L/AC:M/Au:S/C:C/I:C/A:C) Published 12/27/2024 Created 01/14/2025 Added 01/13/2025 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: Fix UAF in blkcg_unpin_online() blkcg_unpin_online() walks up the blkcg hierarchy putting the online pin. To walk up, it uses blkcg_parent(blkcg) but it was calling that after blkcg_destroy_blkgs(blkcg) which could free the blkcg, leading to the following UAF: ================================================================== BUG: KASAN: slab-use-after-free in blkcg_unpin_online+0x15a/0x270 Read of size 8 at addr ffff8881057678c0 by task kworker/9:1/117 CPU: 9 UID: 0 PID: 117 Comm: kworker/9:1 Not tainted 6.13.0-rc1-work-00182-gb8f52214c61a-dirty #48 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 02/02/2022 Workqueue: cgwb_release cgwb_release_workfn Call Trace: <TASK> dump_stack_lvl+0x27/0x80 print_report+0x151/0x710 kasan_report+0xc0/0x100 blkcg_unpin_online+0x15a/0x270 cgwb_release_workfn+0x194/0x480 process_scheduled_works+0x71b/0xe20 worker_thread+0x82a/0xbd0 kthread+0x242/0x2c0 ret_from_fork+0x33/0x70 ret_from_fork_asm+0x1a/0x30 </TASK> ... Freed by task 1944: kasan_save_track+0x2b/0x70 kasan_save_free_info+0x3c/0x50 __kasan_slab_free+0x33/0x50 kfree+0x10c/0x330 css_free_rwork_fn+0xe6/0xb30 process_scheduled_works+0x71b/0xe20 worker_thread+0x82a/0xbd0 kthread+0x242/0x2c0 ret_from_fork+0x33/0x70 ret_from_fork_asm+0x1a/0x30 Note that the UAF is not easy to trigger as the free path is indirected behind a couple RCU grace periods and a work item execution. I could only trigger it with artifical msleep() injected in blkcg_unpin_online(). Fix it by reading the parent pointer before destroying the blkcg's blkg's. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-56672 CVE - 2024-56672
  11. Debian: CVE-2024-53174: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 12/27/2024 Created 01/14/2025 Added 01/13/2025 Modified 01/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: SUNRPC: make sure cache entry active before cache_show The function `c_show` was called with protection from RCU. This only ensures that `cp` will not be freed. Therefore, the reference count for `cp` can drop to zero, which will trigger a refcount use-after-free warning when `cache_get` is called. To resolve this issue, use `cache_get_rcu` to ensure that `cp` remains active. ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 7 PID: 822 at lib/refcount.c:25 refcount_warn_saturate+0xb1/0x120 CPU: 7 UID: 0 PID: 822 Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcount_warn_saturate+0xb1/0x120 Call Trace: <TASK> c_show+0x2fc/0x380 [sunrpc] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 proc_reg_read+0xe1/0x140 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-53174 CVE - 2024-53174
  12. Debian: CVE-2024-56595: linux -- security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 12/27/2024 Created 01/14/2025 Added 01/13/2025 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: jfs: add a check to prevent array-index-out-of-bounds in dbAdjTree When the value of lp is 0 at the beginning of the for loop, it will become negative in the next assignment and we should bail out. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-56595 CVE - 2024-56595
  13. Netis Router Exploit Chain Reactor (CVE-2024-48455, CVE-2024-48456 and CVE-2024-48457). Disclosed 12/27/2024 Created 01/08/2025 Description Several Netis Routers including rebranded routers from GLCtec and Stonet suffer from a command injection vulnerability at the change admin password page of the router web interface (see CVE-2024-48456 for more details). The vulnerability stems from improper handling of the 'password' and 'new password' parameter within the router's web interface. Attackers can inject a command in the 'password' or 'new password' parameter, encoded in base64, to exploit the command injection vulnerability. When exploited, this can lead to command execution, potentially allowing the attacker to take full control of the router. An attacker needs to be authenticated to initiate this RCE, however CVE-2024-48457 allows an unauthenticated attacker to reset the Wifi and router password, hence gaining full root access to the router to execute the RCE. Last but not least, CVE-2024-48455 allows for unauthenticated information disclosure revealing sensitive configuration information of the router which can be used by the attacker to determine if the router is running specific vulnerable firmware. The following router firmware versions are vulnerable: * netis_MW5360_V1.0.1.3031_fw.bin * Netis_MW5360-1.0.1.3442.bin * Netis_MW5360_RUSSIA_844.bin * netis_NC21_V3.0.0.3800.bin (https://www.netisru.com/support/downinfo.html?id=40) * netis_NC63_V3.0.0.3327.bin (https://www.netis-systems.com/support/downinfo.html?id=35) * netis_NC63_v4_Bangladesh-V3.0.0.3889.bin (https://www.netis-systems.com/support/downinfo.html?id=35) * Netis_NC63-V3.0.0.3833.bin (https://www.netisru.com/support/downinfo.html?id=35) * netis_app_BeeWiFi_NC63_v4_Bangladesh-V3.0.0.3503.bin * netis_NC65_V3.0.0.3749.bin * Netis_NC65_Bangladesh-V3.0.0.3508.bin (https://www.netis-systems.com/support/downinfo.html?id=34) * Netis_NC65v2-V3.0.0.3800.bin (https://www.netisru.com/support/downinfo.html?id=34) * netis_NX10_V2.0.1.3582_fw.bin * netis_NX10_V2.0.1.3643.bin * Netis_NX10_v1_Bangladesh-V3.0.0.4142.bin (https://www.netis-systems.com/support/downinfo.html?id=33) * netis_NX10-V3.0.1.4205.bin (https://www.netisru.com/support/downinfo.html?id=33) * netis_app_BeeWiFi_NC21_v4_Bangladesh-V3.0.0.3329.bin * netis_app_BeeWiFi_NC21_v4_Bangladesh-V3.0.0.3500.bin * Netis_NC21_v2_Bangladesh-V3.0.0.3854.bin (https://www.netis-systems.com/support/downinfo.html?id=40) * GLC_ALPHA_AC3-V3.0.2.115.bin (https://drive.google.com/drive/folders/1P69yUfzeZeR6oABmIdcJ6fG57-Xjrzx6) * potentially others... Author(s) h00die-gr3y <[email protected]> Platform Linux Architectures mipsle Development Source Code History
  14. Oracle Linux: CVE-2024-56539: ELSA-2025-20095: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 12/27/2024 Created 02/13/2025 Added 02/11/2025 Modified 02/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan() Replace one-element array with a flexible-array member in `struct mwifiex_ie_types_wildcard_ssid_params` to fix the following warning on a MT8173 Chromebook (mt8173-elm-hana): [356.775250] ------------[ cut here ]------------ [356.784543] memcpy: detected field-spanning write (size 6) of single field &quot;wildcard_ssid_tlv-&gt;ssid&quot; at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1) [356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex] The &quot;(size 6)&quot; above is exactly the length of the SSID of the network this device was connected to. The source of the warning looks like: ssid_len = user_scan_in-&gt;ssid_list[i].ssid_len; [...] memcpy(wildcard_ssid_tlv-&gt;ssid, user_scan_in-&gt;ssid_list[i].ssid, ssid_len); There is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on this struct, but it already didn&apos;t account for the size of the one-element array, so it doesn&apos;t need to be changed. Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-56539 CVE - 2024-56539 ELSA-2025-20095 ELSA-2025-20100
  15. Oracle Linux: CVE-2024-56548: ELSA-2025-20095: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 12/27/2024 Created 02/13/2025 Added 02/11/2025 Modified 02/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: hfsplus: don&apos;t query the device logical block size multiple times Devices block sizes may change. One of these cases is a loop device by using ioctl LOOP_SET_BLOCK_SIZE. While this may cause other issues like IO being rejected, in the case of hfsplus, it will allocate a block by using that size and potentially write out-of-bounds when hfsplus_read_wrapper calls hfsplus_submit_bio and the latter function reads a different io_size. Using a new min_io_size initally set to sb_min_blocksize works for the purposes of the original fix, since it will be set to the max between HFSPLUS_SECTOR_SIZE and the first seen logical block size. We still use the max between HFSPLUS_SECTOR_SIZE and min_io_size in case the latter is not initialized. Tested by mounting an hfsplus filesystem with loop block sizes 512, 1024 and 4096. The produced KASAN report before the fix looks like this: [419.944641] ================================================================== [419.945655] BUG: KASAN: slab-use-after-free in hfsplus_read_wrapper+0x659/0xa0a [419.946703] Read of size 2 at addr ffff88800721fc00 by task repro/10678 [419.947612] [419.947846] CPU: 0 UID: 0 PID: 10678 Comm: repro Not tainted 6.12.0-rc5-00008-gdf56e0f2f3ca #84 [419.949007] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [419.950035] Call Trace: [419.950384]&lt;TASK&gt; [419.950676]dump_stack_lvl+0x57/0x78 [419.951212]? hfsplus_read_wrapper+0x659/0xa0a [419.951830]print_report+0x14c/0x49e [419.952361]? __virt_addr_valid+0x267/0x278 [419.952979]? kmem_cache_debug_flags+0xc/0x1d [419.953561]? hfsplus_read_wrapper+0x659/0xa0a [419.954231]kasan_report+0x89/0xb0 [419.954748]? hfsplus_read_wrapper+0x659/0xa0a [419.955367]hfsplus_read_wrapper+0x659/0xa0a [419.955948]? __pfx_hfsplus_read_wrapper+0x10/0x10 [419.956618]? do_raw_spin_unlock+0x59/0x1a9 [419.957214]? _raw_spin_unlock+0x1a/0x2e [419.957772]hfsplus_fill_super+0x348/0x1590 [419.958355]? hlock_class+0x4c/0x109 [419.958867]? __pfx_hfsplus_fill_super+0x10/0x10 [419.959499]? __pfx_string+0x10/0x10 [419.960006]? lock_acquire+0x3e2/0x454 [419.960532]? bdev_name.constprop.0+0xce/0x243 [419.961129]? __pfx_bdev_name.constprop.0+0x10/0x10 [419.961799]? pointer+0x3f0/0x62f [419.962277]? __pfx_pointer+0x10/0x10 [419.962761]? vsnprintf+0x6c4/0xfba [419.963178]? __pfx_vsnprintf+0x10/0x10 [419.963621]? setup_bdev_super+0x376/0x3b3 [419.964029]? snprintf+0x9d/0xd2 [419.964344]? __pfx_snprintf+0x10/0x10 [419.964675]? lock_acquired+0x45c/0x5e9 [419.965016]? set_blocksize+0x139/0x1c1 [419.965381]? sb_set_blocksize+0x6d/0xae [419.965742]? __pfx_hfsplus_fill_super+0x10/0x10 [419.966179]mount_bdev+0x12f/0x1bf [419.966512]? __pfx_mount_bdev+0x10/0x10 [419.966886]? vfs_parse_fs_string+0xce/0x111 [419.967293]? __pfx_vfs_parse_fs_string+0x10/0x10 [419.967702]? __pfx_hfsplus_mount+0x10/0x10 [419.968073]legacy_get_tree+0x104/0x178 [419.968414]vfs_get_tree+0x86/0x296 [419.968751]path_mount+0xba3/0xd0b [419.969157]? __pfx_path_mount+0x10/0x10 [419.969594]? kmem_cache_free+0x1e2/0x260 [419.970311]do_mount+0x99/0xe0 [419.970630]? __pfx_do_mount+0x10/0x10 [419.971008]__do_sys_mount+0x199/0x1c9 [419.971397]do_syscall_64+0xd0/0x135 [419.971761]entry_SYSCALL_64_after_hwframe+0x76/0x7e [419.972233] RIP: 0033:0x7c3cb812972e [419.972564] Code: 48 8b 0d f5 46 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d c2 46 0d 00 f7 d8 64 89 01 48 [419.974371] RSP: 002b:00007ffe30632548 EFLAGS: 00000286 ORIG_RAX: 00000000000000a5 [419.975048] RAX: ffffffffffffffda RBX: 00007ffe306328d8 RCX: 00007c3cb812972e [419.975701] RDX: 0000000020000000 RSI: 0000000020000c80 RDI: ---truncated--- Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-56548 CVE - 2024-56548 ELSA-2025-20095 ELSA-2025-20100
  16. VMware Photon OS: CVE-2024-56600 Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 12/27/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description In the Linux kernel, the following vulnerability has been resolved: net: inet6: do not leave a dangling sk pointer in inet6_create() sock_init_data() attaches the allocated sk pointer to the provided sock object. If inet6_create() fails later, the sk object is released, but the sock object retains the dangling sk pointer, which may cause use-after-free later. Clear the sock sk pointer on error. Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-56600 CVE - 2024-56600
  17. Oracle Linux: CVE-2024-56578: ELSA-2025-20095: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 12/27/2024 Created 02/13/2025 Added 02/11/2025 Modified 02/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: media: imx-jpeg: Set video drvdata before register video device The video drvdata should be set before the video device is registered, otherwise video_drvdata() may return NULL in the open() file ops, and led to oops. Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-56578 CVE - 2024-56578 ELSA-2025-20095
  18. Amazon Linux AMI 2: CVE-2024-53206: Security patch for kernel (ALASKERNEL-5.15-2025-061) Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 12/27/2024 Created 01/28/2025 Added 01/27/2025 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: tcp: Fix use-after-free of nreq in reqsk_timer_handler(). The cited commit replaced inet_csk_reqsk_queue_drop_and_put() with __inet_csk_reqsk_queue_drop() and reqsk_put() in reqsk_timer_handler(). Then, oreq should be passed to reqsk_put() instead of req; otherwise use-after-free of nreq could happen when reqsk is migrated but the retry attempt failed (e.g. due to timeout). Let's pass oreq to reqsk_put(). Solution(s) amazon-linux-ami-2-upgrade-bpftool amazon-linux-ami-2-upgrade-bpftool-debuginfo amazon-linux-ami-2-upgrade-kernel amazon-linux-ami-2-upgrade-kernel-debuginfo amazon-linux-ami-2-upgrade-kernel-debuginfo-common-aarch64 amazon-linux-ami-2-upgrade-kernel-debuginfo-common-x86_64 amazon-linux-ami-2-upgrade-kernel-devel amazon-linux-ami-2-upgrade-kernel-headers amazon-linux-ami-2-upgrade-kernel-livepatch-5-15-176-118-170 amazon-linux-ami-2-upgrade-kernel-tools amazon-linux-ami-2-upgrade-kernel-tools-debuginfo amazon-linux-ami-2-upgrade-kernel-tools-devel amazon-linux-ami-2-upgrade-perf amazon-linux-ami-2-upgrade-perf-debuginfo amazon-linux-ami-2-upgrade-python-perf amazon-linux-ami-2-upgrade-python-perf-debuginfo References https://attackerkb.com/topics/cve-2024-53206 AL2/ALASKERNEL-5.15-2025-061 CVE - 2024-53206
  19. Debian: CVE-2024-56625: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 12/27/2024 Created 01/14/2025 Added 01/13/2025 Modified 01/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: can: dev: can_set_termination(): allow sleeping GPIOs In commit 6e86a1543c37 ("can: dev: provide optional GPIO based termination support") GPIO based termination support was added. For no particular reason that patch uses gpiod_set_value() to set the GPIO. This leads to the following warning, if the systems uses a sleeping GPIO, i.e. behind an I2C port expander: | WARNING: CPU: 0 PID: 379 at /drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x50/0x6c | CPU: 0 UID: 0 PID: 379 Comm: ip Not tainted 6.11.0-20241016-1 #1 823affae360cc91126e4d316d7a614a8bf86236c Replace gpiod_set_value() by gpiod_set_value_cansleep() to allow the use of sleeping GPIOs. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-56625 CVE - 2024-56625
  20. Debian: CVE-2024-56651: linux -- security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 12/27/2024 Created 01/14/2025 Added 01/13/2025 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: can: hi311x: hi3110_can_ist(): fix potential use-after-free The commit a22bd630cfff ("can: hi311x: do not report txerr and rxerr during bus-off") removed the reporting of rxerr and txerr even in case of correct operation (i. e. not bus-off). The error count information added to the CAN frame after netif_rx() is a potential use after free, since there is no guarantee that the skb is in the same state. It might be freed or reused. Fix the issue by postponing the netif_rx() call in case of txerr and rxerr reporting. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-56651 CVE - 2024-56651
  21. Amazon Linux AMI 2: CVE-2024-56658: Security patch for kernel (ALASKERNEL-5.15-2025-062) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 12/27/2024 Created 02/05/2025 Added 02/04/2025 Modified 02/04/2025 Description In the Linux kernel, the following vulnerability has been resolved: net: defer final 'struct net' free in netns dismantle Ilya reported a slab-use-after-free in dst_destroy [1] Issue is in xfrm6_net_init() and xfrm4_net_init() : They copy xfrm[46]_dst_ops_template into net->xfrm.xfrm[46]_dst_ops. But net structure might be freed before all the dst callbacks are called. So when dst_destroy() calls later : if (dst->ops->destroy) dst->ops->destroy(dst); dst->ops points to the old net->xfrm.xfrm[46]_dst_ops, which has been freed. See a relevant issue fixed in : ac888d58869b ("net: do not delay dst_entries_add() in dst_release()") A fix is to queue the 'struct net' to be freed after one another cleanup_net() round (and existing rcu_barrier()) [1] BUG: KASAN: slab-use-after-free in dst_destroy (net/core/dst.c:112) Read of size 8 at addr ffff8882137ccab0 by task swapper/37/0 Dec 03 05:46:18 kernel: CPU: 37 UID: 0 PID: 0 Comm: swapper/37 Kdump: loaded Not tainted 6.12.0 #67 Hardware name: Red Hat KVM/RHEL, BIOS 1.16.1-1.el9 04/01/2014 Call Trace: <IRQ> dump_stack_lvl (lib/dump_stack.c:124) print_address_description.constprop.0 (mm/kasan/report.c:378) ? dst_destroy (net/core/dst.c:112) print_report (mm/kasan/report.c:489) ? dst_destroy (net/core/dst.c:112) ? kasan_addr_to_slab (mm/kasan/common.c:37) kasan_report (mm/kasan/report.c:603) ? dst_destroy (net/core/dst.c:112) ? rcu_do_batch (kernel/rcu/tree.c:2567) dst_destroy (net/core/dst.c:112) rcu_do_batch (kernel/rcu/tree.c:2567) ? __pfx_rcu_do_batch (kernel/rcu/tree.c:2491) ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4339 kernel/locking/lockdep.c:4406) rcu_core (kernel/rcu/tree.c:2825) handle_softirqs (kernel/softirq.c:554) __irq_exit_rcu (kernel/softirq.c:589 kernel/softirq.c:428 kernel/softirq.c:637) irq_exit_rcu (kernel/softirq.c:651) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1049 arch/x86/kernel/apic/apic.c:1049) </IRQ> <TASK> asm_sysvec_apic_timer_interrupt (./arch/x86/include/asm/idtentry.h:702) RIP: 0010:default_idle (./arch/x86/include/asm/irqflags.h:37 ./arch/x86/include/asm/irqflags.h:92 arch/x86/kernel/process.c:743) Code: 00 4d 29 c8 4c 01 c7 4c 29 c2 e9 6e ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 0f 00 2d c7 c9 27 00 fb f4 <fa> c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 RSP: 0018:ffff888100d2fe00 EFLAGS: 00000246 RAX: 00000000001870ed RBX: 1ffff110201a5fc2 RCX: ffffffffb61a3e46 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffb3d4d123 RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed11c7e1835d R10: ffff888e3f0c1aeb R11: 0000000000000000 R12: 0000000000000000 R13: ffff888100d20000 R14: dffffc0000000000 R15: 0000000000000000 ? ct_kernel_exit.constprop.0 (kernel/context_tracking.c:148) ? cpuidle_idle_call (kernel/sched/idle.c:186) default_idle_call (./include/linux/cpuidle.h:143 kernel/sched/idle.c:118) cpuidle_idle_call (kernel/sched/idle.c:186) ? __pfx_cpuidle_idle_call (kernel/sched/idle.c:168) ? lock_release (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5848) ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4347 kernel/locking/lockdep.c:4406) ? tsc_verify_tsc_adjust (arch/x86/kernel/tsc_sync.c:59) do_idle (kernel/sched/idle.c:326) cpu_startup_entry (kernel/sched/idle.c:423 (discriminator 1)) start_secondary (arch/x86/kernel/smpboot.c:202 arch/x86/kernel/smpboot.c:282) ? __pfx_start_secondary (arch/x86/kernel/smpboot.c:232) ? soft_restart_cpu (arch/x86/kernel/head_64.S:452) common_startup_64 (arch/x86/kernel/head_64.S:414) </TASK> Dec 03 05:46:18 kernel: Allocated by task 12184: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (./arch/x86/include/asm/current.h:49 mm/kasan/common.c:60 mm/kasan/common.c:69) __kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345) kmem_cache_alloc_noprof (mm/slub.c:4085 mm/slub.c:4134 mm/slub.c:4141) copy_net_ns (net/core/net_namespace.c:421 net/core/net_namespace.c:480) create_new_namespaces ---truncated--- Solution(s) amazon-linux-ami-2-upgrade-bpftool amazon-linux-ami-2-upgrade-bpftool-debuginfo amazon-linux-ami-2-upgrade-kernel amazon-linux-ami-2-upgrade-kernel-debuginfo amazon-linux-ami-2-upgrade-kernel-debuginfo-common-aarch64 amazon-linux-ami-2-upgrade-kernel-debuginfo-common-x86_64 amazon-linux-ami-2-upgrade-kernel-devel amazon-linux-ami-2-upgrade-kernel-headers amazon-linux-ami-2-upgrade-kernel-livepatch-5-15-176-118-178 amazon-linux-ami-2-upgrade-kernel-tools amazon-linux-ami-2-upgrade-kernel-tools-debuginfo amazon-linux-ami-2-upgrade-kernel-tools-devel amazon-linux-ami-2-upgrade-perf amazon-linux-ami-2-upgrade-perf-debuginfo amazon-linux-ami-2-upgrade-python-perf amazon-linux-ami-2-upgrade-python-perf-debuginfo References https://attackerkb.com/topics/cve-2024-56658 AL2/ALASKERNEL-5.15-2025-062 CVE - 2024-56658
  22. Oracle Linux: CVE-2024-56603: ELSA-2025-20095: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 6 CVSS (AV:L/AC:L/Au:S/C:C/I:P/A:C) Published 12/27/2024 Created 02/13/2025 Added 02/11/2025 Modified 02/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: net: af_can: do not leave a dangling sk pointer in can_create() On error can_create() frees the allocated sk object, but sock_init_data() has already attached it to the provided sock object. This will leave a dangling sk pointer in the sock object and may cause use-after-free later. Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-56603 CVE - 2024-56603 ELSA-2025-20095 ELSA-2025-20100
  23. Debian: CVE-2020-6923: hplip -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 12/27/2024 Created 12/28/2024 Added 12/27/2024 Modified 12/27/2024 Description The HP Linux Imaging and Printing (HPLIP) software may potentially be affected by memory buffer overflow. Solution(s) debian-upgrade-hplip References https://attackerkb.com/topics/cve-2020-6923 CVE - 2020-6923
  24. Debian: CVE-2024-53233: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 12/27/2024 Created 01/14/2025 Added 01/13/2025 Modified 01/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: unicode: Fix utf8_load() error path utf8_load() requests the symbol "utf8_data_table" and then checks if the requested UTF-8 version is supported. If it's unsupported, it tries to put the data table using symbol_put(). If an unsupported version is requested, symbol_put() fails like this: kernel BUG at kernel/module/main.c:786! RIP: 0010:__symbol_put+0x93/0xb0 Call Trace: <TASK> ? __die_body.cold+0x19/0x27 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x65/0x80 ? __symbol_put+0x93/0xb0 ? exc_invalid_op+0x51/0x70 ? __symbol_put+0x93/0xb0 ? asm_exc_invalid_op+0x1a/0x20 ? __pfx_cmp_name+0x10/0x10 ? __symbol_put+0x93/0xb0 ? __symbol_put+0x62/0xb0 utf8_load+0xf8/0x150 That happens because symbol_put() expects the unique string that identify the symbol, instead of a pointer to the loaded symbol. Fix that by using such string. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-53233 CVE - 2024-53233
  25. Debian: CVE-2024-56658: linux -- security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 12/27/2024 Created 01/14/2025 Added 01/13/2025 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: net: defer final 'struct net' free in netns dismantle Ilya reported a slab-use-after-free in dst_destroy [1] Issue is in xfrm6_net_init() and xfrm4_net_init() : They copy xfrm[46]_dst_ops_template into net->xfrm.xfrm[46]_dst_ops. But net structure might be freed before all the dst callbacks are called. So when dst_destroy() calls later : if (dst->ops->destroy) dst->ops->destroy(dst); dst->ops points to the old net->xfrm.xfrm[46]_dst_ops, which has been freed. See a relevant issue fixed in : ac888d58869b ("net: do not delay dst_entries_add() in dst_release()") A fix is to queue the 'struct net' to be freed after one another cleanup_net() round (and existing rcu_barrier()) [1] BUG: KASAN: slab-use-after-free in dst_destroy (net/core/dst.c:112) Read of size 8 at addr ffff8882137ccab0 by task swapper/37/0 Dec 03 05:46:18 kernel: CPU: 37 UID: 0 PID: 0 Comm: swapper/37 Kdump: loaded Not tainted 6.12.0 #67 Hardware name: Red Hat KVM/RHEL, BIOS 1.16.1-1.el9 04/01/2014 Call Trace: <IRQ> dump_stack_lvl (lib/dump_stack.c:124) print_address_description.constprop.0 (mm/kasan/report.c:378) ? dst_destroy (net/core/dst.c:112) print_report (mm/kasan/report.c:489) ? dst_destroy (net/core/dst.c:112) ? kasan_addr_to_slab (mm/kasan/common.c:37) kasan_report (mm/kasan/report.c:603) ? dst_destroy (net/core/dst.c:112) ? rcu_do_batch (kernel/rcu/tree.c:2567) dst_destroy (net/core/dst.c:112) rcu_do_batch (kernel/rcu/tree.c:2567) ? __pfx_rcu_do_batch (kernel/rcu/tree.c:2491) ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4339 kernel/locking/lockdep.c:4406) rcu_core (kernel/rcu/tree.c:2825) handle_softirqs (kernel/softirq.c:554) __irq_exit_rcu (kernel/softirq.c:589 kernel/softirq.c:428 kernel/softirq.c:637) irq_exit_rcu (kernel/softirq.c:651) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1049 arch/x86/kernel/apic/apic.c:1049) </IRQ> <TASK> asm_sysvec_apic_timer_interrupt (./arch/x86/include/asm/idtentry.h:702) RIP: 0010:default_idle (./arch/x86/include/asm/irqflags.h:37 ./arch/x86/include/asm/irqflags.h:92 arch/x86/kernel/process.c:743) Code: 00 4d 29 c8 4c 01 c7 4c 29 c2 e9 6e ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 0f 00 2d c7 c9 27 00 fb f4 <fa> c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 RSP: 0018:ffff888100d2fe00 EFLAGS: 00000246 RAX: 00000000001870ed RBX: 1ffff110201a5fc2 RCX: ffffffffb61a3e46 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffb3d4d123 RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed11c7e1835d R10: ffff888e3f0c1aeb R11: 0000000000000000 R12: 0000000000000000 R13: ffff888100d20000 R14: dffffc0000000000 R15: 0000000000000000 ? ct_kernel_exit.constprop.0 (kernel/context_tracking.c:148) ? cpuidle_idle_call (kernel/sched/idle.c:186) default_idle_call (./include/linux/cpuidle.h:143 kernel/sched/idle.c:118) cpuidle_idle_call (kernel/sched/idle.c:186) ? __pfx_cpuidle_idle_call (kernel/sched/idle.c:168) ? lock_release (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5848) ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4347 kernel/locking/lockdep.c:4406) ? tsc_verify_tsc_adjust (arch/x86/kernel/tsc_sync.c:59) do_idle (kernel/sched/idle.c:326) cpu_startup_entry (kernel/sched/idle.c:423 (discriminator 1)) start_secondary (arch/x86/kernel/smpboot.c:202 arch/x86/kernel/smpboot.c:282) ? __pfx_start_secondary (arch/x86/kernel/smpboot.c:232) ? soft_restart_cpu (arch/x86/kernel/head_64.S:452) common_startup_64 (arch/x86/kernel/head_64.S:414) </TASK> Dec 03 05:46:18 kernel: Allocated by task 12184: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (./arch/x86/include/asm/current.h:49 mm/kasan/common.c:60 mm/kasan/common.c:69) __kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345) kmem_cache_alloc_noprof (mm/slub.c:4085 mm/slub.c:4134 mm/slub.c:4141) copy_net_ns (net/core/net_namespace.c:421 net/core/net_namespace.c:480) create_new_namespaces ---truncated--- Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-56658 CVE - 2024-56658