Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> quota: fix livelock between quotactl and freeze_super<br /> <br /> When a filesystem is frozen, quotactl_block() enters a retry loop<br /> waiting for the filesystem to thaw. It acquires s_umount, checks the<br /> freeze state, drops s_umount and uses sb_start_write() - sb_end_write()<br /> pair to wait for the unfreeze.<br /> <br /> However, this retry loop can trigger a livelock issue, specifically on<br /> kernels with preemption disabled.<br /> <br /> The mechanism is as follows:<br /> 1. freeze_super() sets SB_FREEZE_WRITE and calls sb_wait_write().<br /> 2. sb_wait_write() calls percpu_down_write(), which initiates<br /> synchronize_rcu().<br /> 3. Simultaneously, quotactl_block() spins in its retry loop, immediately<br /> executing the sb_start_write() - sb_end_write() pair.<br /> 4. Because the kernel is non-preemptible and the loop contains no<br /> scheduling points, quotactl_block() never yields the CPU. This<br /> prevents that CPU from reaching an RCU quiescent state.<br /> 5. synchronize_rcu() in the freezer thread waits indefinitely for the<br /> quotactl_block() CPU to report a quiescent state.<br /> 6. quotactl_block() spins indefinitely waiting for the freezer to<br /> advance, which it cannot do as it is blocked on the RCU sync.<br /> <br /> This results in a hang of the freezer process and 100% CPU usage by the<br /> quota process.<br /> <br /> While this can occur intermittently on multi-core systems, it is<br /> reliably reproducing on a node with the following script, running both<br /> the freezer and the quota toggle on the same CPU:<br /> <br /> # mkfs.ext4 -O quota /dev/sda 2g &amp;&amp; mkdir a_mount<br /> # mount /dev/sda -o quota,usrquota,grpquota a_mount<br /> # taskset -c 3 bash -c "while true; do xfs_freeze -f a_mount; \<br /> xfs_freeze -u a_mount; done" &amp;<br /> # taskset -c 3 bash -c "while true; do quotaon a_mount; \<br /> quotaoff a_mount; done" &amp;<br /> <br /> Adding cond_resched() to the retry loop fixes the issue. It acts as an<br /> RCU quiescent state, allowing synchronize_rcu() in percpu_down_write()<br /> to complete.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: intel-dg: Fix accessing regions before setting nregions<br /> <br /> The regions array is counted by nregions, but it&amp;#39;s set only after<br /> accessing it:<br /> <br /> [] UBSAN: array-index-out-of-bounds in drivers/mtd/devices/mtd_intel_dg.c:750:15<br /> [] index 0 is out of range for type &amp;#39; [*]&amp;#39;<br /> <br /> Fix it by also fixing an undesired behavior: the loop silently ignores<br /> ENOMEM and continues setting the other entries.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_counter: serialize reset with spinlock<br /> <br /> Add a global static spinlock to serialize counter fetch+reset<br /> operations, preventing concurrent dump-and-reset from underrunning<br /> values.<br /> <br /> The lock is taken before fetching the total so that two parallel<br /> resets cannot both read the same counter values and then both<br /> subtract them.<br /> <br /> A global lock is used for simplicity since resets are infrequent.<br /> If this becomes a bottleneck, it can be replaced with a per-net<br /> lock later.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: drop extent cache after doing PARTIAL_VALID1 zeroout<br /> <br /> When splitting an unwritten extent in the middle and converting it to<br /> initialized in ext4_split_extent() with the EXT4_EXT_MAY_ZEROOUT and<br /> EXT4_EXT_DATA_VALID2 flags set, it could leave a stale unwritten extent.<br /> <br /> Assume we have an unwritten file and buffered write in the middle of it<br /> without dioread_nolock enabled, it will allocate blocks as written<br /> extent.<br /> <br /> 0 A B N<br /> [UUUUUUUUUUUU] on-disk extent U: unwritten extent<br /> [UUUUUUUUUUUU] extent status tree<br /> [--DDDDDDDD--] D: valid data<br /> || ----&gt; this range needs to be initialized<br /> <br /> ext4_split_extent() first try to split this extent at B with<br /> EXT4_EXT_DATA_PARTIAL_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but<br /> ext4_split_extent_at() failed to split this extent due to temporary lack<br /> of space. It zeroout B to N and leave the entire extent as unwritten.<br /> <br /> 0 A B N<br /> [UUUUUUUUUUUU] on-disk extent<br /> [UUUUUUUUUUUU] extent status tree<br /> [--DDDDDDDDZZ] Z: zeroed data<br /> <br /> ext4_split_extent() then try to split this extent at A with<br /> EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and<br /> leave an written extent from A to N.<br /> <br /> 0 A B N<br /> [UUWWWWWWWWWW] on-disk extent W: written extent<br /> [UUUUUUUUUUUU] extent status tree<br /> [--DDDDDDDDZZ]<br /> <br /> Finally ext4_map_create_blocks() only insert extent A to B to the extent<br /> status tree, and leave an stale unwritten extent in the status tree.<br /> <br /> 0 A B N<br /> [UUWWWWWWWWWW] on-disk extent W: written extent<br /> [UUWWWWWWWWUU] extent status tree<br /> [--DDDDDDDDZZ]<br /> <br /> Fix this issue by always cached extent status entry after zeroing out<br /> the second part.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Clear Present bit before tearing down PASID entry<br /> <br /> The Intel VT-d Scalable Mode PASID table entry consists of 512 bits (64<br /> bytes). When tearing down an entry, the current implementation zeros the<br /> entire 64-byte structure immediately using multiple 64-bit writes.<br /> <br /> Since the IOMMU hardware may fetch these 64 bytes using multiple<br /> internal transactions (e.g., four 128-bit bursts), updating or zeroing<br /> the entire entry while it is active (P=1) risks a "torn" read. If a<br /> hardware fetch occurs simultaneously with the CPU zeroing the entry, the<br /> hardware could observe an inconsistent state, leading to unpredictable<br /> behavior or spurious faults.<br /> <br /> Follow the "Guidance to Software for Invalidations" in the VT-d spec<br /> (Section 6.5.3.3) by implementing the recommended ownership handshake:<br /> <br /> 1. Clear only the &amp;#39;Present&amp;#39; (P) bit of the PASID entry.<br /> 2. Use a dma_wmb() to ensure the cleared bit is visible to hardware<br /> before proceeding.<br /> 3. Execute the required invalidation sequence (PASID cache, IOTLB, and<br /> Device-TLB flush) to ensure the hardware has released all cached<br /> references.<br /> 4. Only after the flushes are complete, zero out the remaining fields<br /> of the PASID entry.<br /> <br /> Also, add a dma_wmb() in pasid_set_present() to ensure that all other<br /> fields of the PASID entry are visible to the hardware before the Present<br /> bit is set.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: pm8916_bms_vm: Fix use-after-free in power_supply_changed()<br /> <br /> Using the `devm_` variant for requesting IRQ _before_ the `devm_`<br /> variant for allocating/registering the `power_supply` handle, means that<br /> the `power_supply` handle will be deallocated/unregistered _before_ the<br /> interrupt handler (since `devm_` naturally deallocates in reverse<br /> allocation order). This means that during removal, there is a race<br /> condition where an interrupt can fire just _after_ the `power_supply`<br /> handle has been freed, *but* just _before_ the corresponding<br /> unregistration of the IRQ handler has run.<br /> <br /> This will lead to the IRQ handler calling `power_supply_changed()` with<br /> a freed `power_supply` handle. Which usually crashes the system or<br /> otherwise silently corrupts the memory...<br /> <br /> Note that there is a similar situation which can also happen during<br /> `probe()`; the possibility of an interrupt firing _before_ registering<br /> the `power_supply` handle. This would then lead to the nasty situation<br /> of using the `power_supply` handle *uninitialized* in<br /> `power_supply_changed()`.<br /> <br /> Fix this racy use-after-free by making sure the IRQ is requested _after_<br /> the registration of the `power_supply` handle.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: sca3000: Fix a resource leak in sca3000_probe()<br /> <br /> spi-&gt;irq from request_threaded_irq() not released when<br /> iio_device_register() fails. Add an return value check and jump to a<br /> common error handler when iio_device_register() fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> apparmor: avoid per-cpu hold underflow in aa_get_buffer<br /> <br /> When aa_get_buffer() pulls from the per-cpu list it unconditionally<br /> decrements cache-&gt;hold. If hold reaches 0 while count is still non-zero,<br /> the unsigned decrement wraps to UINT_MAX. This keeps hold non-zero for a<br /> very long time, so aa_put_buffer() never returns buffers to the global<br /> list, which can starve other CPUs and force repeated kmalloc(aa_g_path_max)<br /> allocations.<br /> <br /> Guard the decrement so hold never underflows.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: cpcap-battery: Fix use-after-free in power_supply_changed()<br /> <br /> Using the `devm_` variant for requesting IRQ _before_ the `devm_`<br /> variant for allocating/registering the `power_supply` handle, means that<br /> the `power_supply` handle will be deallocated/unregistered _before_ the<br /> interrupt handler (since `devm_` naturally deallocates in reverse<br /> allocation order). This means that during removal, there is a race<br /> condition where an interrupt can fire just _after_ the `power_supply`<br /> handle has been freed, *but* just _before_ the corresponding<br /> unregistration of the IRQ handler has run.<br /> <br /> This will lead to the IRQ handler calling `power_supply_changed()` with<br /> a freed `power_supply` handle. Which usually crashes the system or<br /> otherwise silently corrupts the memory...<br /> <br /> Note that there is a similar situation which can also happen during<br /> `probe()`; the possibility of an interrupt firing _before_ registering<br /> the `power_supply` handle. This would then lead to the nasty situation<br /> of using the `power_supply` handle *uninitialized* in<br /> `power_supply_changed()`.<br /> <br /> Fix this racy use-after-free by making sure the IRQ is requested _after_<br /> the registration of the `power_supply` handle.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix bpf_xdp_store_bytes proto for read-only arg<br /> <br /> While making some maps in Cilium read-only from the BPF side, we noticed<br /> that the bpf_xdp_store_bytes proto is incorrect. In particular, the<br /> verifier was throwing the following error:<br /> <br /> ; ret = ctx_store_bytes(ctx, l3_off + offsetof(struct iphdr, saddr),<br /> &amp;nat-&gt;address, 4, 0);<br /> 635: (79) r1 = *(u64 *)(r10 -144) ; R1=ctx() R10=fp0 fp-144=ctx()<br /> 636: (b4) w2 = 26 ; R2=26<br /> 637: (b4) w4 = 4 ; R4=4<br /> 638: (b4) w5 = 0 ; R5=0<br /> 639: (85) call bpf_xdp_store_bytes#190<br /> write into map forbidden, value_size=6 off=0 size=4<br /> <br /> nat comes from a BPF_F_RDONLY_PROG map, so R3 is a PTR_TO_MAP_VALUE.<br /> The verifier checks the helper&amp;#39;s memory access to R3 in<br /> check_mem_size_reg, as it reaches ARG_CONST_SIZE argument. The third<br /> argument has expected type ARG_PTR_TO_UNINIT_MEM, which includes the<br /> MEM_WRITE flag. The verifier thus checks for a BPF_WRITE access on R3.<br /> Given R3 points to a read-only map, the check fails.<br /> <br /> Conversely, ARG_PTR_TO_UNINIT_MEM can also lead to the helper reading<br /> from uninitialized memory.<br /> <br /> This patch simply fixes the expected argument type to match that of<br /> bpf_skb_store_bytes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_unix: Fix memleak of newsk in unix_stream_connect().<br /> <br /> When prepare_peercred() fails in unix_stream_connect(),<br /> unix_release_sock() is not called for newsk, and the memory<br /> is leaked.<br /> <br /> Let&amp;#39;s move prepare_peercred() before unix_create1().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid1: fix memory leak in raid1_run()<br /> <br /> raid1_run() calls setup_conf() which registers a thread via<br /> md_register_thread(). If raid1_set_limits() fails, the previously<br /> registered thread is not unregistered, resulting in a memory leak<br /> of the md_thread structure and the thread resource itself.<br /> <br /> Add md_unregister_thread() to the error path to properly cleanup<br /> the thread, which aligns with the error handling logic of other paths<br /> in this function.<br /> <br /> Compile tested only. Issue found using a prototype static analysis tool<br /> and code review.