Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: fix a resource leak in xfs_alloc_buftarg()<br /> <br /> In the error path, call fs_put_dax() to drop the DAX<br /> device reference.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/nouveau: fix u32 overflow in pushbuf reloc bounds check<br /> <br /> nouveau_gem_pushbuf_reloc_apply() validates each relocation with<br /> <br /> if (r-&gt;reloc_bo_offset + 4 &gt; nvbo-&gt;bo.base.size)<br /> <br /> but reloc_bo_offset is __u32 (uapi/drm/nouveau_drm.h) and the integer<br /> literal 4 promotes to unsigned int, so the addition is performed in 32<br /> bits and wraps before the comparison against the size_t bo size.<br /> <br /> Cast to u64 so the addition happens in 64-bit arithmetic.<br /> <br /> [ Add Fixes: tag. - Danilo ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix conn-level packet handling to unshare RESPONSE packets<br /> <br /> The security operations that verify the RESPONSE packets decrypt bits of it<br /> in place - however, the sk_buff may be shared with a packet sniffer, which<br /> would lead to the sniffer seeing an apparently corrupt packet (actually<br /> decrypted).<br /> <br /> Fix this by handing a copy of the packet off to the specific security<br /> handler if the packet was cloned.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: sd: fix missing put_disk() when device_add(&amp;disk_dev) fails<br /> <br /> If device_add(&amp;sdkp-&gt;disk_dev) fails, put_device() runs<br /> scsi_disk_release(), which frees the scsi_disk but leaves the gendisk<br /> referenced. The device_add_disk() error path in sd_probe() calls<br /> put_disk(gd); call put_disk(gd) here to mirror that cleanup.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/zcrx: fix user_struct uaf<br /> <br /> io_free_rbuf_ring() usees a struct user_struct, which<br /> io_zcrx_ifq_free() puts it down before destroying the ring.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext2: reject inodes with zero i_nlink and valid mode in ext2_iget()<br /> <br /> ext2_iget() already rejects inodes with i_nlink == 0 when i_mode is<br /> zero or i_dtime is set, treating them as deleted. However, the case of<br /> i_nlink == 0 with a non-zero mode and zero dtime slips through. Since<br /> ext2 has no orphan list, such a combination can only result from<br /> filesystem corruption - a legitimate inode deletion always sets either<br /> i_dtime or clears i_mode before freeing the inode.<br /> <br /> A crafted image can exploit this gap to present such an inode to the<br /> VFS, which then triggers WARN_ON inside drop_nlink() (fs/inode.c) via<br /> ext2_unlink(), ext2_rename() and ext2_rmdir():<br /> <br /> WARNING: CPU: 3 PID: 609 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336<br /> CPU: 3 UID: 0 PID: 609 Comm: syz-executor Not tainted 6.12.77+ #1<br /> Call Trace:<br /> <br /> inode_dec_link_count include/linux/fs.h:2518 [inline]<br /> ext2_unlink+0x26c/0x300 fs/ext2/namei.c:295<br /> vfs_unlink+0x2fc/0x9b0 fs/namei.c:4477<br /> do_unlinkat+0x53e/0x730 fs/namei.c:4541<br /> __x64_sys_unlink+0xc6/0x110 fs/namei.c:4587<br /> do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> <br /> WARNING: CPU: 0 PID: 646 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336<br /> CPU: 0 UID: 0 PID: 646 Comm: syz.0.17 Not tainted 6.12.77+ #1<br /> Call Trace:<br /> <br /> inode_dec_link_count include/linux/fs.h:2518 [inline]<br /> ext2_rename+0x35e/0x850 fs/ext2/namei.c:374<br /> vfs_rename+0xf2f/0x2060 fs/namei.c:5021<br /> do_renameat2+0xbe2/0xd50 fs/namei.c:5178<br /> __x64_sys_rename+0x7e/0xa0 fs/namei.c:5223<br /> do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> <br /> WARNING: CPU: 0 PID: 634 at fs/inode.c:336 drop_nlink+0xad/0xd0 fs/inode.c:336<br /> CPU: 0 UID: 0 PID: 634 Comm: syz-executor Not tainted 6.12.77+ #1<br /> Call Trace:<br /> <br /> inode_dec_link_count include/linux/fs.h:2518 [inline]<br /> ext2_rmdir+0xca/0x110 fs/ext2/namei.c:311<br /> vfs_rmdir+0x204/0x690 fs/namei.c:4348<br /> do_rmdir+0x372/0x3e0 fs/namei.c:4407<br /> __x64_sys_unlinkat+0xf0/0x130 fs/namei.c:4577<br /> do_syscall_64+0xf5/0x220 arch/x86/entry/common.c:78<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> <br /> Extend the existing i_nlink == 0 check to also catch this case,<br /> reporting the corruption via ext2_error() and returning -EFSCORRUPTED.<br /> This rejects the inode at load time and prevents it from reaching any<br /> of the namei.c paths.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (pt5161l) Fix bugs in pt5161l_read_block_data()<br /> <br /> Fix two bugs in pt5161l_read_block_data():<br /> <br /> 1. Buffer overrun: The local buffer rbuf is declared as u8 rbuf[24],<br /> but i2c_smbus_read_block_data() can return up to<br /> I2C_SMBUS_BLOCK_MAX (32) bytes. The i2c-core copies the data into<br /> the caller&amp;#39;s buffer before the return value can be checked, so<br /> the post-read length validation does not prevent a stack overrun<br /> if a device returns more than 24 bytes. Resize the buffer to<br /> I2C_SMBUS_BLOCK_MAX.<br /> <br /> 2. Unexpected positive return on length mismatch: When all three<br /> retries are exhausted because the device returns data with an<br /> unexpected length, i2c_smbus_read_block_data() returns a positive<br /> byte count. The function returns this directly, and callers treat<br /> any non-negative return as success, processing stale or incomplete<br /> buffer contents. Return -EIO when retries are exhausted with a<br /> positive return value, preserving the negative error code on I2C<br /> failure.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: imx: fix use-after-free on unbind<br /> <br /> The SPI subsystem frees the controller and any subsystem allocated<br /> driver data as part of deregistration (unless the allocation is device<br /> managed).<br /> <br /> Take another reference before deregistering the controller so that the<br /> driver data is not freed until the driver is done with it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: fix unsigned underflow in z_erofs_lz4_handle_overlap()<br /> <br /> Some crafted images can have illegal (!partial_decoding &amp;&amp;<br /> m_llen

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix potential UAF after skb_unshare() failure<br /> <br /> If skb_unshare() fails to unshare a packet due to allocation failure in<br /> rxrpc_input_packet(), the skb pointer in the parent (rxrpc_io_thread())<br /> will be NULL&amp;#39;d out. This will likely cause the call to<br /> trace_rxrpc_rx_done() to oops.<br /> <br /> Fix this by moving the unsharing down to where rxrpc_input_call_event()<br /> calls rxrpc_input_call_packet(). There are a number of places prior to<br /> that where we ignore DATA packets for a variety of reasons (such as the<br /> call already being complete) for which an unshare is then avoided.<br /> <br /> And with that, rxrpc_input_packet() doesn&amp;#39;t need to take a pointer to the<br /> pointer to the packet, so change that to just a pointer.

*** Pendiente de traducción *** Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ibmasm: fix OOB reads in command_file_write due to missing size checks<br /> <br /> The command_file_write() handler allocates a kernel buffer of exactly<br /> count bytes and copies user data into it, but does not validate the<br /> buffer against the dot command protocol before passing it to<br /> get_dot_command_size() and get_dot_command_timeout().<br /> <br /> Since both the allocation size (count) and the header fields (command_size,<br /> data_size) are independently user-controlled, an attacker can cause<br /> get_dot_command_size() to return a value exceeding the allocation,<br /> triggering OOB reads in get_dot_command_timeout() and an out-of-bounds<br /> memcpy_toio() that leaks kernel heap memory to the service processor.<br /> <br /> Fix with two guards: reject writes smaller than sizeof(struct<br /> dot_command_header) before allocation, then after copying user data<br /> reject commands where the buffer is smaller than the total size declared<br /> by the header (sizeof(header) + command_size + data_size). This ensures<br /> all subsequent header and payload field accesses stay within the buffer.