Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix error handling in rxgk_extract_token()<br /> <br /> Fix a missing bit of error handling in rxgk_extract_token(): in the event<br /> that rxgk_decrypt_skb() returns -ENOMEM, it should just return that rather<br /> than continuing on (for anything else, it generates an abort).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: endpoint: pci-epf-ntb: Remove duplicate resource teardown<br /> <br /> epf_ntb_epc_destroy() duplicates the teardown that the caller is<br /> supposed to do later. This leads to an oops when .allow_link fails or<br /> when .drop_link is performed. Remove the helper.<br /> <br /> Also drop pci_epc_put(). EPC device refcounting is tied to configfs EPC<br /> group lifetime, and pci_epc_put() in the .drop_link path is sufficient.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/core: fix damos_walk() vs kdamond_fn() exit race<br /> <br /> When kdamond_fn() main loop is finished, the function cancels remaining<br /> damos_walk() request and unset the damon_ctx-&gt;kdamond so that API callers<br /> and API functions themselves can show the context is terminated. <br /> damos_walk() adds the caller&amp;#39;s request to the queue first. After that, it<br /> shows if the kdamond of the damon_ctx is still running (damon_ctx-&gt;kdamond<br /> is set). Only if the kdamond is running, damos_walk() starts waiting for<br /> the kdamond&amp;#39;s handling of the newly added request.<br /> <br /> The damos_walk() requests registration and damon_ctx-&gt;kdamond unset are<br /> protected by different mutexes, though. Hence, damos_walk() could race<br /> with damon_ctx-&gt;kdamond unset, and result in deadlocks.<br /> <br /> For example, let&amp;#39;s suppose kdamond successfully finished the damow_walk()<br /> request cancelling. Right after that, damos_walk() is called for the<br /> context. It registers the new request, and shows the context is still<br /> running, because damon_ctx-&gt;kdamond unset is not yet done. Hence the<br /> damos_walk() caller starts waiting for the handling of the request. <br /> However, the kdamond is already on the termination steps, so it never<br /> handles the new request. As a result, the damos_walk() caller thread<br /> infinitely waits.<br /> <br /> Fix this by introducing another damon_ctx field, namely<br /> walk_control_obsolete. It is protected by the<br /> damon_ctx-&gt;walk_control_lock, which protects damos_walk() request<br /> registration. Initialize (unset) it in kdamond_fn() before letting<br /> damon_start() returns and set it just before the cancelling of the<br /> remaining damos_walk() request is executed. damos_walk() reads the<br /> obsolete field under the lock and avoids adding a new request.<br /> <br /> After this change, only requests that are guaranteed to be handled or<br /> cancelled are registered. Hence the after-registration DAMON context<br /> termination check is no longer needed. Remove it together.<br /> <br /> The issue is found by sashiko [1].

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (powerz) Avoid cacheline sharing for DMA buffer<br /> <br /> Depending on the architecture the transfer buffer may share a cacheline<br /> with the following mutex. As the buffer may be used for DMA, that is<br /> problematic.<br /> <br /> Use the high-level DMA helpers to make sure that cacheline sharing can<br /> not happen.<br /> <br /> Also drop the comment, as the helpers are documentation enough.<br /> <br /> https://sashiko.dev/#/message/20260408175814.934BFC19421%40smtp.kernel.org

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: caiaq: Handle probe errors properly<br /> <br /> The probe procedure of setup_card() in caiaq driver doesn&amp;#39;t treat the<br /> error cases gracefully, e.g. the error from snd_card_register() calls<br /> snd_card_free() but continues. This would lead to a UAF for the<br /> further calls like snd_usb_caiaq_control_init(), as Berk suggested in<br /> another patch in the link below.<br /> <br /> However, the problem is not only that; in general, this function drops<br /> the all error handlings (as it&amp;#39;s a void function) although its caller<br /> can propagate an error to snd_probe(), which eventually calls<br /> snd_card_free() as a proper error path. That said, we should treat<br /> each error case in setup_card(), and just return the error code<br /> promptly, which is then handled later as a fatal error in snd_probe().<br /> <br /> This patch achieves it by changing the setup_card() to return an error<br /> code. Also, the superfluous snd_card_free() call is removed, too.<br /> <br /> Note that card-&gt;private_free can be set still safely at returning an<br /> error. All called functions in card_free() have checks of the<br /> unassigned resources or NULL checks.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qrtr: ns: Limit the total number of nodes<br /> <br /> Currently, the nameserver doesn&amp;#39;t limit the number of nodes it handles.<br /> This can be an attack vector if a malicious client starts registering<br /> random nodes, leading to memory exhaustion.<br /> <br /> Hence, limit the maximum number of nodes to 64. Note that, limit of 64 is<br /> chosen based on the current platform requirements. If requirement changes<br /> in the future, this limit can be increased.

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