Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/buffer: add alert in try_to_free_buffers() for folios without buffers<br /> <br /> try_to_free_buffers() can be called on folios with no buffers attached<br /> when filemap_release_folio() is invoked on a folio belonging to a mapping<br /> with AS_RELEASE_ALWAYS set but no release_folio operation defined.<br /> <br /> In such cases, folio_needs_release() returns true because of the<br /> AS_RELEASE_ALWAYS flag, but the folio has no private buffer data. This<br /> causes try_to_free_buffers() to call drop_buffers() on a folio with no<br /> buffers, leading to a null pointer dereference.<br /> <br /> Adding a check in try_to_free_buffers() to return early if the folio has no<br /> buffers attached, with WARN_ON_ONCE() to alert about the misconfiguration.<br /> This provides defensive hardening.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix NULL pointer issue buffer funcs<br /> <br /> If SDMA block not enabled, buffer_funcs will not initialize,<br /> fix the null pointer issue if buffer_funcs not initialized.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/ras: Move ras data alloc before bad page check<br /> <br /> In the rare event if eeprom has only invalid address entries,<br /> allocation is skipped, this causes following NULL pointer issue<br /> [ 547.103445] BUG: kernel NULL pointer dereference, address: 0000000000000010<br /> [ 547.118897] #PF: supervisor read access in kernel mode<br /> [ 547.130292] #PF: error_code(0x0000) - not-present page<br /> [ 547.141689] PGD 124757067 P4D 0<br /> [ 547.148842] Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 547.158504] CPU: 49 PID: 8167 Comm: cat Tainted: G OE 6.8.0-38-generic #38-Ubuntu<br /> [ 547.177998] Hardware name: Supermicro AS -8126GS-TNMR/H14DSG-OD, BIOS 1.7 09/12/2025<br /> [ 547.195178] RIP: 0010:amdgpu_ras_sysfs_badpages_read+0x2f2/0x5d0 [amdgpu]<br /> [ 547.210375] Code: e8 63 78 82 c0 45 31 d2 45 3b 75 08 48 8b 45 a0 73 44 44 89 f1 48 8b 7d 88 48 89 ca 48 c1 e2 05 48 29 ca 49 8b 4d 00 48 01 d1 83 79 10 00 74 17 49 63 f2 48 8b 49 08 41 83 c2 01 48 8d 34 76<br /> [ 547.252045] RSP: 0018:ffa0000067287ac0 EFLAGS: 00010246<br /> [ 547.263636] RAX: ff11000167c28130 RBX: ff11000127600000 RCX: 0000000000000000<br /> [ 547.279467] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ff11000125b1c800<br /> [ 547.295298] RBP: ffa0000067287b50 R08: 0000000000000000 R09: 0000000000000000<br /> [ 547.311129] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000<br /> [ 547.326959] R13: ff11000217b1de00 R14: 0000000000000000 R15: 0000000000000092<br /> [ 547.342790] FS: 0000746e59d14740(0000) GS:ff11017dfda80000(0000) knlGS:0000000000000000<br /> [ 547.360744] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 547.373489] CR2: 0000000000000010 CR3: 000000019585e001 CR4: 0000000000f71ef0<br /> [ 547.389321] PKRU: 55555554<br /> [ 547.395316] Call Trace:<br /> [ 547.400737] <br /> [ 547.405386] ? show_regs+0x6d/0x80<br /> [ 547.412929] ? __die+0x24/0x80<br /> [ 547.419697] ? page_fault_oops+0x99/0x1b0<br /> [ 547.428588] ? do_user_addr_fault+0x2ee/0x6b0<br /> [ 547.438249] ? exc_page_fault+0x83/0x1b0<br /> [ 547.446949] ? asm_exc_page_fault+0x27/0x30<br /> [ 547.456225] ? amdgpu_ras_sysfs_badpages_read+0x2f2/0x5d0 [amdgpu]<br /> [ 547.470040] ? mas_wr_modify+0xcd/0x140<br /> [ 547.478548] sysfs_kf_bin_read+0x63/0xb0<br /> [ 547.487248] kernfs_file_read_iter+0xa1/0x190<br /> [ 547.496909] kernfs_fop_read_iter+0x25/0x40<br /> [ 547.506182] vfs_read+0x255/0x390<br /> <br /> This also result in space left assigned to negative values.<br /> Moving data alloc call before bad page check resolves both the issue.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: nlink overflow in jfs_rename<br /> <br /> If nlink is maximal for a directory (-1) and inside that directory you<br /> perform a rename for some child directory (not moving from the parent),<br /> then the nlink of the first directory is first incremented and later<br /> decremented. Normally this is fine, but when nlink = -1 this causes a<br /> wrap around to 0, and then drop_nlink issues a warning.<br /> <br /> After applying the patch syzbot no longer issues any warnings. I also<br /> ran some basic fs tests to look for any regressions.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: bcm_vk: Fix possible null-pointer dereferences in bcm_vk_read()<br /> <br /> In the function bcm_vk_read(), the pointer entry is checked, indicating<br /> that it can be NULL. If entry is NULL and rc is set to -EMSGSIZE, the<br /> following code may cause null-pointer dereferences:<br /> <br /> struct vk_msg_blk tmp_msg = entry-&gt;to_h_msg[0];<br /> set_msg_id(&amp;tmp_msg, entry-&gt;usr_msg_id);<br /> tmp_msg.size = entry-&gt;to_h_blks - 1;<br /> <br /> To prevent these possible null-pointer dereferences, copy to_h_msg,<br /> usr_msg_id, and to_h_blks from iter into temporary variables, and return<br /> these temporary variables to the application instead of accessing them<br /> through a potentially NULL entry.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: ti_fpc202: fix a potential memory leak in probe function<br /> <br /> Use for_each_child_of_node_scoped() to simplify the code and ensure the<br /> device node reference is automatically released when the loop scope<br /> ends.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: handle attr_set_size() errors when truncating files<br /> <br /> If attr_set_size() fails while truncating down, the error is silently<br /> ignored and the inode may be left in an inconsistent state.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SOF: ipc4-topology: Correct the allocation size for bytes controls<br /> <br /> The size of the data behind of scontrol-&gt;ipc_control_data for bytes<br /> controls is:<br /> [1] sizeof(struct sof_ipc4_control_data) + // kernel only struct<br /> [2] sizeof(struct sof_abi_hdr)) + payload<br /> <br /> The max_size specifies the size of [2] and it is coming from topology.<br /> <br /> Change the function to take this into account and allocate adequate amount<br /> of memory behind scontrol-&gt;ipc_control_data.<br /> <br /> With the change we will allocate [1] amount more memory to be able to hold<br /> the full size of data.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qrtr: Drop the MHI auto_queue feature for IPCR DL channels<br /> <br /> MHI stack offers the &amp;#39;auto_queue&amp;#39; feature, which allows the MHI stack to<br /> auto queue the buffers for the RX path (DL channel). Though this feature<br /> simplifies the client driver design, it introduces race between the client<br /> drivers and the MHI stack. For instance, with auto_queue, the &amp;#39;dl_callback&amp;#39;<br /> for the DL channel may get called before the client driver is fully probed.<br /> This means, by the time the dl_callback gets called, the client driver&amp;#39;s<br /> structures might not be initialized, leading to NULL ptr dereference.<br /> <br /> Currently, the drivers have to workaround this issue by initializing the<br /> internal structures before calling mhi_prepare_for_transfer_autoqueue().<br /> But even so, there is a chance that the client driver&amp;#39;s internal code path<br /> may call the MHI queue APIs before mhi_prepare_for_transfer_autoqueue() is<br /> called, leading to similar NULL ptr dereference. This issue has been<br /> reported on the Qcom X1E80100 CRD machines affecting boot.<br /> <br /> So to properly fix all these races, drop the MHI &amp;#39;auto_queue&amp;#39; feature<br /> altogether and let the client driver (QRTR) manage the RX buffers manually.<br /> In the QRTR driver, queue the RX buffers based on the ring length during<br /> probe and recycle the buffers in &amp;#39;dl_callback&amp;#39; once they are consumed. This<br /> also warrants removing the setting of &amp;#39;auto_queue&amp;#39; flag from controller<br /> drivers.<br /> <br /> Currently, this &amp;#39;auto_queue&amp;#39; feature is only enabled for IPCR DL channel.<br /> So only the QRTR client driver requires the modification.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rpmsg: core: fix race in driver_override_show() and use core helper<br /> <br /> The driver_override_show function reads the driver_override string<br /> without holding the device_lock. However, the store function modifies<br /> and frees the string while holding the device_lock. This creates a race<br /> condition where the string can be freed by the store function while<br /> being read by the show function, leading to a use-after-free.<br /> <br /> To fix this, replace the rpmsg_string_attr macro with explicit show and<br /> store functions. The new driver_override_store uses the standard<br /> driver_set_override helper. Since the introduction of<br /> driver_set_override, the comments in include/linux/rpmsg.h have stated<br /> that this helper must be used to set or clear driver_override, but the<br /> implementation was not updated until now.<br /> <br /> Because driver_set_override modifies and frees the string while holding<br /> the device_lock, the new driver_override_show now correctly holds the<br /> device_lock during the read operation to prevent the race.<br /> <br /> Additionally, since rpmsg_string_attr has only ever been used for<br /> driver_override, removing the macro simplifies the code.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfsplus: ensure sb-&gt;s_fs_info is always cleaned up<br /> <br /> When hfsplus was converted to the new mount api a bug was introduced by<br /> changing the allocation pattern of sb-&gt;s_fs_info. If setup_bdev_super()<br /> fails after a new superblock has been allocated by sget_fc(), but before<br /> hfsplus_fill_super() takes ownership of the filesystem-specific s_fs_info<br /> data it was leaked.<br /> <br /> Fix this by freeing sb-&gt;s_fs_info in hfsplus_kill_super().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw88: Use devm_kmemdup() in rtw_set_supported_band()<br /> <br /> Simplify the code by using device managed memory allocations.<br /> <br /> This also fixes a memory leak in rtw_register_hw(). The supported bands<br /> were not freed in the error path.<br /> <br /> Copied from commit 145df52a8671 ("wifi: rtw89: Convert<br /> rtw89_core_set_supported_band to use devm_*").