CVE-2024-56655

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

netfilter: nf_tables: do not defer rule destruction via call_rcu

nf_tables_chain_destroy can sleep, it can't be used from call_rcu callbacks.

Moreover, nf_tables_rule_release() is only safe for error unwinding, while transaction mutex is held and the to-be-desroyed rule was not exposed to either dataplane or dumps, as it deactives+frees without the required synchronize_rcu() in-between.

nft_rule_expr_deactivate() callbacks will change ->use counters of other chains/sets, see e.g. nft_lookup .deactivate callback, these must be serialized via transaction mutex.

Also add a few lockdep asserts to make this more explicit.

Calling synchronize_rcu() isn't ideal, but fixing this without is hard and way more intrusive. As-is, we can get:

WARNING: .. net/netfilter/nf_tables_api.c:5515 nft_set_destroy+0x.. Workqueue: events nf_tables_trans_destroy_work RIP: 0010:nft_set_destroy+0x3fe/0x5c0 Call Trace: <TASK> nf_tables_trans_destroy_work+0x6b7/0xad0 process_one_work+0x64a/0xce0 worker_thread+0x613/0x10d0

In case the synchronize_rcu becomes an issue, we can explore alternatives.

One way would be to allocate nft_trans_rule objects + one nft_trans_chain object, deactivate the rules + the chain and then defer the freeing to the nft destroy workqueue. We'd still need to keep the synchronize_rcu path as a fallback to handle -ENOMEM corner cases though.

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: do not defer rule destruction via call_rcu nf_tables_chain_destroy can sleep, it can't be used from call_rcu callbacks. Moreover, nf_tables_rule_release() is only safe for error unwinding, while transaction mutex is held and the to-be-desroyed rule was not exposed to either dataplane or dumps, as it deactives+frees without the required synchronize_rcu() in-between. nft_rule_expr_deactivate() callbacks will change ->use counters of other chains/sets, see e.g. nft_lookup .deactivate callback, these must be serialized via transaction mutex. Also add a few lockdep asserts to make this more explicit. Calling synchronize_rcu() isn't ideal, but fixing this without is hard and way more intrusive. As-is, we can get: WARNING: .. net/netfilter/nf_tables_api.c:5515 nft_set_destroy+0x.. Workqueue: events nf_tables_trans_destroy_work RIP: 0010:nft_set_destroy+0x3fe/0x5c0 Call Trace: <TASK> nf_tables_trans_destroy_work+0x6b7/0xad0 process_one_work+0x64a/0xce0 worker_thread+0x613/0x10d0 In case the synchronize_rcu becomes an issue, we can explore alternatives. One way would be to allocate nft_trans_rule objects + one nft_trans_chain object, deactivate the rules + the chain and then defer the freeing to the nft destroy workqueue. We'd still need to keep the synchronize_rcu path as a fallback to handle -ENOMEM corner cases though.

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

bpf: Prevent tailcall infinite loop caused by freplace

There is a potential infinite loop issue that can occur when using a combination of tail calls and freplace.

In an upcoming selftest, the attach target for entry_freplace of tailcall_freplace.c is subprog_tc of tc_bpf2bpf.c, while the tail call in entry_freplace leads to entry_tc. This results in an infinite loop:

entry_tc -> subprog_tc -> entry_freplace --tailcall-> entry_tc.

The problem arises because the tail_call_cnt in entry_freplace resets to zero each time entry_freplace is executed, causing the tail call mechanism to never terminate, eventually leading to a kernel panic.

To fix this issue, the solution is twofold:

1. Prevent updating a program extended by an freplace program to a prog_array map.
2. Prevent extending a program that is already part of a prog_array map with an freplace program.

This ensures that:

• If a program or its subprogram has been extended by an freplace program, it can no longer be updated to a prog_array map.
• If a program has been added to a prog_array map, neither it nor its subprograms can be extended by an freplace program.

Moreover, an extension program should not be tailcalled. As such, return -EINVAL if the program has a type of BPF_PROG_TYPE_EXT when adding it to a prog_array map.

Additionally, fix a minor code style issue by replacing eight spaces with a tab for proper formatting.(CVE-2024-47794)

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

mm/thp: fix deferred split unqueue naming and locking

Recent changes are putting more pressure on THP deferred split queues: under load revealing long-standing races, causing list_del corruptions, "Bad page state"s and worse (I keep BUGs in both of those, so usually don't get to see how badly they end up without). The relevant recent changes being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP splitting.

Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo large_rmappable, to folio_unqueue_deferred_split(), which is what it does. But that and its out-of-line __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()).

Just omit the folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer has any callers (and will be deleted separately).

Swapout: mem_cgroup_swapout() has been resetting folio->memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is unfortunate, since the split_queue_lock depends on the memcg (when memcg is enabled); so swapout has been unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting the memcg's list. __remove_mapping() has frozen refcount to 0 here, so no problem with calling folio_unqueue_deferred_split() before resetting memcg_data.

That goes back to 5.4 commit 87eaceb3faa5 ("mm: thp: make deferred split shrinker memcg aware"): which included a check on swapcache before adding to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 ("mm: split underused THPs") avoids splitting underused THPs in reclaim, which makes swapcache THPs…

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

bpf: Prevent tailcall infinite loop caused by freplace

There is a potential infinite loop issue that can occur when using a combination of tail calls and freplace.

In an upcoming selftest, the attach target for entry_freplace of tailcall_freplace.c is subprog_tc of tc_bpf2bpf.c, while the tail call in entry_freplace leads to entry_tc. This results in an infinite loop:

entry_tc -> subprog_tc -> entry_freplace --tailcall-> entry_tc.

The problem arises because the tail_call_cnt in entry_freplace resets to zero each time entry_freplace is executed, causing the tail call mechanism to never terminate, eventually leading to a kernel panic.

To fix this issue, the solution is twofold:

1. Prevent updating a program extended by an freplace program to a prog_array map.
2. Prevent extending a program that is already part of a prog_array map with an freplace program.

This ensures that:

• If a program or its subprogram has been extended by an freplace program, it can no longer be updated to a prog_array map.
• If a program has been added to a prog_array map, neither it nor its subprograms can be extended by an freplace program.

Moreover, an extension program should not be tailcalled. As such, return -EINVAL if the program has a type of BPF_PROG_TYPE_EXT when adding it to a prog_array map.

Additionally, fix a minor code style issue by replacing eight spaces with a tab for proper formatting.(CVE-2024-47794)

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

mm/thp: fix deferred split unqueue naming and locking

Recent changes are putting more pressure on THP deferred split queues: under load revealing long-standing races, causing list_del corruptions, "Bad page state"s and worse (I keep BUGs in both of those, so usually don't get to see how badly they end up without). The relevant recent changes being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP splitting.

Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo large_rmappable, to folio_unqueue_deferred_split(), which is what it does. But that and its out-of-line __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()).

Just omit the folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer has any callers (and will be deleted separately).

Swapout: mem_cgroup_swapout() has been resetting folio->memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is unfortunate, since the split_queue_lock depends on the memcg (when memcg is enabled); so swapout has been unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting the memcg's list. __remove_mapping() has frozen refcount to 0 here, so no problem with calling folio_unqueue_deferred_split() before resetting memcg_data.

That goes back to 5.4 commit 87eaceb3faa5 ("mm: thp: make deferred split shrinker memcg aware"): which included a check on swapcache before adding to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 ("mm: split underused THPs") avoids splitting underused THPs in reclaim, which makes swapcache THPs…

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: do not defer rule destruction via call_rcu nf_tables_chain_destroy can sleep, it can't be used from call_rcu callbacks. Moreover, nf_tables_rule_release() is only safe for error unwinding, while transaction mutex is held and the to-be-desroyed rule was not exposed to either dataplane or dumps, as it deactives+frees without the required synchronize_rcu() in-between. nft_rule_expr_deactivate() callbacks will change ->use counters of other chains/sets, see e.g. nft_lookup .deactivate callback, these must be serialized via transaction mutex. Also add a few lockdep asserts to make this more explicit. Calling synchronize_rcu() isn't ideal, but fixing this without is hard and way more intrusive. As-is, we can get: WARNING: .. net/netfilter/nf_tables_api.c:5515 nft_set_destroy+0x.. Workqueue: events nf_tables_trans_destroy_work RIP: 0010:nft_set_destroy+0x3fe/0x5c0 Call Trace: <TASK> nf_tables_trans_destroy_work+0x6b7/0xad0 process_one_work+0x64a/0xce0 worker_thread+0x613/0x10d0 In case the synchronize_rcu becomes an issue, we can explore alternatives. One way would be to allocate nft_trans_rule objects + one nft_trans_chain object, deactivate the rules + the chain and then defer the freeing to the nft destroy workqueue. We'd still need to keep the synchronize_rcu path as a fallback to handle -ENOMEM corner cases though.

• rds: tcp: block BH in TCP callbacks
• kexec: Improve & fix crash_exclude_mem_range() to handle overlapping ranges
• module: correctly exit module_kallsyms_on_each_symbol when fn() != 0
• module: potential uninitialized return in module_kallsyms_on_each_symbol()
• module: use RCU to synchronize find_module
• kallsyms: refactor {,module_}kallsyms_on_each_symbol
• LTS tag: v5.4.295
• scsi: qedf: Use designated initializer for struct qed_fcoe_cb_ops
• arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth() {CVE-2025-38320}
• perf: Fix sample vs do_exit() {CVE-2025-38424}
• s390/pci: Fix __pcilg_mio_inuser() inline assembly
• rtc: test: Fix invalid format specifier.
• jbd2: fix data-race and null-ptr-deref in jbd2_journal_dirty_metadata() {CVE-2025-38337}
• mm/huge_memory: fix dereferencing invalid pmd migration entry {CVE-2025-37958}
• rtc: Make rtc_time64_to_tm() support dates before 1970
• rtc: Improve performance of rtc_time64_to_tm(). Add tests.
• xprtrdma: fix pointer derefs in error cases of rpcrdma_ep_create {CVE-2022-48773}
• posix-cpu-timers: fix race between handle_posix_cpu_timers() and posix_cpu_timer_del() {CVE-2025-38352}
• ARM: dts: am335x-bone-common: Increase MDIO reset deassert delay to 50ms
• ARM: dts: am335x-bone-common: Increase MDIO reset deassert time
• ARM: dts: am335x-bone-common: Add GPIO PHY reset on revision C3 board
• net: atm: fix /proc/net/atm/lec handling {CVE-2025-38180}
• net: atm: add lec_mutex {CVE-2025-38323}
• calipso: Fix null-ptr-deref in calipso_req_{set,del}attr(). {CVE-2025-38181}
• tipc: fix null-ptr-deref when acquiring remote ip of ethernet bearer {CVE-2025-38184}
• tcp: fix tcp_packet_delayed() for tcp_is_non_sack_preventing_reopen() behavior
• atm: atmtcp: Free invalid length skb in atmtcp_c_send(). {CVE-2025-38185}
• mpls: Use rcu_dereference_rtnl() in mpls_route_input_rcu(). {CVE-2025-38324}
• wifi: carl9170: do not ping device which has failed to load firmware {CVE-2025-38420}
• aoe: clean device rq_list in aoedev_downdev() {CVE-2025-38326}
• hwmon: (occ) fix unaligned accesses
• drm/nouveau/bl: increase buffer size to avoid truncate warning
• erofs: remove unused trace event erofs_destroy_inode
• ALSA: hda/realtek: enable headset mic on Latitude 5420 Rugged
• ALSA: hda/intel: Add Thinkpad E15 to PM deny list
• Input: sparcspkr - avoid unannotated fall-through
• HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse() {CVE-2025-38103}
• atm: Revert atm_account_tx() if copy_from_iter_full() fails. {CVE-2025-38190}
• selinux: fix selinux_xfrm_alloc_user() to set correct ctx_len
• scsi: s390: zfcp: Ensure synchronous unit_add
• scsi: storvsc: Increase the timeouts to storvsc_timeout
• jffs2: check jffs2_prealloc_raw_node_refs() result in few other places {CVE-2025-38328}
• jffs2: check that raw node were preallocated before writing summary {CVE-2025-38194}
• drivers/rapidio/rio_cm.c: prevent possible heap overwrite {CVE-2025-38090}
• powerpc/eeh: Fix missing PE bridge reconfiguration during VFIO EEH recovery
• platform/x86: dell_rbu: Stop overwriting data buffer
• platform: Add Surface platform directory
• Revert "bus: ti-sysc: Probe for l4_wkup and l4_cfg interconnect devices first"
• tee: Prevent size calculation wraparound on 32-bit kernels
• ARM: OMAP2+: Fix l4ls clk domain handling in STANDBY
• bus: fsl-mc: increase MC_CMD_COMPLETION_TIMEOUT_MS value
• watchdog: da9052_wdt: respect TWDMIN
• i40e: fix MMIO write access to an invalid page in i40e_clear_hw {CVE-2025-38200}
• sock: Correct error checking condition for (assign|release)_proto_idx()
• scsi: lpfc: Use memcpy() for BIOS version {CVE-2025-38332}
• vxlan: Do not treat dst cache initialization errors as fatal
• clk: rockchip: rk3036: mark ddrphy as critical
• wifi: mac80211: do not offer a mesh path if forwarding is disabled
• net: mlx4: add SOF_TIMESTAMPING_TX_SOFTWARE flag when getting ts info
• pinctrl: armada-37xx: propagate error from armada_37xx_gpio_get()
• pinctrl: armada-37xx:…

Upstream kernel version 6.6.74 fixes bugs and vulnerabilities. The kmod-virtualbox and kmod-xtables-addons packages have been updated to work with this new kernel. For information about the vulnerabilities see the links.

Vanilla upstream kernel version 6.6.74 fixes bugs and vulnerabilities. For information about the vulnerabilities see the links.

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,…