Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: ipc: fix use-after-free in ipc_msg_send_request<br /> <br /> ipc_msg_send_request() waits for a generic netlink reply using an<br /> ipc_msg_table_entry on the stack. The generic netlink handler<br /> (handle_generic_event()/handle_response()) fills entry-&gt;response under<br /> ipc_msg_table_lock, but ipc_msg_send_request() used to validate and free<br /> entry-&gt;response without holding the same lock.<br /> <br /> Under high concurrency this allows a race where handle_response() is<br /> copying data into entry-&gt;response while ipc_msg_send_request() has just<br /> freed it, leading to a slab-use-after-free reported by KASAN in<br /> handle_generic_event():<br /> <br /> BUG: KASAN: slab-use-after-free in handle_generic_event+0x3c4/0x5f0 [ksmbd]<br /> Write of size 12 at addr ffff888198ee6e20 by task pool/109349<br /> ...<br /> Freed by task:<br /> kvfree<br /> ipc_msg_send_request [ksmbd]<br /> ksmbd_rpc_open -&gt; ksmbd_session_rpc_open [ksmbd]<br /> <br /> Fix by:<br /> - Taking ipc_msg_table_lock in ipc_msg_send_request() while validating<br /> entry-&gt;response, freeing it when invalid, and removing the entry from<br /> ipc_msg_table.<br /> - Returning the final entry-&gt;response pointer to the caller only after<br /> the hash entry is removed under the lock.<br /> - Returning NULL in the error path, preserving the original API<br /> semantics.<br /> <br /> This makes all accesses to entry-&gt;response consistent with<br /> handle_response(), which already updates and fills the response buffer<br /> under ipc_msg_table_lock, and closes the race that allowed the UAF.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: refresh inline data size before write operations<br /> <br /> The cached ei-&gt;i_inline_size can become stale between the initial size<br /> check and when ext4_update_inline_data()/ext4_create_inline_data() use<br /> it. Although ext4_get_max_inline_size() reads the correct value at the<br /> time of the check, concurrent xattr operations can modify i_inline_size<br /> before ext4_write_lock_xattr() is acquired.<br /> <br /> This causes ext4_update_inline_data() and ext4_create_inline_data() to<br /> work with stale capacity values, leading to a BUG_ON() crash in<br /> ext4_write_inline_data():<br /> <br /> kernel BUG at fs/ext4/inline.c:1331!<br /> BUG_ON(pos + len &gt; EXT4_I(inode)-&gt;i_inline_size);<br /> <br /> The race window:<br /> 1. ext4_get_max_inline_size() reads i_inline_size = 60 (correct)<br /> 2. Size check passes for 50-byte write<br /> 3. [Another thread adds xattr, i_inline_size changes to 40]<br /> 4. ext4_write_lock_xattr() acquires lock<br /> 5. ext4_update_inline_data() uses stale i_inline_size = 60<br /> 6. Attempts to write 50 bytes but only 40 bytes actually available<br /> 7. BUG_ON() triggers<br /> <br /> Fix this by recalculating i_inline_size via ext4_find_inline_data_nolock()<br /> immediately after acquiring xattr_sem. This ensures ext4_update_inline_data()<br /> and ext4_create_inline_data() work with current values that are protected<br /> from concurrent modifications.<br /> <br /> This is similar to commit a54c4613dac1 ("ext4: fix race writing to an<br /> inline_data file while its xattrs are changing") which fixed i_inline_off<br /> staleness. This patch addresses the related i_inline_size staleness issue.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vmw_balloon: indicate success when effectively deflating during migration<br /> <br /> When migrating a balloon page, we first deflate the old page to then<br /> inflate the new page.<br /> <br /> However, if inflating the new page succeeded, we effectively deflated the<br /> old page, reducing the balloon size.<br /> <br /> In that case, the migration actually worked: similar to migrating+<br /> immediately deflating the new page. The old page will be freed back to<br /> the buddy.<br /> <br /> Right now, the core will leave the page be marked as isolated (as we<br /> returned an error). When later trying to putback that page, we will run<br /> into the WARN_ON_ONCE() in balloon_page_putback().<br /> <br /> That handling was changed in commit 3544c4faccb8 ("mm/balloon_compaction:<br /> stop using __ClearPageMovable()"); before that change, we would have<br /> tolerated that way of handling it.<br /> <br /> To fix it, let&amp;#39;s just return 0 in that case, making the core effectively<br /> just clear the "isolated" flag + freeing it back to the buddy as if the<br /> migration succeeded. Note that the new page will also get freed when the<br /> core puts the last reference.<br /> <br /> Note that this also makes it all be more consistent: we will no longer<br /> unisolate the page in the balloon driver while keeping it marked as being<br /> isolated in migration core.<br /> <br /> This was found by code inspection.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> most: usb: hdm_probe: Fix calling put_device() before device initialization<br /> <br /> The early error path in hdm_probe() can jump to err_free_mdev before<br /> &amp;mdev-&gt;dev has been initialized with device_initialize(). Calling<br /> put_device(&amp;mdev-&gt;dev) there triggers a device core WARN and ends up<br /> invoking kref_put(&amp;kobj-&gt;kref, kobject_release) on an uninitialized<br /> kobject.<br /> <br /> In this path the private struct was only kmalloc&amp;#39;ed and the intended<br /> release is effectively kfree(mdev) anyway, so free it directly instead<br /> of calling put_device() on an uninitialized device.<br /> <br /> This removes the WARNING and fixes the pre-initialization error path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hung_task: fix warnings caused by unaligned lock pointers<br /> <br /> The blocker tracking mechanism assumes that lock pointers are at least<br /> 4-byte aligned to use their lower bits for type encoding.<br /> <br /> However, as reported by Eero Tamminen, some architectures like m68k<br /> only guarantee 2-byte alignment of 32-bit values. This breaks the<br /> assumption and causes two related WARN_ON_ONCE checks to trigger.<br /> <br /> To fix this, the runtime checks are adjusted to silently ignore any lock<br /> that is not 4-byte aligned, effectively disabling the feature in such<br /> cases and avoiding the related warnings.<br /> <br /> Thanks to Geert Uytterhoeven for bisecting!

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: avoid infinite loops due to corrupted subpage compact indexes<br /> <br /> Robert reported an infinite loop observed by two crafted images.<br /> <br /> The root cause is that `clusterofs` can be larger than `lclustersize`<br /> for !NONHEAD `lclusters` in corrupted subpage compact indexes, e.g.:<br /> <br /> blocksize = lclustersize = 512 lcn = 6 clusterofs = 515<br /> <br /> Move the corresponding check for full compress indexes to<br /> `z_erofs_load_lcluster_from_disk()` to also cover subpage compact<br /> compress indexes.<br /> <br /> It also fixes the position of `m-&gt;type &gt;= Z_EROFS_LCLUSTER_TYPE_MAX`<br /> check, since it should be placed right after<br /> `z_erofs_load_{compact,full}_lcluster()`.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: Fix dma_buf object leak in fastrpc_map_lookup<br /> <br /> In fastrpc_map_lookup, dma_buf_get is called to obtain a reference to<br /> the dma_buf for comparison purposes. However, this reference is never<br /> released when the function returns, leading to a dma_buf memory leak.<br /> <br /> Fix this by adding dma_buf_put before returning from the function,<br /> ensuring that the temporarily acquired reference is properly released<br /> regardless of whether a matching map is found.<br /> <br /> Rule: add

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: don&amp;#39;t spin in add_stack_record when gfp flags don&amp;#39;t allow<br /> <br /> syzbot was able to find the following path:<br /> add_stack_record_to_list mm/page_owner.c:182 [inline]<br /> inc_stack_record_count mm/page_owner.c:214 [inline]<br /> __set_page_owner+0x2c3/0x4a0 mm/page_owner.c:333<br /> set_page_owner include/linux/page_owner.h:32 [inline]<br /> post_alloc_hook+0x240/0x2a0 mm/page_alloc.c:1851<br /> prep_new_page mm/page_alloc.c:1859 [inline]<br /> get_page_from_freelist+0x21e4/0x22c0 mm/page_alloc.c:3858<br /> alloc_pages_nolock_noprof+0x94/0x120 mm/page_alloc.c:7554<br /> <br /> Don&amp;#39;t spin in add_stack_record_to_list() when it is called<br /> from *_nolock() context.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: fix out-of-bounds read in OnBeacon ESR IE parsing<br /> <br /> The Extended Supported Rates (ESR) IE handling in OnBeacon accessed<br /> *(p + 1 + ielen) and *(p + 2 + ielen) without verifying that these<br /> offsets lie within the received frame buffer. A malformed beacon with<br /> an ESR IE positioned at the end of the buffer could cause an<br /> out-of-bounds read, potentially triggering a kernel panic.<br /> <br /> Add a boundary check to ensure that the ESR IE body and the subsequent<br /> bytes are within the limits of the frame before attempting to access<br /> them.<br /> <br /> This prevents OOB reads caused by malformed beacon frames.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: fix stack buffer overflow in OnAssocReq IE parsing<br /> <br /> The Supported Rates IE length from an incoming Association Request frame<br /> was used directly as the memcpy() length when copying into a fixed-size<br /> 16-byte stack buffer (supportRate). A malicious station can advertise an<br /> IE length larger than 16 bytes, causing a stack buffer overflow.<br /> <br /> Clamp ie_len to the buffer size before copying the Supported Rates IE,<br /> and correct the bounds check when merging Extended Supported Rates to<br /> prevent a second potential overflow.<br /> <br /> This prevents kernel stack corruption triggered by malformed association<br /> requests.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser<br /> <br /> The Information Element (IE) parser rtw_get_ie() trusted the length<br /> byte of each IE without validating that the IE body (len bytes after<br /> the 2-byte header) fits inside the remaining frame buffer. A malformed<br /> frame can advertise an IE length larger than the available data, causing<br /> the parser to increment its pointer beyond the buffer end. This results<br /> in out-of-bounds reads or, depending on the pattern, an infinite loop.<br /> <br /> Fix by validating that (offset + 2 + len) does not exceed the limit<br /> before accepting the IE or advancing to the next element.<br /> <br /> This prevents OOB reads and ensures the parser terminates safely on<br /> malformed frames.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binfmt_misc: restore write access before closing files opened by open_exec()<br /> <br /> bm_register_write() opens an executable file using open_exec(), which<br /> internally calls do_open_execat() and denies write access on the file to<br /> avoid modification while it is being executed.<br /> <br /> However, when an error occurs, bm_register_write() closes the file using<br /> filp_close() directly. This does not restore the write permission, which<br /> may cause subsequent write operations on the same file to fail.<br /> <br /> Fix this by calling exe_file_allow_write_access() before filp_close() to<br /> restore the write permission properly.