Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xen-netback: reject zero-queue configuration from guest<br /> <br /> A malicious or buggy Xen guest can write "0" to the xenbus key<br /> "multi-queue-num-queues". The connect() function in the backend only<br /> validates the upper bound (requested_num_queues &gt; xenvif_max_queues)<br /> but not zero, allowing requested_num_queues=0 to reach<br /> vzalloc(array_size(0, sizeof(struct xenvif_queue))), which triggers<br /> WARN_ON_ONCE(!size) in __vmalloc_node_range().<br /> <br /> On systems with panic_on_warn=1, this allows a guest-to-host denial<br /> of service.<br /> <br /> The Xen network interface specification requires<br /> the queue count to be "greater than zero".<br /> <br /> Add a zero check to match the validation already present<br /> in xen-blkback, which has included this<br /> guard since its multi-queue support was added.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hns3: fix double free issue for tx spare buffer<br /> <br /> In hns3_set_ringparam(), a temporary copy (tmp_rings) of the ring structure<br /> is created for rollback. However, the tx_spare pointer in the original<br /> ring handle is incorrectly left pointing to the old backup memory.<br /> <br /> Later, if memory allocation fails in hns3_init_all_ring() during the setup,<br /> the error path attempts to free all newly allocated rings. Since tx_spare<br /> contains a stale (non-NULL) pointer from the backup, it is mistaken for<br /> a newly allocated buffer and is erroneously freed, leading to a double-free<br /> of the backup memory.<br /> <br /> The root cause is that the tx_spare field was not cleared after its value<br /> was saved in tmp_rings, leaving a dangling pointer.<br /> <br /> Fix this by setting tx_spare to NULL in the original ring structure<br /> when the creation of the new `tx_spare` fails. This ensures the<br /> error cleanup path only frees genuinely newly allocated buffers.

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 /> apparmor: Fix &amp; Optimize table creation from possibly unaligned memory<br /> <br /> Source blob may come from userspace and might be unaligned.<br /> Try to optize the copying process by avoiding unaligned memory accesses.<br /> <br /> - Added Fixes tag<br /> - Added "Fix &amp;" to description as this doesn&amp;#39;t just optimize but fixes<br /> a potential unaligned memory access<br /> [jj: remove duplicate word "convert" in comment trigger checkpatch warning]

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 /> 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 /> 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.