{"schema_version":"1.7.2","id":"OESA-2025-1065","modified":"2025-01-17T14:08:45Z","published":"2025-01-17T14:08:45Z","upstream":["CVE-2024-50199","CVE-2024-53171","CVE-2024-53190","CVE-2024-53237","CVE-2024-53239","CVE-2024-56567","CVE-2024-56595","CVE-2024-56597","CVE-2024-56631","CVE-2024-56633","CVE-2024-56662","CVE-2024-56701","CVE-2024-56759"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  mm/swapfile: skip HugeTLB pages for unuse_vma  I got a bad pud error and lost a 1GB HugeTLB when calling swapoff.  The problem can be reproduced by the following steps:   1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory.  2. Swapout the above anonymous memory.  3. run swapoff and we will get a bad pud error in kernel message:    mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7)  We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace.  And therefore the HugeTLB pages will never be freed because we lost it from page table.  We can skip HugeTLB pages for unuse_vma to fix it.(CVE-2024-50199)\r\n\r\nIn 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-\u0026gt;parent`. A further deletion of other nodes in the tree (which also could free the nodes), the aforementioned node\u0026apos;s `znode-\u0026gt;cparent` could still point to a freed node. This `znode-\u0026gt;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-\u0026gt;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_new          zn  `zn-\u0026gt;parent` has now been moved to `zp2`, *but* `zn-\u0026gt;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-\u0026gt;cparent` that wrongly points to the already freed `zp1`. `ubifs_copy_hash()` thus gets wrongly called with `znode-\u0026gt;cparent-\u0026gt;zbranch[znode-\u0026gt;iip].hash` that triggers the use-after-free!  Fix this by explicitly setting `znode-\u0026gt;cparent` to `NULL` in `get_znodes_to_commit()` for the root node. The search for the dirty nodes ---truncated---(CVE-2024-53171)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failures  Syzkaller reported a hung task with uevent_show() on stack trace. That specific issue was addressed by another commit [0], but even with that fix applied (for example, running v6.12-rc5) we face another type of hung task that comes from the same reproducer [1]. By investigating that, we could narrow it to the following path:  (a) Syzkaller emulates a Realtek USB WiFi adapter using raw-gadget and dummy_hcd infrastructure.  (b) During the probe of rtl8192cu, the driver ends-up performing an efuse read procedure (which is related to EEPROM load IIUC), and here lies the issue: the function read_efuse() calls read_efuse_byte() many times, as loop iterations depending on the efuse size (in our example, 512 in total).  This procedure for reading efuse bytes relies in a loop that performs an I/O read up to *10k* times in case of failures. We measured the time of the loop inside read_efuse_byte() alone, and in this reproducer (which involves the dummy_hcd emulation layer), it takes 15 seconds each. As a consequence, we have the driver stuck in its probe routine for big time, exposing a stack trace like below if we attempt to reboot the system, for example:  task:kworker/0:3 state:D stack:0 pid:662 tgid:662 ppid:2 flags:0x00004000 Workqueue: usb_hub_wq hub_event Call Trace:  __schedule+0xe22/0xeb6  schedule_timeout+0xe7/0x132  __wait_for_common+0xb5/0x12e  usb_start_wait_urb+0xc5/0x1ef  ? usb_alloc_urb+0x95/0xa4  usb_control_msg+0xff/0x184  _usbctrl_vendorreq_sync+0xa0/0x161  _usb_read_sync+0xb3/0xc5  read_efuse_byte+0x13c/0x146  read_efuse+0x351/0x5f0  efuse_read_all_map+0x42/0x52  rtl_efuse_shadow_map_update+0x60/0xef  rtl_get_hwinfo+0x5d/0x1c2  rtl92cu_read_eeprom_info+0x10a/0x8d5  ? rtl92c_read_chip_version+0x14f/0x17e  rtl_usb_probe+0x323/0x851  usb_probe_interface+0x278/0x34b  really_probe+0x202/0x4a4  __driver_probe_device+0x166/0x1b2  driver_probe_device+0x2f/0xd8  [...]  We propose hereby to drastically reduce the attempts of doing the I/O reads in case of failures, restricted to USB devices (given that they\u0026apos;re inherently slower than PCIe ones). By retrying up to 10 times (instead of 10000), we got reponsiveness in the reproducer, while seems reasonable to believe that there\u0026apos;s no sane USB device implementation in the field requiring this amount of retries at every I/O read in order to properly work. Based on that assumption, it\u0026apos;d be good to have it backported to stable but maybe not since driver implementation (the 10k number comes from day 0), perhaps up to 6.x series makes sense.  [0] Commit 15fffc6a5624 (\u0026quot;driver core: Fix uevent_show() vs driver detach race\u0026quot;)  [1] A note about that: this syzkaller report presents multiple reproducers that differs by the type of emulated USB device. For this specific case, check the entry from 2024/08/08 06:23 in the list of crashes; the C repro is available at https://syzkaller.appspot.com/text?tag=ReproC\u0026amp;x=1521fc83980000.(CVE-2024-53190)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  Bluetooth: fix use-after-free in device_for_each_child()  Syzbot has reported the following KASAN splat:  BUG: KASAN: slab-use-after-free in device_for_each_child+0x18f/0x1a0 Read of size 8 at addr ffff88801f605308 by task kbnepd bnep0/4980  CPU: 0 UID: 0 PID: 4980 Comm: kbnepd bnep0 Not tainted 6.12.0-rc4-00161-gae90f6a6170d #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 Call Trace:  \u0026lt;TASK\u0026gt;  dump_stack_lvl+0x100/0x190  ? device_for_each_child+0x18f/0x1a0  print_report+0x13a/0x4cb  ? __virt_addr_valid+0x5e/0x590  ? __phys_addr+0xc6/0x150  ? device_for_each_child+0x18f/0x1a0  kasan_report+0xda/0x110  ? device_for_each_child+0x18f/0x1a0  ? __pfx_dev_memalloc_noio+0x10/0x10  device_for_each_child+0x18f/0x1a0  ? __pfx_device_for_each_child+0x10/0x10  pm_runtime_set_memalloc_noio+0xf2/0x180  netdev_unregister_kobject+0x1ed/0x270  unregister_netdevice_many_notify+0x123c/0x1d80  ? __mutex_trylock_common+0xde/0x250  ? __pfx_unregister_netdevice_many_notify+0x10/0x10  ? trace_contention_end+0xe6/0x140  ? __mutex_lock+0x4e7/0x8f0  ? __pfx_lock_acquire.part.0+0x10/0x10  ? rcu_is_watching+0x12/0xc0  ? unregister_netdev+0x12/0x30  unregister_netdevice_queue+0x30d/0x3f0  ? __pfx_unregister_netdevice_queue+0x10/0x10  ? __pfx_down_write+0x10/0x10  unregister_netdev+0x1c/0x30  bnep_session+0x1fb3/0x2ab0  ? __pfx_bnep_session+0x10/0x10  ? __pfx_lock_release+0x10/0x10  ? __pfx_woken_wake_function+0x10/0x10  ? __kthread_parkme+0x132/0x200  ? __pfx_bnep_session+0x10/0x10  ? kthread+0x13a/0x370  ? __pfx_bnep_session+0x10/0x10  kthread+0x2b7/0x370  ? __pfx_kthread+0x10/0x10  ret_from_fork+0x48/0x80  ? __pfx_kthread+0x10/0x10  ret_from_fork_asm+0x1a/0x30  \u0026lt;/TASK\u0026gt;  Allocated by task 4974:  kasan_save_stack+0x30/0x50  kasan_save_track+0x14/0x30  __kasan_kmalloc+0xaa/0xb0  __kmalloc_noprof+0x1d1/0x440  hci_alloc_dev_priv+0x1d/0x2820  __vhci_create_device+0xef/0x7d0  vhci_write+0x2c7/0x480  vfs_write+0x6a0/0xfc0  ksys_write+0x12f/0x260  do_syscall_64+0xc7/0x250  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Freed by task 4979:  kasan_save_stack+0x30/0x50  kasan_save_track+0x14/0x30  kasan_save_free_info+0x3b/0x60  __kasan_slab_free+0x4f/0x70  kfree+0x141/0x490  hci_release_dev+0x4d9/0x600  bt_host_release+0x6a/0xb0  device_release+0xa4/0x240  kobject_put+0x1ec/0x5a0  put_device+0x1f/0x30  vhci_release+0x81/0xf0  __fput+0x3f6/0xb30  task_work_run+0x151/0x250  do_exit+0xa79/0x2c30  do_group_exit+0xd5/0x2a0  get_signal+0x1fcd/0x2210  arch_do_signal_or_restart+0x93/0x780  syscall_exit_to_user_mode+0x140/0x290  do_syscall_64+0xd4/0x250  entry_SYSCALL_64_after_hwframe+0x77/0x7f  In \u0026apos;hci_conn_del_sysfs()\u0026apos;, \u0026apos;device_unregister()\u0026apos; may be called when an underlying (kobject) reference counter is greater than 1. This means that reparenting (happened when the device is actually freed) is delayed and, during that delay, parent controller device (hciX) may be deleted. Since the latter may create a dangling pointer to freed parent, avoid that scenario by reparenting to NULL explicitly.(CVE-2024-53237)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ALSA: 6fire: Release resources at card release  The current 6fire code tries to release the resources right after the call of usb6fire_chip_abort().  But at this moment, the card object might be still in use (as we\u0026apos;re calling snd_card_free_when_closed()).  For avoid potential UAFs, move the release of resources to the card\u0026apos;s private_free instead of the manual call of usb6fire_chip_destroy() at the USB disconnect callback.(CVE-2024-53239)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ad7780: fix division by zero in ad7780_write_raw()  In the ad7780_write_raw() , val2 can be zero, which might lead to a division by zero error in DIV_ROUND_CLOSEST(). The ad7780_write_raw() is based on iio_info\u0026apos;s write_raw. While val is explicitly declared that can be zero (in read mode), val2 is not specified to be non-zero.(CVE-2024-56567)\r\n\r\nIn 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.(CVE-2024-56595)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  jfs: fix shift-out-of-bounds in dbSplit  When dmt_budmin is less than zero, it causes errors in the later stages. Added a check to return an error beforehand in dbAllocCtl itself.(CVE-2024-56597)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  scsi: sg: Fix slab-use-after-free read in sg_release()  Fix a use-after-free bug in sg_release(), detected by syzbot with KASAN:  BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5838 __mutex_unlock_slowpath+0xe2/0x750 kernel/locking/mutex.c:912 sg_release+0x1f4/0x2e0 drivers/scsi/sg.c:407  In sg_release(), the function kref_put(\u0026amp;sfp-\u0026gt;f_ref, sg_remove_sfp) is called before releasing the open_rel_lock mutex. The kref_put() call may decrement the reference count of sfp to zero, triggering its cleanup through sg_remove_sfp(). This cleanup includes scheduling deferred work via sg_remove_sfp_usercontext(), which ultimately frees sfp.  After kref_put(), sg_release() continues to unlock open_rel_lock and may reference sfp or sdp. If sfp has already been freed, this results in a slab-use-after-free error.  Move the kref_put(\u0026amp;sfp-\u0026gt;f_ref, sg_remove_sfp) call after unlocking the open_rel_lock mutex. This ensures:   - No references to sfp or sdp occur after the reference count is    decremented.   - Cleanup functions such as sg_remove_sfp() and    sg_remove_sfp_usercontext() can safely execute without impacting the    mutex handling in sg_release().  The fix has been tested and validated by syzbot. This patch closes the bug reported at the following syzkaller link and ensures proper sequencing of resource cleanup and mutex operations, eliminating the risk of use-after-free errors in sg_release().(CVE-2024-56631)\r\n\r\nIn 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-\u0026gt;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 \u0026lt; 0), we may   miss uncharging (msg-\u0026gt;sg.size - apply_bytes) bytes.  [...] 415 tosend = msg-\u0026gt;sg.size; 416 if (psock-\u0026gt;apply_bytes \u0026amp;\u0026amp; psock-\u0026gt;apply_bytes \u0026lt; tosend) 417   tosend = psock-\u0026gt;apply_bytes; [...] 443 sk_msg_return(sk, msg, tosend); 444 release_sock(sk); 446 origsize = msg-\u0026gt;sg.size; 447 ret = tcp_bpf_sendmsg_redir(sk_redir, redir_ingress, 448                             msg, tosend, flags); 449 sent = origsize - msg-\u0026gt;sg.size; [...] 454 lock_sock(sk); 455 if (unlikely(ret \u0026lt; 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: \u0026lt;TASK\u0026gt; ? __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 \u0026lt;/TASK\u0026gt; ---[ 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 \u0026lt; 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-\u0026gt;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.(CVE-2024-56633)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  acpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctl  Fix an issue detected by syzbot with KASAN:  BUG: KASAN: vmalloc-out-of-bounds in cmd_to_func drivers/acpi/nfit/ core.c:416 [inline] BUG: KASAN: vmalloc-out-of-bounds in acpi_nfit_ctl+0x20e8/0x24a0 drivers/acpi/nfit/core.c:459  The issue occurs in cmd_to_func when the call_pkg-\u0026gt;nd_reserved2 array is accessed without verifying that call_pkg points to a buffer that is appropriately sized as a struct nd_cmd_pkg. This can lead to out-of-bounds access and undefined behavior if the buffer does not have sufficient space.  To address this, a check was added in acpi_nfit_ctl() to ensure that buf is not NULL and that buf_len is less than sizeof(*call_pkg) before accessing it. This ensures safe access to the members of call_pkg, including the nd_reserved2 array.(CVE-2024-56662)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  powerpc/pseries: Fix dtl_access_lock to be a rw_semaphore  The dtl_access_lock needs to be a rw_sempahore, a sleeping lock, because the code calls kmalloc() while holding it, which can sleep:    # echo 1 \u0026gt; /proc/powerpc/vcpudispatch_stats   BUG: sleeping function called from invalid context at include/linux/sched/mm.h:337   in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 199, name: sh   preempt_count: 1, expected: 0   3 locks held by sh/199:    #0: c00000000a0743f8 (sb_writers#3){.+.+}-{0:0}, at: vfs_write+0x324/0x438    #1: c0000000028c7058 (dtl_enable_mutex){+.+.}-{3:3}, at: vcpudispatch_stats_write+0xd4/0x5f4    #2: c0000000028c70b8 (dtl_access_lock){+.+.}-{2:2}, at: vcpudispatch_stats_write+0x220/0x5f4   CPU: 0 PID: 199 Comm: sh Not tainted 6.10.0-rc4 #152   Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries   Call Trace:     dump_stack_lvl+0x130/0x148 (unreliable)     __might_resched+0x174/0x410     kmem_cache_alloc_noprof+0x340/0x3d0     alloc_dtl_buffers+0x124/0x1ac     vcpudispatch_stats_write+0x2a8/0x5f4     proc_reg_write+0xf4/0x150     vfs_write+0xfc/0x438     ksys_write+0x88/0x148     system_call_exception+0x1c4/0x5a0     system_call_common+0xf4/0x258(CVE-2024-56701)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  btrfs: fix use-after-free when COWing tree bock and tracing is enabled  When a COWing a tree block, at btrfs_cow_block(), and we have the tracepoint trace_btrfs_cow_block() enabled and preemption is also enabled (CONFIG_PREEMPT=y), we can trigger a use-after-free in the COWed extent buffer while inside the tracepoint code. This is because in some paths that call btrfs_cow_block(), such as btrfs_search_slot(), we are holding the last reference on the extent buffer @buf so btrfs_force_cow_block() drops the last reference on the @buf extent buffer when it calls free_extent_buffer_stale(buf), which schedules the release of the extent buffer with RCU. This means that if we are on a kernel with preemption, the current task may be preempted before calling trace_btrfs_cow_block() and the extent buffer already released by the time trace_btrfs_cow_block() is called, resulting in a use-after-free.  Fix this by moving the trace_btrfs_cow_block() from btrfs_cow_block() to btrfs_force_cow_block() before the COWed extent buffer is freed. This also has a side effect of invoking the tracepoint in the tree defrag code, at defrag.c:btrfs_realloc_node(), since btrfs_force_cow_block() is called there, but this is fine and it was actually missing there.(CVE-2024-56759)","affected":[{"package":{"ecosystem":"openEuler:22.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-246.0.0.145.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm","kernel-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm","perf-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-246.0.0.145.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm","kernel-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm","perf-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1065"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50199"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53171"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53190"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53237"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53239"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56567"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56595"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56597"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56631"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56633"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56662"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56701"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56759"}],"database_specific":{"severity":"High"}}