Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: revert commit_mutex usage in reset path<br /> <br /> It causes circular lock dependency between commit_mutex, nfnl_subsys_ipset<br /> and nlk_cb_mutex when nft reset, ipset list, and iptables-nft with &amp;#39;-m set&amp;#39;<br /> rule run at the same time.<br /> <br /> Previous patches made it safe to run individual reset handlers concurrently<br /> so commit_mutex is no longer required to prevent this.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: caam - fix netdev memory leak in dpaa2_caam_probe<br /> <br /> When commit 0e1a4d427f58 ("crypto: caam: Unembed net_dev structure in<br /> dpaa2") converted embedded net_device to dynamically allocated pointers,<br /> it added cleanup in dpaa2_dpseci_disable() but missed adding cleanup in<br /> dpaa2_dpseci_free() for error paths.<br /> <br /> This causes memory leaks when dpaa2_dpseci_dpio_setup() fails during probe<br /> due to DPIO devices not being ready yet. The kernel&amp;#39;s deferred probe<br /> mechanism handles the retry successfully, but the netdevs allocated during<br /> the failed probe attempt are never freed, resulting in kmemleak reports<br /> showing multiple leaked netdev-related allocations all traced back to<br /> dpaa2_caam_probe().<br /> <br /> Fix this by preserving the CPU mask of allocated netdevs during setup and<br /> using it for cleanup in dpaa2_dpseci_free(). This approach ensures that<br /> only the CPUs that actually had netdevs allocated will be cleaned up,<br /> avoiding potential issues with CPU hotplug scenarios.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/iwcm: Fix workqueue list corruption by removing work_list<br /> <br /> The commit e1168f0 ("RDMA/iwcm: Simplify cm_event_handler()")<br /> changed the work submission logic to unconditionally call<br /> queue_work() with the expectation that queue_work() would<br /> have no effect if work was already pending. The problem is<br /> that a free list of struct iwcm_work is used (for which<br /> struct work_struct is embedded), so each call to queue_work()<br /> is basically unique and therefore does indeed queue the work.<br /> <br /> This causes a problem in the work handler which walks the work_list<br /> until it&amp;#39;s empty to process entries. This means that a single<br /> run of the work handler could process item N+1 and release it<br /> back to the free list while the actual workqueue entry is still<br /> queued. It could then get reused (INIT_WORK...) and lead to<br /> list corruption in the workqueue logic.<br /> <br /> Fix this by just removing the work_list. The workqueue already<br /> does this for us.<br /> <br /> This fixes the following error that was observed when stress<br /> testing with ucmatose on an Intel E830 in iWARP mode:<br /> <br /> [ 151.465780] list_del corruption. next-&gt;prev should be ffff9f0915c69c08, but was ffff9f0a1116be08. (next=ffff9f0a15b11c08)<br /> [ 151.466639] ------------[ cut here ]------------<br /> [ 151.466986] kernel BUG at lib/list_debug.c:67!<br /> [ 151.467349] Oops: invalid opcode: 0000 [#1] SMP NOPTI<br /> [ 151.467753] CPU: 14 UID: 0 PID: 2306 Comm: kworker/u64:18 Not tainted 6.19.0-rc4+ #1 PREEMPT(voluntary)<br /> [ 151.468466] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 151.469192] Workqueue: 0x0 (iw_cm_wq)<br /> [ 151.469478] RIP: 0010:__list_del_entry_valid_or_report+0xf0/0x100<br /> [ 151.469942] Code: c7 58 5f 4c b2 e8 10 50 aa ff 0f 0b 48 89 ef e8 36 57 cb ff 48 8b 55 08 48 89 e9 48 89 de 48 c7 c7 a8 5f 4c b2 e8 f0 4f aa ff 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90<br /> [ 151.471323] RSP: 0000:ffffb15644e7bd68 EFLAGS: 00010046<br /> [ 151.471712] RAX: 000000000000006d RBX: ffff9f0915c69c08 RCX: 0000000000000027<br /> [ 151.472243] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9f0a37d9c600<br /> [ 151.472768] RBP: ffff9f0a15b11c08 R08: 0000000000000000 R09: c0000000ffff7fff<br /> [ 151.473294] R10: 0000000000000001 R11: ffffb15644e7bba8 R12: ffff9f092339ee68<br /> [ 151.473817] R13: ffff9f0900059c28 R14: ffff9f092339ee78 R15: 0000000000000000<br /> [ 151.474344] FS: 0000000000000000(0000) GS:ffff9f0a847b5000(0000) knlGS:0000000000000000<br /> [ 151.474934] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 151.475362] CR2: 0000559e233a9088 CR3: 000000020296b004 CR4: 0000000000770ef0<br /> [ 151.475895] PKRU: 55555554<br /> [ 151.476118] Call Trace:<br /> [ 151.476331] <br /> [ 151.476497] move_linked_works+0x49/0xa0<br /> [ 151.476792] __pwq_activate_work.isra.46+0x2f/0xa0<br /> [ 151.477151] pwq_dec_nr_in_flight+0x1e0/0x2f0<br /> [ 151.477479] process_scheduled_works+0x1c8/0x410<br /> [ 151.477823] worker_thread+0x125/0x260<br /> [ 151.478108] ? __pfx_worker_thread+0x10/0x10<br /> [ 151.478430] kthread+0xfe/0x240<br /> [ 151.478671] ? __pfx_kthread+0x10/0x10<br /> [ 151.478955] ? __pfx_kthread+0x10/0x10<br /> [ 151.479240] ret_from_fork+0x208/0x270<br /> [ 151.479523] ? __pfx_kthread+0x10/0x10<br /> [ 151.479806] ret_from_fork_asm+0x1a/0x30<br /> [ 151.480103]

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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]

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.