Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: fix memory leak in __blkdev_issue_zero_pages<br /> <br /> Move the fatal signal check before bio_alloc() to prevent a memory<br /> leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending.<br /> <br /> Previously, the bio was allocated before checking for a fatal signal.<br /> If a signal was pending, the code would break out of the loop without<br /> freeing or chaining the just-allocated bio, causing a memory leak.<br /> <br /> This matches the pattern already used in __blkdev_issue_write_zeroes()<br /> where the signal check precedes the allocation.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exfat: fix divide-by-zero in exfat_allocate_bitmap<br /> <br /> The variable max_ra_count can be 0 in exfat_allocate_bitmap(),<br /> which causes a divide-by-zero error in the subsequent modulo operation<br /> (i % max_ra_count), leading to a system crash.<br /> When max_ra_count is 0, it means that readahead is not used. This patch<br /> load the bitmap without readahead.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: ch341: fix out-of-bounds memory access in ch341_transfer_one<br /> <br /> Discovered by Atuin - Automated Vulnerability Discovery Engine.<br /> <br /> The &amp;#39;len&amp;#39; variable is calculated as &amp;#39;min(32, trans-&gt;len + 1)&amp;#39;,<br /> which includes the 1-byte command header.<br /> <br /> When copying data from &amp;#39;trans-&gt;tx_buf&amp;#39; to &amp;#39;ch341-&gt;tx_buf + 1&amp;#39;, using &amp;#39;len&amp;#39;<br /> as the length is incorrect because:<br /> <br /> 1. It causes an out-of-bounds read from &amp;#39;trans-&gt;tx_buf&amp;#39; (which has size<br /> &amp;#39;trans-&gt;len&amp;#39;, i.e., &amp;#39;len - 1&amp;#39; in this context).<br /> 2. It can cause an out-of-bounds write to &amp;#39;ch341-&gt;tx_buf&amp;#39; if &amp;#39;len&amp;#39; is<br /> CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341-&gt;tx_buf + 1<br /> overflows the buffer.<br /> <br /> Fix this by copying &amp;#39;len - 1&amp;#39; bytes.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: vxlan: prevent NULL deref in vxlan_xmit_one<br /> <br /> Neither sock4 nor sock6 pointers are guaranteed to be non-NULL in<br /> vxlan_xmit_one, e.g. if the iface is brought down. This can lead to the<br /> following NULL dereference:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000010<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> RIP: 0010:vxlan_xmit_one+0xbb3/0x1580<br /> Call Trace:<br /> vxlan_xmit+0x429/0x610<br /> dev_hard_start_xmit+0x55/0xa0<br /> __dev_queue_xmit+0x6d0/0x7f0<br /> ip_finish_output2+0x24b/0x590<br /> ip_output+0x63/0x110<br /> <br /> Mentioned commits changed the code path in vxlan_xmit_one and as a side<br /> effect the sock4/6 pointer validity checks in vxlan(6)_get_route were<br /> lost. Fix this by adding back checks.<br /> <br /> Since both commits being fixed were released in the same version (v6.7)<br /> and are strongly related, bundle the fixes in a single commit.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix exclusive map memory leak<br /> <br /> When excl_prog_hash is 0 and excl_prog_hash_size is non-zero, the map also<br /> needs to be freed. Otherwise, the map memory will not be reclaimed, just<br /> like the memory leak problem reported by syzbot [1].<br /> <br /> syzbot reported:<br /> BUG: memory leak<br /> backtrace (crc 7b9fb9b4):<br /> map_create+0x322/0x11e0 kernel/bpf/syscall.c:1512<br /> __sys_bpf+0x3556/0x3610 kernel/bpf/syscall.c:6131

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gfs2: Prevent recursive memory reclaim<br /> <br /> Function new_inode() returns a new inode with inode-&gt;i_mapping-&gt;gfp_mask<br /> set to GFP_HIGHUSER_MOVABLE. This value includes the __GFP_FS flag, so<br /> allocations in that address space can recurse into filesystem memory<br /> reclaim. We don&amp;#39;t want that to happen because it can consume a<br /> significant amount of stack memory.<br /> <br /> Worse than that is that it can also deadlock: for example, in several<br /> places, gfs2_unstuff_dinode() is called inside filesystem transactions.<br /> This calls filemap_grab_folio(), which can allocate a new folio, which<br /> can trigger memory reclaim. If memory reclaim recurses into the<br /> filesystem and starts another transaction, a deadlock will ensue.<br /> <br /> To fix these kinds of problems, prevent memory reclaim from recursing<br /> into filesystem code by making sure that the gfp_mask of inode address<br /> spaces doesn&amp;#39;t include __GFP_FS.<br /> <br /> The "meta" and resource group address spaces were already using GFP_NOFS<br /> as their gfp_mask (which doesn&amp;#39;t include __GFP_FS). The default value<br /> of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though. To<br /> avoid being overly limiting, use the default value and only knock off<br /> the __GFP_FS flag. I&amp;#39;m not sure if this will actually make a<br /> difference, but it also shouldn&amp;#39;t hurt.<br /> <br /> This patch is loosely based on commit ad22c7a043c2 ("xfs: prevent stack<br /> overflows from page cache allocation").<br /> <br /> Fixes xfstest generic/273.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP events<br /> <br /> The DSP event handling code in hwdep_read() could write more bytes to<br /> the user buffer than requested, when a user provides a buffer smaller<br /> than the event header size (8 bytes).<br /> <br /> Fix by using min_t() to clamp the copy size, This ensures we never copy<br /> more than the user requested.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalid<br /> <br /> Fixes a crash when layout is null during this call stack:<br /> <br /> write_inode<br /> -&gt; nfs4_write_inode<br /> -&gt; pnfs_layoutcommit_inode<br /> <br /> pnfs_set_layoutcommit relies on the lseg refcount to keep the layout<br /> around. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attempt<br /> to reference a null layout.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex<br /> <br /> regulator_supply_alias_list was accessed without any locking in<br /> regulator_supply_alias(), regulator_register_supply_alias(), and<br /> regulator_unregister_supply_alias(). Concurrent registration,<br /> unregistration and lookups can race, leading to:<br /> <br /> 1 use-after-free if an alias entry is removed while being read,<br /> 2 duplicate entries when two threads register the same alias,<br /> 3 inconsistent alias mappings observed by consumers.<br /> <br /> Protect all traversals, insertions and deletions on<br /> regulator_supply_alias_list with the existing regulator_list_mutex.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exfat: fix refcount leak in exfat_find<br /> <br /> Fix refcount leaks in `exfat_find` related to `exfat_get_dentry_set`.<br /> <br /> Function `exfat_get_dentry_set` would increase the reference counter of<br /> `es-&gt;bh` on success. Therefore, `exfat_put_dentry_set` must be called<br /> after `exfat_get_dentry_set` to ensure refcount consistency. This patch<br /> relocate two checks to avoid possible leaks.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: fix memory leak when removing provided buffers<br /> <br /> When removing provided buffers, io_buffer structs are not being disposed<br /> of, leading to a memory leak. They can&amp;#39;t be freed individually, because<br /> they are allocated in page-sized groups. They need to be added to some<br /> free list instead, such as io_buffers_cache. All callers already hold<br /> the lock protecting it, apart from when destroying buffers, so had to<br /> extend the lock there.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/64s: Fix VAS mm use after free<br /> <br /> The refcount on mm is dropped before the coprocessor is detached.