跳转到帖子

ISHACK AI BOT

Members
  • 注册日期

  • 上次访问

ISHACK AI BOT 发布的所有帖子

  1. Oracle Linux: CVE-2024-56691: 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/28/2024 Created 02/13/2025 Added 02/11/2025 Modified 02/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C device While design wise the idea of converting the driver to use the hierarchy of the IRQ chips is correct, the implementation has (inherited) flaws. This was unveiled when platform_get_irq() had started WARN() on IRQ 0 that is supposed to be a Linux IRQ number (also known as vIRQ). Rework the driver to respect IRQ domain when creating each MFD device separately, as the domain is not the same for all of them. Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-56691 CVE - 2024-56691 ELSA-2025-20095 ELSA-2025-20100
  2. VMware Photon OS: CVE-2024-56690 Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 12/28/2024 Created 01/21/2025 Added 01/20/2025 Modified 01/29/2025 Description In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY Since commit 8f4f68e788c3 ("crypto: pcrypt - Fix hungtask for PADATA_RESET"), the pcrypt encryption and decryption operations return -EAGAIN when the CPU goes online or offline. In alg_test(), a WARN is generated when pcrypt_aead_decrypt() or pcrypt_aead_encrypt() returns -EAGAIN, the unnecessary panic will occur when panic_on_warn set 1. Fix this issue by calling crypto layer directly without parallelization in that case. Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-56690 CVE - 2024-56690
  3. Debian: CVE-2024-56679: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 12/28/2024 Created 01/14/2025 Added 01/13/2025 Modified 01/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_common.c Add error pointer check after calling otx2_mbox_get_rsp(). Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-56679 CVE - 2024-56679
  4. Oracle Linux: CVE-2024-56694: 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/28/2024 Created 02/13/2025 Added 02/11/2025 Modified 02/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: bpf: fix recursive lock when verdict program return SK_PASS When the stream_verdict program returns SK_PASS, it places the received skb into its own receive queue, but a recursive lock eventually occurs, leading to an operating system deadlock. This issue has been present since v6.9. ''' sk_psock_strp_data_ready write_lock_bh(&sk->sk_callback_lock) strp_data_ready strp_read_sock read_sock -> tcp_read_sock strp_recv cb.rcv_msg -> sk_psock_strp_read # now stream_verdict return SK_PASS without peer sock assign __SK_PASS = sk_psock_map_verd(SK_PASS, NULL) sk_psock_verdict_apply sk_psock_skb_ingress_self sk_psock_skb_ingress_enqueue sk_psock_data_ready read_lock_bh(&sk->sk_callback_lock) <= dead lock ''' This topic has been discussed before, but it has not been fixed. Previous discussion: https://lore.kernel.org/all/[email protected] Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-56694 CVE - 2024-56694 ELSA-2025-20095
  5. VMware Photon OS: CVE-2024-56677 Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 12/28/2024 Created 01/21/2025 Added 01/20/2025 Modified 01/20/2025 Description In the Linux kernel, the following vulnerability has been resolved: powerpc/fadump: Move fadump_cma_init to setup_arch() after initmem_init() During early init CMA_MIN_ALIGNMENT_BYTES can be PAGE_SIZE, since pageblock_order is still zero and it gets initialized later during initmem_init() e.g. setup_arch() -> initmem_init() -> sparse_init() -> set_pageblock_order() One such use case where this causes issue is - early_setup() -> early_init_devtree() -> fadump_reserve_mem() -> fadump_cma_init() This causes CMA memory alignment check to be bypassed in cma_init_reserved_mem(). Then later cma_activate_area() can hit a VM_BUG_ON_PAGE(pfn & ((1 << order) - 1)) if the reserved memory area was not pageblock_order aligned. Fix it by moving the fadump_cma_init() after initmem_init(), where other such cma reservations also gets called. <stack trace> ============== page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x10010 flags: 0x13ffff800000000(node=1|zone=0|lastcpupid=0x7ffff) CMA raw: 013ffff800000000 5deadbeef0000100 5deadbeef0000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: VM_BUG_ON_PAGE(pfn & ((1 << order) - 1)) ------------[ cut here ]------------ kernel BUG at mm/page_alloc.c:778! Call Trace: __free_one_page+0x57c/0x7b0 (unreliable) free_pcppages_bulk+0x1a8/0x2c8 free_unref_page_commit+0x3d4/0x4e4 free_unref_page+0x458/0x6d0 init_cma_reserved_pageblock+0x114/0x198 cma_init_reserved_areas+0x270/0x3e0 do_one_initcall+0x80/0x2f8 kernel_init_freeable+0x33c/0x530 kernel_init+0x34/0x26c ret_from_kernel_user_thread+0x14/0x1c Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-56677 CVE - 2024-56677
  6. Debian: CVE-2024-56688: linux -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 12/28/2024 Created 01/14/2025 Added 01/13/2025 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport Since transport->sock has been set to NULL during reset transport, XPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, the xs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request() to dereference the transport->sock that has been set to NULL. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-56688 CVE - 2024-56688
  7. Debian: CVE-2024-56681: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 12/28/2024 Created 01/14/2025 Added 01/13/2025 Modified 01/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: crypto: bcm - add error check in the ahash_hmac_init function The ahash_init functions may return fails. The ahash_hmac_init should not return ok when ahash_init returns error. For an example, ahash_init will return -ENOMEM when allocation memory is error. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-56681 CVE - 2024-56681
  8. Oracle Linux: CVE-2024-56700: 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/28/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: wl128x: Fix atomicity violation in fmc_send_cmd() Atomicity violation occurs when the fmc_send_cmd() function is executed simultaneously with the modification of the fmdev-&gt;resp_skb value. Consider a scenario where, after passing the validity check within the function, a non-null fmdev-&gt;resp_skb variable is assigned a null value. This results in an invalid fmdev-&gt;resp_skb variable passing the validity check. As seen in the later part of the function, skb = fmdev-&gt;resp_skb; when the invalid fmdev-&gt;resp_skb passes the check, a null pointer dereference error may occur at line 478, evt_hdr = (void *)skb-&gt;data; To address this issue, it is recommended to include the validity check of fmdev-&gt;resp_skb within the locked section of the function. This modification ensures that the value of fmdev-&gt;resp_skb does not change during the validation process, thereby maintaining its validity. This possible bug is found by an experimental static analysis tool developed by our team. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-56700 CVE - 2024-56700 ELSA-2025-20095 ELSA-2025-20100
  9. Oracle Linux: CVE-2024-56708: ELSA-2025-20095: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 4 CVSS (AV:L/AC:L/Au:M/C:N/I:N/A:C) Published 12/28/2024 Created 02/13/2025 Added 02/11/2025 Modified 02/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: EDAC/igen6: Avoid segmentation fault on module unload The segmentation fault happens because: During modprobe: 1. In igen6_probe(), igen6_pvt will be allocated with kzalloc() 2. In igen6_register_mci(), mci-&gt;pvt_info will point to &amp;igen6_pvt-&gt;imc[mc] During rmmod: 1. In mci_release() in edac_mc.c, it will kfree(mci-&gt;pvt_info) 2. In igen6_remove(), it will kfree(igen6_pvt); Fix this issue by setting mci-&gt;pvt_info to NULL to avoid the double kfree. Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-56708 CVE - 2024-56708 ELSA-2025-20095
  10. VMware Photon OS: CVE-2024-56693 Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 12/28/2024 Created 01/21/2025 Added 01/20/2025 Modified 01/20/2025 Description In the Linux kernel, the following vulnerability has been resolved: brd: defer automatic disk creation until module initialization succeeds My colleague Wupeng found the following problems during fault injection: BUG: unable to handle page fault for address: fffffbfff809d073 PGD 6e648067 P4D 123ec8067 PUD 123ec4067 PMD 100e38067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 5 UID: 0 PID: 755 Comm: modprobe Not tainted 6.12.0-rc3+ #17 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:__asan_load8+0x4c/0xa0 ... Call Trace: <TASK> blkdev_put_whole+0x41/0x70 bdev_release+0x1a3/0x250 blkdev_release+0x11/0x20 __fput+0x1d7/0x4a0 task_work_run+0xfc/0x180 syscall_exit_to_user_mode+0x1de/0x1f0 do_syscall_64+0x6b/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e loop_init() is calling loop_add() after __register_blkdev() succeeds and is ignoring disk_add() failure from loop_add(), for loop_add() failure is not fatal and successfully created disks are already visible to bdev_open(). brd_init() is currently calling brd_alloc() before __register_blkdev() succeeds and is releasing successfully created disks when brd_init() returns an error. This can cause UAF for the latter two case: case 1: T1: modprobe brd brd_init brd_alloc(0) // success add_disk disk_scan_partitions bdev_file_open_by_dev // alloc file fput // won't free until back to userspace brd_alloc(1) // failed since mem alloc error inject // error path for modprobe will release code segment // back to userspace __fput blkdev_release bdev_release blkdev_put_whole bdev->bd_disk->fops->release // fops is freed now, UAF! case 2: T1:T2: modprobe brd brd_init brd_alloc(0) // success open(/dev/ram0) brd_alloc(1) // fail // error path for modprobe close(/dev/ram0) ... /* UAF! */ bdev->bd_disk->fops->release Fix this problem by following what loop_init() does. Besides, reintroduce brd_devices_mutex to help serialize modifications to brd_list. Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-56693 CVE - 2024-56693
  11. Debian: CVE-2024-56708: linux -- security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 12/28/2024 Created 01/14/2025 Added 01/13/2025 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: EDAC/igen6: Avoid segmentation fault on module unload The segmentation fault happens because: During modprobe: 1. In igen6_probe(), igen6_pvt will be allocated with kzalloc() 2. In igen6_register_mci(), mci->pvt_info will point to &igen6_pvt->imc[mc] During rmmod: 1. In mci_release() in edac_mc.c, it will kfree(mci->pvt_info) 2. In igen6_remove(), it will kfree(igen6_pvt); Fix this issue by setting mci->pvt_info to NULL to avoid the double kfree. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-56708 CVE - 2024-56708
  12. Oracle Linux: CVE-2024-56602: 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: net: ieee802154: do not leave a dangling sk pointer in ieee802154_create() sock_init_data() attaches the allocated sk object to the provided sock object. If ieee802154_create() fails later, the allocated sk object is freed, but the dangling pointer remains in the provided sock object, which may allow use-after-free. Clear the sk pointer in the sock object on error. Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-56602 CVE - 2024-56602 ELSA-2025-20095 ELSA-2025-20100
  13. Oracle Linux: CVE-2024-56589: 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: scsi: hisi_sas: Add cond_resched() for no forced preemption model For no forced preemption model kernel, in the scenario where the expander is connected to 12 high performance SAS SSDs, the following call trace may occur: [214.409199][C240] watchdog: BUG: soft lockup - CPU#240 stuck for 22s! [irq/149-hisi_sa:3211] [214.568533][C240] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--) [214.575224][C240] pc : fput_many+0x8c/0xdc [214.579480][C240] lr : fput+0x1c/0xf0 [214.583302][C240] sp : ffff80002de2b900 [214.587298][C240] x29: ffff80002de2b900 x28: ffff1082aa412000 [214.593291][C240] x27: ffff3062a0348c08 x26: ffff80003a9f6000 [214.599284][C240] x25: ffff1062bbac5c40 x24: 0000000000001000 [214.605277][C240] x23: 000000000000000a x22: 0000000000000001 [214.611270][C240] x21: 0000000000001000 x20: 0000000000000000 [214.617262][C240] x19: ffff3062a41ae580 x18: 0000000000010000 [214.623255][C240] x17: 0000000000000001 x16: ffffdb3a6efe5fc0 [214.629248][C240] x15: ffffffffffffffff x14: 0000000003ffffff [214.635241][C240] x13: 000000000000ffff x12: 000000000000029c [214.641234][C240] x11: 0000000000000006 x10: ffff80003a9f7fd0 [214.647226][C240] x9 : ffffdb3a6f0482fc x8 : 0000000000000001 [214.653219][C240] x7 : 0000000000000002 x6 : 0000000000000080 [214.659212][C240] x5 : ffff55480ee9b000 x4 : fffffde7f94c6554 [214.665205][C240] x3 : 0000000000000002 x2 : 0000000000000020 [214.671198][C240] x1 : 0000000000000021 x0 : ffff3062a41ae5b8 [214.677191][C240] Call trace: [214.680320][C240]fput_many+0x8c/0xdc [214.684230][C240]fput+0x1c/0xf0 [214.687707][C240]aio_complete_rw+0xd8/0x1fc [214.692225][C240]blkdev_bio_end_io+0x98/0x140 [214.696917][C240]bio_endio+0x160/0x1bc [214.701001][C240]blk_update_request+0x1c8/0x3bc [214.705867][C240]scsi_end_request+0x3c/0x1f0 [214.710471][C240]scsi_io_completion+0x7c/0x1a0 [214.715249][C240]scsi_finish_command+0x104/0x140 [214.720200][C240]scsi_softirq_done+0x90/0x180 [214.724892][C240]blk_mq_complete_request+0x5c/0x70 [214.730016][C240]scsi_mq_done+0x48/0xac [214.734194][C240]sas_scsi_task_done+0xbc/0x16c [libsas] [214.739758][C240]slot_complete_v3_hw+0x260/0x760 [hisi_sas_v3_hw] [214.746185][C240]cq_thread_v3_hw+0xbc/0x190 [hisi_sas_v3_hw] [214.752179][C240]irq_thread_fn+0x34/0xa4 [214.756435][C240]irq_thread+0xc4/0x130 [214.760520][C240]kthread+0x108/0x13c [214.764430][C240]ret_from_fork+0x10/0x18 This is because in the hisi_sas driver, both the hardware interrupt handler and the interrupt thread are executed on the same CPU. In the performance test scenario, function irq_wait_for_interrupt() will always return 0 if lots of interrupts occurs and the CPU will be continuously consumed. As a result, the CPU cannot run the watchdog thread. When the watchdog time exceeds the specified time, call trace occurs. To fix it, add cond_resched() to execute the watchdog thread. Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-56589 CVE - 2024-56589 ELSA-2025-20095
  14. Debian: CVE-2024-53171: 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: 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->parent`. A further deletion of other nodes in the tree (which also could free the nodes), the aforementioned node's `znode->cparent` could still point to a freed node. This `znode->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->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->parent` has now been moved to `zp2`, *but* `zn->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->cparent` that wrongly points to the already freed `zp1`. `ubifs_copy_hash()` thus gets wrongly called with `znode->cparent->zbranch[znode->iip].hash` that triggers the use-after-free! Fix this by explicitly setting `znode->cparent` to `NULL` in `get_znodes_to_commit()` for the root node. The search for the dirty nodes ---truncated--- Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-53171 CVE - 2024-53171
  15. Oracle Linux: CVE-2024-56594: 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: drm/amdgpu: set the right AMDGPU sg segment limitation The driver needs to set the correct max_segment_size; otherwise debug_dma_map_sg() will complain about the over-mapping of the AMDGPU sg length as following: WARNING: CPU: 6 PID: 1964 at kernel/dma/debug.c:1178 debug_dma_map_sg+0x2dc/0x370 [364.049444] Modules linked in: veth amdgpu(OE) amdxcp drm_exec gpu_sched drm_buddy drm_ttm_helper ttm(OE) drm_suballoc_helper drm_display_helper drm_kms_helper i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter nvme_fabrics overlay nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc amd_atl intel_rapl_msr intel_rapl_common sunrpc sch_fq_codel snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd binfmt_misc snd_hda_codec snd_pci_acp6x snd_hda_core snd_acp_config snd_hwdep snd_soc_acpi kvm_amd snd_pcm kvm snd_seq_midi snd_seq_midi_event crct10dif_pclmul ghash_clmulni_intel sha512_ssse3 snd_rawmidi sha256_ssse3 sha1_ssse3 aesni_intel snd_seq nls_iso8859_1 crypto_simd snd_seq_device cryptd snd_timer rapl input_leds snd [364.049532]ipmi_devintf wmi_bmof ccp serio_raw k10temp sp5100_tco soundcore ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport drm efi_pstore ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii [364.049576] CPU: 6 PID: 1964 Comm: rocminfo Tainted: G OE6.10.0-custom #492 [364.049579] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021 [364.049582] RIP: 0010:debug_dma_map_sg+0x2dc/0x370 [364.049585] Code: 89 4d b8 e8 36 b1 86 00 8b 4d b8 48 8b 55 b0 44 8b 45 a8 4c 8b 4d a0 48 89 c6 48 c7 c7 00 4b 74 bc 4c 89 4d b8 e8 b4 73 f3 ff &lt;0f&gt; 0b 4c 8b 4d b8 8b 15 c8 2c b8 01 85 d2 0f 85 ee fd ff ff 8b 05 [364.049588] RSP: 0018:ffff9ca600b57ac0 EFLAGS: 00010286 [364.049590] RAX: 0000000000000000 RBX: ffff88b7c132b0c8 RCX: 0000000000000027 [364.049592] RDX: ffff88bb0f521688 RSI: 0000000000000001 RDI: ffff88bb0f521680 [364.049594] RBP: ffff9ca600b57b20 R08: 000000000000006f R09: ffff9ca600b57930 [364.049596] R10: ffff9ca600b57928 R11: ffffffffbcb46328 R12: 0000000000000000 [364.049597] R13: 0000000000000001 R14: ffff88b7c19c0700 R15: ffff88b7c9059800 [364.049599] FS:00007fb2d3516e80(0000) GS:ffff88bb0f500000(0000) knlGS:0000000000000000 [364.049601] CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [364.049603] CR2: 000055610bd03598 CR3: 00000001049f6000 CR4: 0000000000350ef0 [364.049605] Call Trace: [364.049607]&lt;TASK&gt; [364.049609]? show_regs+0x6d/0x80 [364.049614]? __warn+0x8c/0x140 [364.049618]? debug_dma_map_sg+0x2dc/0x370 [364.049621]? report_bug+0x193/0x1a0 [364.049627]? handle_bug+0x46/0x80 [364.049631]? exc_invalid_op+0x1d/0x80 [364.049635]? asm_exc_invalid_op+0x1f/0x30 [364.049642]? debug_dma_map_sg+0x2dc/0x370 [364.049647]__dma_map_sg_attrs+0x90/0xe0 [364.049651]dma_map_sgtable+0x25/0x40 [364.049654]amdgpu_bo_move+0x59a/0x850 [amdgpu] [364.049935]? srso_return_thunk+0x5/0x5f [364.049939]? amdgpu_ttm_tt_populate+0x5d/0xc0 [amdgpu] [364.050095]ttm_bo_handle_move_mem+0xc3/0x180 [ttm] [364.050103]ttm_bo_validate+0xc1/0x160 [ttm] [364.050108]? amdgpu_ttm_tt_get_user_pages+0xe5/0x1b0 [amdgpu] [364.050263]amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0xa12/0xc90 [amdgpu] [364.050473]kfd_ioctl_alloc_memory_of_gpu+0x16b/0x3b0 [amdgpu] [364.050680]kfd_ioctl+0x3c2/0x530 [amdgpu] [364.050866]? __pfx_kfd_ioctl_alloc_memory_of_gpu+0x10/0x10 [amdgpu] [364.05105 ---truncated--- Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-56594 CVE - 2024-56594 ELSA-2025-20095 ELSA-2025-20100
  16. Oracle Linux: CVE-2024-53206: ELSA-2025-20018: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 8 CVSS (AV:N/AC:L/Au:N/C:N/I:N/A:C) Published 12/27/2024 Created 01/15/2025 Added 01/13/2025 Modified 01/23/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&apos;s pass oreq to reqsk_put(). Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-53206 CVE - 2024-53206 ELSA-2025-20018
  17. VMware Photon OS: CVE-2024-56628 Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 12/27/2024 Created 01/30/2025 Added 01/29/2025 Modified 01/29/2025 Description In the Linux kernel, the following vulnerability has been resolved: LoongArch: Add architecture specific huge_pte_clear() When executing mm selftests run_vmtests.sh, there is such an error: BUG: Bad page state in process uffd-unit-testspfn:00000 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x0 flags: 0xffff0000002000(reserved|node=0|zone=0|lastcpupid=0xffff) raw: 00ffff0000002000 ffffbf0000000008 ffffbf0000000008 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set Modules linked in: snd_seq_dummy snd_seq snd_seq_device rfkill vfat fat virtio_balloon efi_pstore virtio_net pstore net_failover failover fuse nfnetlink virtio_scsi virtio_gpu virtio_dma_buf dm_multipath efivarfs CPU: 2 UID: 0 PID: 1913 Comm: uffd-unit-tests Not tainted 6.12.0 #184 Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022 Stack : 900000047c8ac000 0000000000000000 9000000000223a7c 900000047c8ac000 900000047c8af690 900000047c8af698 0000000000000000 900000047c8af7d8 900000047c8af7d0 900000047c8af7d0 900000047c8af5b0 0000000000000001 0000000000000001 900000047c8af698 10b3c7d53da40d26 0000010000000000 0000000000000022 0000000fffffffff fffffffffe000000 ffff800000000000 000000000000002f 0000800000000000 000000017a6d4000 90000000028f8940 0000000000000000 0000000000000000 90000000025aa5e0 9000000002905000 0000000000000000 90000000028f8940 ffff800000000000 0000000000000000 0000000000000000 0000000000000000 9000000000223a94 000000012001839c 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ... Call Trace: [<9000000000223a94>] show_stack+0x5c/0x180 [<9000000001c3fd64>] dump_stack_lvl+0x6c/0xa0 [<900000000056aa08>] bad_page+0x1a0/0x1f0 [<9000000000574978>] free_unref_folios+0xbf0/0xd20 [<90000000004e65cc>] folios_put_refs+0x1a4/0x2b8 [<9000000000599a0c>] free_pages_and_swap_cache+0x164/0x260 [<9000000000547698>] tlb_batch_pages_flush+0xa8/0x1c0 [<9000000000547f30>] tlb_finish_mmu+0xa8/0x218 [<9000000000543cb8>] exit_mmap+0x1a0/0x360 [<9000000000247658>] __mmput+0x78/0x200 [<900000000025583c>] do_exit+0x43c/0xde8 [<9000000000256490>] do_group_exit+0x68/0x110 [<9000000000256554>] sys_exit_group+0x1c/0x20 [<9000000001c413b4>] do_syscall+0x94/0x130 [<90000000002216d8>] handle_syscall+0xb8/0x158 Disabling lock debugging due to kernel taint BUG: non-zero pgtables_bytes on freeing mm: -16384 On LoongArch system, invalid huge pte entry should be invalid_pte_table or a single _PAGE_HUGE bit rather than a zero value. And it should be the same with invalid pmd entry, since pmd_none() is called by function free_pgd_range() and pmd_none() return 0 by huge_pte_clear(). So single _PAGE_HUGE bit is also treated as a valid pte table and free_pte_range() will be called in free_pmd_range(). free_pmd_range() pmd = pmd_offset(pud, addr); do { next = pmd_addr_end(addr, end); if (pmd_none_or_clear_bad(pmd)) continue; free_pte_range(tlb, pmd, addr); } while (pmd++, addr = next, addr != end); Here invalid_pte_table is used for both invalid huge pte entry and pmd entry. Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-56628 CVE - 2024-56628
  18. Oracle Linux: CVE-2024-56581: ELSA-2025-20095: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 7 CVSS (AV:L/AC:L/Au:S/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: btrfs: ref-verify: fix use-after-free after invalid ref action At btrfs_ref_tree_mod() after we successfully inserted the new ref entry (local variable &apos;ref&apos;) into the respective block entry&apos;s rbtree (local variable &apos;be&apos;), if we find an unexpected action of BTRFS_DROP_DELAYED_REF, we error out and free the ref entry without removing it from the block entry&apos;s rbtree. Then in the error path of btrfs_ref_tree_mod() we call btrfs_free_ref_cache(), which iterates over all block entries and then calls free_block_entry() for each one, and there we will trigger a use-after-free when we are called against the block entry to which we added the freed ref entry to its rbtree, since the rbtree still points to the block entry, as we didn&apos;t remove it from the rbtree before freeing it in the error path at btrfs_ref_tree_mod(). Fix this by removing the new ref entry from the rbtree before freeing it. Syzbot report this with the following stack traces: BTRFS error (device loop0 state EA): Ref action 2, root 5, ref_root 0, parent 8564736, owner 0, offset 0, num_refs 18446744073709551615 __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523 update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_insert_empty_items+0x9c/0x1a0 fs/btrfs/ctree.c:4314 btrfs_insert_empty_item fs/btrfs/ctree.h:669 [inline] btrfs_insert_orphan_item+0x1f1/0x320 fs/btrfs/orphan.c:23 btrfs_orphan_add+0x6d/0x1a0 fs/btrfs/inode.c:3482 btrfs_unlink+0x267/0x350 fs/btrfs/inode.c:4293 vfs_unlink+0x365/0x650 fs/namei.c:4469 do_unlinkat+0x4ae/0x830 fs/namei.c:4533 __do_sys_unlinkat fs/namei.c:4576 [inline] __se_sys_unlinkat fs/namei.c:4569 [inline] __x64_sys_unlinkat+0xcc/0xf0 fs/namei.c:4569 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f BTRFS error (device loop0 state EA): Ref action 1, root 5, ref_root 5, parent 0, owner 260, offset 0, num_refs 1 __btrfs_mod_ref+0x76b/0xac0 fs/btrfs/extent-tree.c:2521 update_ref_for_cow+0x96a/0x11f0 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411 __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030 btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1114 [inline] __btrfs_commit_inode_delayed_items+0x2318/0x24a0 fs/btrfs/delayed-inode.c:1137 __btrfs_run_delayed_items+0x213/0x490 fs/btrfs/delayed-inode.c:1171 btrfs_commit_transaction+0x8a8/0x3740 fs/btrfs/transaction.c:2313 prepare_to_relocate+0x3c4/0x4c0 fs/btrfs/relocation.c:3586 relocate_block_group+0x16c/0xd40 fs/btrfs/relocation.c:3611 btrfs_relocate_block_group+0x77d/0xd90 fs/btrfs/relocation.c:4081 btrfs_relocate_chunk+0x12c/0x3b0 fs/btrfs/volumes.c:3377 __btrfs_balance+0x1b0f/0x26b0 fs/btrfs/volumes.c:4161 btrfs_balance+0xbdc/0x10c0 fs/btrfs/volumes.c:4538 BTRFS error (device loop0 state EA): Ref action 2, root 5, ref_root 0, parent 8564736, owner 0, offset 0, num_refs 18446744073709551615 __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523 update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411 __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030 btrfs_update_delayed_i ---truncated--- Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-56581 CVE - 2024-56581 ELSA-2025-20095 ELSA-2025-20100
  19. Debian: CVE-2024-53229: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 12/27/2024 Created 02/11/2025 Added 02/10/2025 Modified 02/10/2025 Description In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix the qp flush warnings in req When the qp is in error state, the status of WQEs in the queue should be set to error. Or else the following will appear. [920.617269] WARNING: CPU: 1 PID: 21 at drivers/infiniband/sw/rxe/rxe_comp.c:756 rxe_completer+0x989/0xcc0 [rdma_rxe] [920.617744] Modules linked in: rnbd_client(O) rtrs_client(O) rtrs_core(O) rdma_ucm rdma_cm iw_cm ib_cm crc32_generic rdma_rxe ip6_udp_tunnel udp_tunnel ib_uverbs ib_core loop brd null_blk ipv6 [920.618516] CPU: 1 PID: 21 Comm: ksoftirqd/1 Tainted: G O 6.1.113-storage+ #65 [920.618986] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [920.619396] RIP: 0010:rxe_completer+0x989/0xcc0 [rdma_rxe] [920.619658] Code: 0f b6 84 24 3a 02 00 00 41 89 84 24 44 04 00 00 e9 2a f7 ff ff 39 ca bb 03 00 00 00 b8 0e 00 00 00 48 0f 45 d8 e9 15 f7 ff ff <0f> 0b e9 cb f8 ff ff 41 bf f5 ff ff ff e9 08 f8 ff ff 49 8d bc 24 [920.620482] RSP: 0018:ffff97b7c00bbc38 EFLAGS: 00010246 [920.620817] RAX: 0000000000000000 RBX: 000000000000000c RCX: 0000000000000008 [920.621183] RDX: ffff960dc396ebc0 RSI: 0000000000005400 RDI: ffff960dc4e2fbac [920.621548] RBP: 0000000000000000 R08: 0000000000000001 R09: ffffffffac406450 [920.621884] R10: ffffffffac4060c0 R11: 0000000000000001 R12: ffff960dc4e2f800 [920.622254] R13: ffff960dc4e2f928 R14: ffff97b7c029c580 R15: 0000000000000000 [920.622609] FS:0000000000000000(0000) GS:ffff960ef7d00000(0000) knlGS:0000000000000000 [920.622979] CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [920.623245] CR2: 00007fa056965e90 CR3: 00000001107f1000 CR4: 00000000000006e0 [920.623680] Call Trace: [920.623815]<TASK> [920.623933]? __warn+0x79/0xc0 [920.624116]? rxe_completer+0x989/0xcc0 [rdma_rxe] [920.624356]? report_bug+0xfb/0x150 [920.624594]? handle_bug+0x3c/0x60 [920.624796]? exc_invalid_op+0x14/0x70 [920.624976]? asm_exc_invalid_op+0x16/0x20 [920.625203]? rxe_completer+0x989/0xcc0 [rdma_rxe] [920.625474]? rxe_completer+0x329/0xcc0 [rdma_rxe] [920.625749]rxe_do_task+0x80/0x110 [rdma_rxe] [920.626037]rxe_requester+0x625/0xde0 [rdma_rxe] [920.626310]? rxe_cq_post+0xe2/0x180 [rdma_rxe] [920.626583]? do_complete+0x18d/0x220 [rdma_rxe] [920.626812]? rxe_completer+0x1a3/0xcc0 [rdma_rxe] [920.627050]rxe_do_task+0x80/0x110 [rdma_rxe] [920.627285]tasklet_action_common.constprop.0+0xa4/0x120 [920.627522]handle_softirqs+0xc2/0x250 [920.627728]? sort_range+0x20/0x20 [920.627942]run_ksoftirqd+0x1f/0x30 [920.628158]smpboot_thread_fn+0xc7/0x1b0 [920.628334]kthread+0xd6/0x100 [920.628504]? kthread_complete_and_exit+0x20/0x20 [920.628709]ret_from_fork+0x1f/0x30 [920.628892]</TASK> Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-53229 CVE - 2024-53229 DSA-5860-1
  20. Debian: CVE-2024-56637: 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: netfilter: ipset: Hold module reference while requesting a module User space may unload ip_set.ko while it is itself requesting a set type backend module, leading to a kernel crash. The race condition may be provoked by inserting an mdelay() right after the nfnl_unlock() call. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-56637 CVE - 2024-56637
  21. Debian: CVE-2024-56571: 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: media: uvcvideo: Require entities to have a non-zero unique ID Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero unique ID. ``` Each Unit and Terminal within the video function is assigned a unique identification number, the Unit ID (UID) or Terminal ID (TID), contained in the bUnitID or bTerminalID field of the descriptor. The value 0x00 is reserved for undefined ID, ``` So, deny allocating an entity with ID 0 or an ID that belongs to a unit that is already added to the list of entities. This also prevents some syzkaller reproducers from triggering warnings due to a chain of entities referring to themselves. In one particular case, an Output Unit is connected to an Input Unit, both with the same ID of 1. But when looking up for the source ID of the Output Unit, that same entity is found instead of the input entity, which leads to such warnings. In another case, a backward chain was considered finished as the source ID was 0. Later on, that entity was found, but its pads were not valid. Here is a sample stack trace for one of those cases. [ 20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd [ 20.830206] usb 1-1: Using ep0 maxpacket: 8 [ 20.833501] usb 1-1: config 0 descriptor?? [ 21.038518] usb 1-1: string descriptor 0 read error: -71 [ 21.038893] usb 1-1: Found UVC 0.00 device <unnamed> (2833:0201) [ 21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized! [ 21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized! [ 21.042218] ------------[ cut here ]------------ [ 21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0 [ 21.043195] Modules linked in: [ 21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444 [ 21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 21.044639] Workqueue: usb_hub_wq hub_event [ 21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0 [ 21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 <0f> 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00 [ 21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246 [ 21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1 [ 21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290 [ 21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000 [ 21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003 [ 21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000 [ 21.049648] FS:0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 [ 21.050271] CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0 [ 21.051136] PKRU: 55555554 [ 21.051331] Call Trace: [ 21.051480]<TASK> [ 21.051611]? __warn+0xc4/0x210 [ 21.051861]? media_create_pad_link+0x2c4/0x2e0 [ 21.052252]? report_bug+0x11b/0x1a0 [ 21.052540]? trace_hardirqs_on+0x31/0x40 [ 21.052901]? handle_bug+0x3d/0x70 [ 21.053197]? exc_invalid_op+0x1a/0x50 [ 21.053511]? asm_exc_invalid_op+0x1a/0x20 [ 21.053924]? media_create_pad_link+0x91/0x2e0 [ 21.054364]? media_create_pad_link+0x2c4/0x2e0 [ 21.054834]? media_create_pad_link+0x91/0x2e0 [ 21.055131]? _raw_spin_unlock+0x1e/0x40 [ 21.055441]? __v4l2_device_register_subdev+0x202/0x210 [ 21.055837]uvc_mc_register_entities+0x358/0x400 [ 21.056144]uvc_register_chains+0x1fd/0x290 [ 21.056413]uvc_probe+0x380e/0x3dc0 [ 21.056676]? __lock_acquire+0x5aa/0x26e0 [ 21.056946]? find_held_lock+0x33/0xa0 [ 21.057196]? kernfs_activate+0x70/0x80 [ 21.057533]? usb_match_dy ---truncated--- Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-56571 CVE - 2024-56571
  22. VMware Photon OS: CVE-2024-56665 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: bpf,perf: Fix invalid prog_array access in perf_event_detach_bpf_prog Syzbot reported [1] crash that happens for following tracing scenario: - create tracepoint perf event with attr.inherit=1, attach it to the process and set bpf program to it - attached process forks -> chid creates inherited event the new child event shares the parent's bpf program and tp_event (hence prog_array) which is global for tracepoint - exit both process and its child -> release both events - first perf_event_detach_bpf_prog call will release tp_event->prog_array and second perf_event_detach_bpf_prog will crash, because tp_event->prog_array is NULL The fix makes sure the perf_event_detach_bpf_prog checks prog_array is valid before it tries to remove the bpf program from it. [1] https://lore.kernel.org/bpf/Z1MR6dCIKajNS6nU@krava/T/#m91dbf0688221ec7a7fc95e896a7ef9ff93b0b8ad Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-56665 CVE - 2024-56665
  23. VMware Photon OS: CVE-2024-56658 Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/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: 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) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-56658 CVE - 2024-56658
  24. Debian: CVE-2024-53220: 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: f2fs: fix to account dirty data in __get_secs_required() It will trigger system panic w/ testcase in [1]: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2752! RIP: 0010:new_curseg+0xc81/0x2110 Call Trace: f2fs_allocate_data_block+0x1c91/0x4540 do_write_page+0x163/0xdf0 f2fs_outplace_write_data+0x1aa/0x340 f2fs_do_write_data_page+0x797/0x2280 f2fs_write_single_data_page+0x16cd/0x2190 f2fs_write_cache_pages+0x994/0x1c80 f2fs_write_data_pages+0x9cc/0xea0 do_writepages+0x194/0x7a0 filemap_fdatawrite_wbc+0x12b/0x1a0 __filemap_fdatawrite_range+0xbb/0xf0 file_write_and_wait_range+0xa1/0x110 f2fs_do_sync_file+0x26f/0x1c50 f2fs_sync_file+0x12b/0x1d0 vfs_fsync_range+0xfa/0x230 do_fsync+0x3d/0x80 __x64_sys_fsync+0x37/0x50 x64_sys_call+0x1e88/0x20d0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is if checkpoint_disabling and lfs_mode are both on, it will trigger OPU for all overwritten data, it may cost more free segment than expected, so f2fs must account those data correctly to calculate cosumed free segments later, and return ENOSPC earlier to avoid run out of free segment during block allocation. [1] https://lore.kernel.org/fstests/[email protected]/ Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-53220 CVE - 2024-53220
  25. Debian: CVE-2024-56608: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 12/27/2024 Created 02/11/2025 Added 02/10/2025 Modified 02/10/2025 Description In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix out-of-bounds access in 'dcn21_link_encoder_create' An issue was identified in the dcn21_link_encoder_create function where an out-of-bounds access could occur when the hpd_source index was used to reference the link_enc_hpd_regs array. This array has a fixed size and the index was not being checked against the array's bounds before accessing it. This fix adds a conditional check to ensure that the hpd_source index is within the valid range of the link_enc_hpd_regs array. If the index is out of bounds, the function now returns NULL to prevent undefined behavior. References: [ 65.920507] ------------[ cut here ]------------ [ 65.920510] UBSAN: array-index-out-of-bounds in drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn21/dcn21_resource.c:1312:29 [ 65.920519] index 7 is out of range for type 'dcn10_link_enc_hpd_registers [5]' [ 65.920523] CPU: 3 PID: 1178 Comm: modprobe Tainted: G OE6.8.0-cleanershaderfeatureresetasdntipmi200nv2132 #13 [ 65.920525] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS WMJ0429N_Weekly_20_04_2 04/29/2020 [ 65.920527] Call Trace: [ 65.920529]<TASK> [ 65.920532]dump_stack_lvl+0x48/0x70 [ 65.920541]dump_stack+0x10/0x20 [ 65.920543]__ubsan_handle_out_of_bounds+0xa2/0xe0 [ 65.920549]dcn21_link_encoder_create+0xd9/0x140 [amdgpu] [ 65.921009]link_create+0x6d3/0xed0 [amdgpu] [ 65.921355]create_links+0x18a/0x4e0 [amdgpu] [ 65.921679]dc_create+0x360/0x720 [amdgpu] [ 65.921999]? dmi_matches+0xa0/0x220 [ 65.922004]amdgpu_dm_init+0x2b6/0x2c90 [amdgpu] [ 65.922342]? console_unlock+0x77/0x120 [ 65.922348]? dev_printk_emit+0x86/0xb0 [ 65.922354]dm_hw_init+0x15/0x40 [amdgpu] [ 65.922686]amdgpu_device_init+0x26a8/0x33a0 [amdgpu] [ 65.922921]amdgpu_driver_load_kms+0x1b/0xa0 [amdgpu] [ 65.923087]amdgpu_pci_probe+0x1b7/0x630 [amdgpu] [ 65.923087]local_pci_probe+0x4b/0xb0 [ 65.923087]pci_device_probe+0xc8/0x280 [ 65.923087]really_probe+0x187/0x300 [ 65.923087]__driver_probe_device+0x85/0x130 [ 65.923087]driver_probe_device+0x24/0x110 [ 65.923087]__driver_attach+0xac/0x1d0 [ 65.923087]? __pfx___driver_attach+0x10/0x10 [ 65.923087]bus_for_each_dev+0x7d/0xd0 [ 65.923087]driver_attach+0x1e/0x30 [ 65.923087]bus_add_driver+0xf2/0x200 [ 65.923087]driver_register+0x64/0x130 [ 65.923087]? __pfx_amdgpu_init+0x10/0x10 [amdgpu] [ 65.923087]__pci_register_driver+0x61/0x70 [ 65.923087]amdgpu_init+0x7d/0xff0 [amdgpu] [ 65.923087]do_one_initcall+0x49/0x310 [ 65.923087]? kmalloc_trace+0x136/0x360 [ 65.923087]do_init_module+0x6a/0x270 [ 65.923087]load_module+0x1fce/0x23a0 [ 65.923087]init_module_from_file+0x9c/0xe0 [ 65.923087]? init_module_from_file+0x9c/0xe0 [ 65.923087]idempotent_init_module+0x179/0x230 [ 65.923087]__x64_sys_finit_module+0x5d/0xa0 [ 65.923087]do_syscall_64+0x76/0x120 [ 65.923087]entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 65.923087] RIP: 0033:0x7f2d80f1e88d [ 65.923087] 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 [ 65.923087] RSP: 002b:00007ffc7bc1aa78 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 65.923087] RAX: ffffffffffffffda RBX: 0000564c9c1db130 RCX: 00007f2d80f1e88d [ 65.923087] RDX: 0000000000000000 RSI: 0000564c9c1e5480 RDI: 000000000000000f [ 65.923087] RBP: 0000000000040000 R08: 0000000000000000 R09: 0000000000000002 [ 65.923087] R10: 000000000000000f R11: 0000000000000246 R12: 0000564c9c1e5480 [ 65.923087] R13: 0000564c9c1db260 R14: 0000000000000000 R15: 0000564c9c1e54b0 [ 65.923087]</TASK> [ 65.923927] ---[ end trace ]--- Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-56608 CVE - 2024-56608 DSA-5860-1