CVE-2024-56559

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

net: wwan: t7xx: Fix FSM command timeout issue

When driver processes the internal state change command, it use an asynchronous thread to process the command operation. If the main thread detects that the task has timed out, the asynchronous thread will panic when executing the completion notification because the main thread completion object has been released.

BUG: unable to handle page fault for address: fffffffffffffff8 PGD 1f283a067 P4D 1f283a067 PUD 1f283c067 PMD 0 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:complete_all+0x3e/0xa0 [...] Call Trace: <TASK> ? __die_body+0x68/0xb0 ? page_fault_oops+0x379/0x3e0 ? exc_page_fault+0x69/0xa0 ? asm_exc_page_fault+0x22/0x30 ? complete_all+0x3e/0xa0 fsm_main_thread+0xa3/0x9c0 [mtk_t7xx (HASH:1400 5)] ? __pfx_autoremove_wake_function+0x10/0x10 kthread+0xd8/0x110 ? __pfx_fsm_main_thread+0x10/0x10 [mtk_t7xx (HASH:1400 5)] ? __pfx_kthread+0x10/0x10 ret_from_fork+0x38/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> [...] CR2: fffffffffffffff8 ---[ end trace 0000000000000000 ]---

Use the reference counter to ensure safe release as Sergey suggests: https://lore.kernel.org/all/[email protected]/(CVE-2024-39282)

In the Linux kernel, the following vulnerability has been resolved:

i3c: mipi-i3c-hci: Mask ring interrupts before ring stop request

Bus cleanup path in DMA mode may trigger a RING_OP_STAT interrupt when the ring is being stopped. Depending on timing between ring stop request completion, interrupt handler removal and code execution this may lead to a NULL pointer dereference in hci_dma_irq_handler() if it gets to run after the io_data pointer is set to NULL in hci_dma_cleanup().

Prevent this my masking the ring interrupts before ring stop request.(CVE-2024-45828)

In the Linux kernel, the following vulnerability has been resolved:

ethtool: fail closed if we can't get max channel used in indirection tables

Commit 0d1b7d6c9274 ("bnxt: fix crashes when reducing ring count with active RSS contexts") proves that allowing indirection table to contain channels with out of bounds IDs may lead to crashes. Currently the max channel check in the core gets skipped if driver can't fetch the indirection table or when we can't allocate memory.

Both of those conditions should be extremely rare but if they do happen we should try to be safe and fail the channel change.(CVE-2024-46834)

In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: mt7921: fix NULL pointer access in mt7921_ipv6_addr_change

When disabling wifi mt7921_ipv6_addr_change() is called as a notifier. At this point mvif->phy is already NULL so we cannot use it here.(CVE-2024-46860)

In the Linux kernel, the following vulnerability has been resolved:

usbnet: ipheth: do not stop RX on failing RX callback

RX callbacks can fail for multiple reasons:

• Payload too short
• Payload formatted incorrecly (e.g. bad NCM framing)
• Lack of memory

None of these should cause the driver to seize up.

Make such failures non-critical and continue processing further incoming URBs.(CVE-2024-46861)

In the Linux kernel, the following vulnerability has been resolved:

nvme-rdma: unquiesce admin_q before destroy it

Kernel will hang on destroy admin_q while we create ctrl failed, such as following calltrace:

PID: 23644 TASK: ff2d52b40f439fc0 CPU: 2 COMMAND: "nvme" #0 [ff61d23de260fb78] __schedule at ffffffff8323bc15 #1 [ff61d23de260fc08] schedule at ffffffff8323c014 #2 [ff61d23de260fc28] blk_mq_freeze_queue_wait at ffffffff82a3dba1 #3 [ff61d23de260fc78] blk_freeze_queue at ffffffff82a4113a #4 [ff61d23de260fc90] blk_cleanup_queue at ffffffff82a33006 #5 [ff61d23de260fcb0] nvme_rdma_destroy_admin_queue at ffffffffc12686ce #6 [ff61d23de260fcc8]…

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

net: wwan: t7xx: Fix FSM command timeout issue

When driver processes the internal state change command, it use an asynchronous thread to process the command operation. If the main thread detects that the task has timed out, the asynchronous thread will panic when executing the completion notification because the main thread completion object has been released.

BUG: unable to handle page fault for address: fffffffffffffff8 PGD 1f283a067 P4D 1f283a067 PUD 1f283c067 PMD 0 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:complete_all+0x3e/0xa0 [...] Call Trace: <TASK> ? __die_body+0x68/0xb0 ? page_fault_oops+0x379/0x3e0 ? exc_page_fault+0x69/0xa0 ? asm_exc_page_fault+0x22/0x30 ? complete_all+0x3e/0xa0 fsm_main_thread+0xa3/0x9c0 [mtk_t7xx (HASH:1400 5)] ? __pfx_autoremove_wake_function+0x10/0x10 kthread+0xd8/0x110 ? __pfx_fsm_main_thread+0x10/0x10 [mtk_t7xx (HASH:1400 5)] ? __pfx_kthread+0x10/0x10 ret_from_fork+0x38/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> [...] CR2: fffffffffffffff8 ---[ end trace 0000000000000000 ]---

Use the reference counter to ensure safe release as Sergey suggests: https://lore.kernel.org/all/[email protected]/(CVE-2024-39282)

In the Linux kernel, the following vulnerability has been resolved:

i3c: mipi-i3c-hci: Mask ring interrupts before ring stop request

Bus cleanup path in DMA mode may trigger a RING_OP_STAT interrupt when the ring is being stopped. Depending on timing between ring stop request completion, interrupt handler removal and code execution this may lead to a NULL pointer dereference in hci_dma_irq_handler() if it gets to run after the io_data pointer is set to NULL in hci_dma_cleanup().

Prevent this my masking the ring interrupts before ring stop request.(CVE-2024-45828)

In the Linux kernel, the following vulnerability has been resolved:

ethtool: fail closed if we can't get max channel used in indirection tables

Commit 0d1b7d6c9274 ("bnxt: fix crashes when reducing ring count with active RSS contexts") proves that allowing indirection table to contain channels with out of bounds IDs may lead to crashes. Currently the max channel check in the core gets skipped if driver can't fetch the indirection table or when we can't allocate memory.

Both of those conditions should be extremely rare but if they do happen we should try to be safe and fail the channel change.(CVE-2024-46834)

In the Linux kernel, the following vulnerability has been resolved:

nvme-rdma: unquiesce admin_q before destroy it

Kernel will hang on destroy admin_q while we create ctrl failed, such as following calltrace:

PID: 23644 TASK: ff2d52b40f439fc0 CPU: 2 COMMAND: "nvme" #0 [ff61d23de260fb78] __schedule at ffffffff8323bc15 #1 [ff61d23de260fc08] schedule at ffffffff8323c014 #2 [ff61d23de260fc28] blk_mq_freeze_queue_wait at ffffffff82a3dba1 #3 [ff61d23de260fc78] blk_freeze_queue at ffffffff82a4113a #4 [ff61d23de260fc90] blk_cleanup_queue at ffffffff82a33006 #5 [ff61d23de260fcb0] nvme_rdma_destroy_admin_queue at ffffffffc12686ce #6 [ff61d23de260fcc8] nvme_rdma_setup_ctrl at ffffffffc1268ced #7 [ff61d23de260fd28] nvme_rdma_create_ctrl at ffffffffc126919b #8 [ff61d23de260fd68] nvmf_dev_write at ffffffffc024f362 #9 [ff61d23de260fe38] vfs_write at ffffffff827d5f25 RIP: 00007fda7891d574 RSP: 00007ffe2ef06958 RFLAGS: 00000202 RAX: ffffffffffffffda RBX: 000055e8122a4d90 RCX: 00007fda7891d574 RDX: 000000000000012b RSI: 000055e8122a4d90 RDI: 0000000000000004 RBP: 00007ffe2ef079c0 R8: 000000000000012b R9: 000055e8122a4d90 R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000004 R13: 000055e8122923c0 R14: 000000000000012b R15: 00007fda78a54500 ORIG_RAX: 0000000000000001 CS: 0033 SS: 002b

This due to we have…

In the Linux kernel, the following vulnerability has been resolved: mm/vmalloc: combine all TLB flush operations of KASAN shadow virtual address into one operation When compiling kernel source 'make -j $(nproc)' with the up-and-running KASAN-enabled kernel on a 256-core machine, the following soft lockup is shown: watchdog: BUG: soft lockup - CPU#28 stuck for 22s! [kworker/28:1:1760] CPU: 28 PID: 1760 Comm: kworker/28:1 Kdump: loaded Not tainted 6.10.0-rc5 #95 Workqueue: events drain_vmap_area_work RIP: 0010:smp_call_function_many_cond+0x1d8/0xbb0 Code: 38 c8 7c 08 84 c9 0f 85 49 08 00 00 8b 45 08 a8 01 74 2e 48 89 f1 49 89 f7 48 c1 e9 03 41 83 e7 07 4c 01 e9 41 83 c7 03 f3 90 <0f> b6 01 41 38 c7 7c 08 84 c0 0f 85 d4 06 00 00 8b 45 08 a8 01 75 RSP: 0018:ffffc9000cb3fb60 EFLAGS: 00000202 RAX: 0000000000000011 RBX: ffff8883bc4469c0 RCX: ffffed10776e9949 RDX: 0000000000000002 RSI: ffff8883bb74ca48 RDI: ffffffff8434dc50 RBP: ffff8883bb74ca40 R08: ffff888103585dc0 R09: ffff8884533a1800 R10: 0000000000000004 R11: ffffffffffffffff R12: ffffed1077888d39 R13: dffffc0000000000 R14: ffffed1077888d38 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff8883bc400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005577b5c8d158 CR3: 0000000004850000 CR4: 0000000000350ef0 Call Trace: <IRQ> ? watchdog_timer_fn+0x2cd/0x390 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x300/0x6d0 ? sched_clock_cpu+0x69/0x4e0 ? __pfx___hrtimer_run_queues+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? ktime_get_update_offsets_now+0x7f/0x2a0 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? hrtimer_interrupt+0x2ca/0x760 ? __sysvec_apic_timer_interrupt+0x8c/0x2b0 ? sysvec_apic_timer_interrupt+0x6a/0x90 </IRQ> <TASK> ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? smp_call_function_many_cond+0x1d8/0xbb0 ? __pfx_do_kernel_range_flush+0x10/0x10 on_each_cpu_cond_mask+0x20/0x40 flush_tlb_kernel_range+0x19b/0x250 ? srso_return_thunk+0x5/0x5f ? kasan_release_vmalloc+0xa7/0xc0 purge_vmap_node+0x357/0x820 ? __pfx_purge_vmap_node+0x10/0x10 __purge_vmap_area_lazy+0x5b8/0xa10 drain_vmap_area_work+0x21/0x30 process_one_work+0x661/0x10b0 worker_thread+0x844/0x10e0 ? srso_return_thunk+0x5/0x5f ? __kthread_parkme+0x82/0x140 ? __pfx_worker_thread+0x10/0x10 kthread+0x2a5/0x370 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Debugging Analysis: 1. The following ftrace log shows that the lockup CPU spends too much time iterating vmap_nodes and flushing TLB when purging vm_area structures. (Some info is trimmed). kworker: funcgraph_entry: | drain_vmap_area_work() { kworker: funcgraph_entry: | mutex_lock() { kworker: funcgraph_entry: 1.092 us | __cond_resched(); kworker: funcgraph_exit: 3.306 us | } ... ... kworker: funcgraph_entry: | flush_tlb_kernel_range() { ... ... kworker: funcgraph_exit: # 7533.649 us | } ... ... kworker: funcgraph_entry: 2.344 us | mutex_unlock(); kworker: funcgraph_exit: $ 23871554 us | } The drain_vmap_area_work() spends over 23 seconds. There are 2805 flush_tlb_kernel_range() calls in the ftrace log. * One is called in __purge_vmap_area_lazy(). * Others are called by purge_vmap_node->kasan_release_vmalloc. purge_vmap_node() iteratively releases kasan vmalloc allocations and flushes TLB for each vmap_area. - [Rough calculation] Each flush_tlb_kernel_range() runs about 7.5ms. -- 2804 * 7.5ms = 21.03 seconds. -- That's why a soft lock is triggered. 2. Extending the soft lockup time can work around the issue (For example, # echo ---truncated---

In the Linux kernel, the following vulnerability has been resolved:

mm/vmalloc: combine all TLB flush operations of KASAN shadow virtual address into one operation

When compiling kernel source 'make -j $(nproc)' with the up-and-running KASAN-enabled kernel on a 256-core machine, the following soft lockup is shown:

watchdog: BUG: soft lockup - CPU#28 stuck for 22s! [kworker/28:1:1760] CPU: 28 PID: 1760 Comm: kworker/28:1 Kdump: loaded Not tainted 6.10.0-rc5 #95 Workqueue: events drain_vmap_area_work RIP: 0010:smp_call_function_many_cond+0x1d8/0xbb0 Code: 38 c8 7c 08 84 c9 0f 85 49 08 00 00 8b 45 08 a8 01 74 2e 48 89 f1 49 89 f7 48 c1 e9 03 41 83 e7 07 4c 01 e9 41 83 c7 03 f3 90 <0f> b6 01 41 38 c7 7c 08 84 c0 0f 85 d4 06 00 00 8b 45 08 a8 01 75 RSP: 0018:ffffc9000cb3fb60 EFLAGS: 00000202 RAX: 0000000000000011 RBX: ffff8883bc4469c0 RCX: ffffed10776e9949 RDX: 0000000000000002 RSI: ffff8883bb74ca48 RDI: ffffffff8434dc50 RBP: ffff8883bb74ca40 R08: ffff888103585dc0 R09: ffff8884533a1800 R10: 0000000000000004 R11: ffffffffffffffff R12: ffffed1077888d39 R13: dffffc0000000000 R14: ffffed1077888d38 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff8883bc400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005577b5c8d158 CR3: 0000000004850000 CR4: 0000000000350ef0 Call Trace: <IRQ> ? watchdog_timer_fn+0x2cd/0x390 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x300/0x6d0 ? sched_clock_cpu+0x69/0x4e0 ? __pfx___hrtimer_run_queues+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? ktime_get_update_offsets_now+0x7f/0x2a0 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? hrtimer_interrupt+0x2ca/0x760 ? __sysvec_apic_timer_interrupt+0x8c/0x2b0 ? sysvec_apic_timer_interrupt+0x6a/0x90 </IRQ> <TASK> ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? smp_call_function_many_cond+0x1d8/0xbb0 ? __pfx_do_kernel_range_flush+0x10/0x10 on_each_cpu_cond_mask+0x20/0x40 flush_tlb_kernel_range+0x19b/0x250 ? srso_return_thunk+0x5/0x5f ? kasan_release_vmalloc+0xa7/0xc0 purge_vmap_node+0x357/0x820 ? __pfx_purge_vmap_node+0x10/0x10 __purge_vmap_area_lazy+0x5b8/0xa10 drain_vmap_area_work+0x21/0x30 process_one_work+0x661/0x10b0 worker_thread+0x844/0x10e0 ? srso_return_thunk+0x5/0x5f ? __kthread_parkme+0x82/0x140 ? __pfx_worker_thread+0x10/0x10 kthread+0x2a5/0x370 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK>

Debugging Analysis:

1. The following ftrace log shows that the lockup CPU spends too much time iterating vmap_nodes and flushing TLB when purging vm_area structures. (Some info is trimmed).

   kworker: funcgraph_entry: | drain_vmap_area_work() { kworker: funcgraph_entry: | mutex_lock() { kworker: funcgraph_entry: 1.092 us | __cond_resched(); kworker: funcgraph_exit: 3.306 us | } ... ... kworker: funcgraph_entry: | flush_tlb_kernel_range() { ... ... kworker: funcgraph_exit: # 7533.649 us | } ... ... kworker: funcgraph_entry: 2.344 us | mutex_unlock(); kworker: funcgraph_exit: $ 23871554 us | }

   The drain_vmap_area_work() spends over 23 seconds.

   There are 2805 flush_tlb_kernel_range() calls in the ftrace log.

   • One is called in __purge_vmap_area_lazy().
   • Others are called by purge_vmap_node->kasan_release_vmalloc. purge_vmap_node() iteratively releases kasan vmalloc allocations and flushes TLB for each vmap_area.
     • [Rough calculation] Each flush_tlb_kernel_range() runs about 7.5ms. -- 2804 * 7.5ms = 21.03 seconds. -- That's why a soft lock is triggered.

2. Extending the soft lockup time can work around the issue (For example,

   echo

---truncated---

Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system. This update corrects flaws in the following subsystems:

• ARM64 architecture;
• MIPS architecture;
• PowerPC architecture;
• RISC-V architecture;
• S390 architecture;
• x86 architecture;
• Block layer subsystem;
• Compute Acceleration Framework;
• ACPI drivers;
• Drivers core;
• Ublk userspace block driver;
• Virtio block driver;
• Bluetooth drivers;
• Buffer Sharing and Synchronization framework;
• DMA engine subsystem;
• EFI core;
• GPIO subsystem;
• GPU drivers;
• HID subsystem;
• Microsoft Hyper-V drivers;
• Hardware monitoring drivers;
• I3C subsystem;
• IIO ADC drivers;
• IIO subsystem;
• InfiniBand drivers;
• IOMMU subsystem;
• LED subsystem;
• Multiple devices driver;
• Media drivers;
• Microchip PCI driver;
• MTD block device drivers;
• Network drivers;
• Mellanox network drivers;
• STMicroelectronics network drivers;
• NVME drivers;
• PCI subsystem;
• PHY drivers;
• Pin controllers subsystem;
• x86 platform drivers;
• i.MX PM domains;
• Power supply drivers;
• Voltage and Current Regulator drivers;
• SCSI subsystem;
• i.MX SoC drivers;
• SPI subsystem;
• UFS subsystem;
• USB Gadget drivers;
• TDX Guest driver;
• AFS file system;
• BTRFS file system;
• Ceph distributed file system;
• File systems infrastructure;
• F2FS file system;
• JFFS2 file system;
• JFS file system;
• Network file systems library;
• Network file system (NFS) server daemon;
• NILFS2 file system;
• File system notification infrastructure;
• Overlay file system;
• Diskquota system;
• SMB network file system;
• DRM display driver;
• BPF subsystem;
• VLANs driver;
• KASAN memory debugging framework;
• Memory management;
• StackDepot library;
• Bluetooth subsystem;
• LAPB network protocol;
• Netfilter;
• io_uring subsystem;
• Control group (cgroup);
• DMA mapping infrastructure;
• KCSAN framework;
• Scheduler infrastructure;
• Seccomp subsystem;
• Tracing infrastructure;
• Workqueue subsystem;
• KUnit library;
• CAN network layer;
• Networking core;
• DCCP (Datagram Congestion Control Protocol);
• HSR network protocol;
• IEEE802154.4 network protocol;
• IPv4 networking;
• IPv6 networking;
• MAC80211 subsystem;
• Multipath TCP;
• NET/ROM layer;
• Packet sockets;
• RDS protocol;
• Network traffic control;
• SCTP protocol;
• SMC sockets;
• TIPC protocol;
• Wireless networking;
• eXpress Data Path;
• SELinux security module;
• ALSA framework;
• Intel ASoC drivers;
• SOF drivers; (CVE-2024-57921, CVE-2024-56614, CVE-2024-56558, CVE-2024-56589, CVE-2024-56662, CVE-2024-56610, CVE-2024-56717, CVE-2024-57890, CVE-2024-55639, CVE-2024-56562, CVE-2025-21633, CVE-2024-56598, CVE-2024-47794, CVE-2024-41935, CVE-2024-57901, CVE-2024-56587, CVE-2024-56581, CVE-2024-56783, CVE-2024-57888, CVE-2024-57809, CVE-2024-57926, CVE-2025-21650, CVE-2024-56634, CVE-2025-21639, CVE-2025-21656, CVE-2024-56578, CVE-2025-21632, CVE-2024-56784, CVE-2025-21644, CVE-2024-56776, CVE-2024-56764, CVE-2024-56652, CVE-2024-56550, CVE-2024-56569, CVE-2024-57904, CVE-2024-49569, CVE-2024-56770, CVE-2024-56606, CVE-2024-57806, CVE-2024-56646, CVE-2024-57895, CVE-2024-57880, CVE-2024-56650, CVE-2024-56591, CVE-2024-56590, CVE-2024-56642, CVE-2024-56713, CVE-2025-21663, CVE-2024-57938, CVE-2024-56760, CVE-2024-56583, CVE-2025-21662, CVE-2024-56629, CVE-2024-47408, CVE-2024-57850, CVE-2024-56777, CVE-2024-56626, CVE-2024-56773, CVE-2024-56647, CVE-2025-21664, CVE-2024-56564, CVE-2024-56597, CVE-2024-56623, CVE-2024-57897, CVE-2024-56670, CVE-2024-56567, CVE-2024-57931, CVE-2024-56761, CVE-2024-57935, CVE-2024-53690, CVE-2025-21640, CVE-2024-56608, CVE-2024-57878, CVE-2025-21648, CVE-2024-57898, CVE-2024-57889, CVE-2024-56644, CVE-2024-56763, CVE-2024-57900,…

Attila Szász discovered that the HFS+ file system implementation in the Linux Kernel contained a heap overflow vulnerability. An attacker could use a specially crafted file system image that, when mounted, could cause a denial of service (system crash) or possibly execute arbitrary code. (CVE-2025-0927)

Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system. This update corrects flaws in the following subsystems:

• ARM64 architecture;
• MIPS architecture;
• PowerPC architecture;
• RISC-V architecture;
• S390 architecture;
• x86 architecture;
• Block layer subsystem;
• Compute Acceleration Framework;
• ACPI drivers;
• Drivers core;
• Ublk userspace block driver;
• Virtio block driver;
• Bluetooth drivers;
• Buffer Sharing and Synchronization framework;
• DMA engine subsystem;
• EFI core;
• GPIO subsystem;
• GPU drivers;
• HID subsystem;
• Microsoft Hyper-V drivers;
• Hardware monitoring drivers;
• I3C subsystem;
• IIO ADC drivers;
• IIO subsystem;
• InfiniBand drivers;
• IOMMU subsystem;
• LED subsystem;
• Multiple devices driver;
• Media drivers;
• Microchip PCI driver;
• MTD block device drivers;
• Network drivers;
• Mellanox network drivers;
• STMicroelectronics network drivers;
• NVME drivers;
• PCI subsystem;
• PHY drivers;
• Pin controllers subsystem;
• x86 platform drivers;
• i.MX PM domains;
• Power supply drivers;
• Voltage and Current Regulator drivers;
• SCSI subsystem;
• i.MX SoC drivers;
• SPI subsystem;
• UFS subsystem;
• USB Gadget drivers;
• TDX Guest driver;
• AFS file system;
• BTRFS file system;
• Ceph distributed file system;
• File systems infrastructure;
• F2FS file system;
• JFFS2 file system;
• JFS file system;
• Network file systems library;
• Network file system (NFS) server daemon;
• NILFS2 file system;
• File system notification infrastructure;
• Overlay file system;
• Diskquota system;
• SMB network file system;
• DRM display driver;
• BPF subsystem;
• VLANs driver;
• KASAN memory debugging framework;
• Memory management;
• StackDepot library;
• Bluetooth subsystem;
• LAPB network protocol;
• Network namespace;
• Netfilter;
• io_uring subsystem;
• Control group (cgroup);
• DMA mapping infrastructure;
• KCSAN framework;
• Scheduler infrastructure;
• Seccomp subsystem;
• Tracing infrastructure;
• Workqueue subsystem;
• KUnit library;
• CAN network layer;
• Networking core;
• DCCP (Datagram Congestion Control Protocol);
• HSR network protocol;
• IEEE802154.4 network protocol;
• IPv4 networking;
• IPv6 networking;
• MAC80211 subsystem;
• Multipath TCP;
• NET/ROM layer;
• Packet sockets;
• RDS protocol;
• Network traffic control;
• SCTP protocol;
• SMC sockets;
• TIPC protocol;
• Wireless networking;
• eXpress Data Path;
• SELinux security module;
• ALSA framework;
• Intel ASoC drivers;
• SOF drivers; (CVE-2024-56712, CVE-2024-56761, CVE-2025-21661, CVE-2024-56565, CVE-2024-57804, CVE-2024-57887, CVE-2025-21642, CVE-2024-56779, CVE-2025-21656, CVE-2024-57890, CVE-2024-36476, CVE-2024-57843, CVE-2024-56594, CVE-2024-41932, CVE-2025-21653, CVE-2024-56567, CVE-2024-56665, CVE-2024-54191, CVE-2024-57893, CVE-2024-57932, CVE-2024-56656, CVE-2024-57945, CVE-2024-57931, CVE-2024-56599, CVE-2024-57897, CVE-2024-57903, CVE-2024-57918, CVE-2024-57795, CVE-2024-56662, CVE-2025-21639, CVE-2024-55881, CVE-2024-57889, CVE-2024-57884, CVE-2024-57934, CVE-2024-39282, CVE-2024-56718, CVE-2024-56644, CVE-2024-56760, CVE-2024-43098, CVE-2024-47143, CVE-2024-55642, CVE-2024-56634, CVE-2024-56564, CVE-2024-56768, CVE-2024-56649, CVE-2024-57919, CVE-2024-56620, CVE-2024-56625, CVE-2024-56655, CVE-2024-56772, CVE-2025-21637, CVE-2024-56617, CVE-2024-57879, CVE-2024-56715, CVE-2024-56550, CVE-2024-50051, CVE-2024-56673, CVE-2024-51729, CVE-2025-21664,…

Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system. This update corrects flaws in the following subsystems:

• ARM64 architecture;
• MIPS architecture;
• PowerPC architecture;
• RISC-V architecture;
• S390 architecture;
• x86 architecture;
• Block layer subsystem;
• Compute Acceleration Framework;
• ACPI drivers;
• Drivers core;
• Ublk userspace block driver;
• Virtio block driver;
• Bluetooth drivers;
• Buffer Sharing and Synchronization framework;
• DMA engine subsystem;
• EFI core;
• GPIO subsystem;
• GPU drivers;
• HID subsystem;
• Microsoft Hyper-V drivers;
• Hardware monitoring drivers;
• I3C subsystem;
• IIO ADC drivers;
• IIO subsystem;
• InfiniBand drivers;
• IOMMU subsystem;
• LED subsystem;
• Multiple devices driver;
• Media drivers;
• Microchip PCI driver;
• MTD block device drivers;
• Network drivers;
• Mellanox network drivers;
• STMicroelectronics network drivers;
• NVME drivers;
• PCI subsystem;
• PHY drivers;
• Pin controllers subsystem;
• x86 platform drivers;
• i.MX PM domains;
• Power supply drivers;
• Voltage and Current Regulator drivers;
• SCSI subsystem;
• i.MX SoC drivers;
• SPI subsystem;
• UFS subsystem;
• USB Gadget drivers;
• TDX Guest driver;
• AFS file system;
• BTRFS file system;
• Ceph distributed file system;
• File systems infrastructure;
• F2FS file system;
• JFFS2 file system;
• JFS file system;
• Network file systems library;
• Network file system (NFS) server daemon;
• NILFS2 file system;
• File system notification infrastructure;
• Overlay file system;
• Diskquota system;
• SMB network file system;
• DRM display driver;
• BPF subsystem;
• VLANs driver;
• KASAN memory debugging framework;
• Memory management;
• StackDepot library;
• Bluetooth subsystem;
• LAPB network protocol;
• Netfilter;
• io_uring subsystem;
• Control group (cgroup);
• DMA mapping infrastructure;
• KCSAN framework;
• Scheduler infrastructure;
• Seccomp subsystem;
• Tracing infrastructure;
• Workqueue subsystem;
• KUnit library;
• CAN network layer;
• Networking core;
• DCCP (Datagram Congestion Control Protocol);
• HSR network protocol;
• IEEE802154.4 network protocol;
• IPv4 networking;
• IPv6 networking;
• MAC80211 subsystem;
• Multipath TCP;
• NET/ROM layer;
• Packet sockets;
• RDS protocol;
• Network traffic control;
• SCTP protocol;
• SMC sockets;
• TIPC protocol;
• Wireless networking;
• eXpress Data Path;
• SELinux security module;
• ALSA framework;
• Intel ASoC drivers;
• SOF drivers; (CVE-2024-47794, CVE-2025-21653, CVE-2024-55642, CVE-2024-56580, CVE-2024-36476, CVE-2024-56623, CVE-2024-56773, CVE-2024-48873, CVE-2024-47141, CVE-2024-57910, CVE-2024-56759, CVE-2024-54460, CVE-2024-57839, CVE-2024-56625, CVE-2024-55916, CVE-2025-21664, CVE-2025-21652, CVE-2024-56624, CVE-2024-56574, CVE-2024-50051, CVE-2025-21655, CVE-2024-56578, CVE-2024-56782, CVE-2024-57939, CVE-2024-57935, CVE-2024-56647, CVE-2024-57905, CVE-2024-57921, CVE-2024-56660, CVE-2025-21650, CVE-2025-21631, CVE-2024-56642, CVE-2024-56552, CVE-2024-57934, CVE-2024-56621, CVE-2024-57881, CVE-2024-41932, CVE-2024-56770, CVE-2024-57897, CVE-2024-56785, CVE-2024-56664, CVE-2024-57945, CVE-2024-57938, CVE-2024-56636, CVE-2024-56572, CVE-2024-43098, CVE-2024-56760, CVE-2024-57916, CVE-2024-56714, CVE-2025-21660, CVE-2024-57906, CVE-2025-21638, CVE-2024-53687, CVE-2024-56652, CVE-2024-51729, CVE-2024-49571, CVE-2024-57883, CVE-2024-54191, CVE-2024-56712, CVE-2024-49568, CVE-2024-57932, CVE-2024-57893, CVE-2024-56645, CVE-2024-56719, CVE-2024-56641, CVE-2024-57802, CVE-2024-56775, CVE-2024-56627, CVE-2024-56638, CVE-2024-57929, CVE-2024-56615, CVE-2024-56566, CVE-2024-56620, CVE-2024-56577, CVE-2025-21656, CVE-2024-57887, CVE-2024-52319, CVE-2024-56657, CVE-2024-57872,…