Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfsplus: don&amp;#39;t use BUG_ON() in hfsplus_create_attributes_file()<br /> <br /> When the volume header contains erroneous values that do not reflect<br /> the actual state of the filesystem, hfsplus_fill_super() assumes that<br /> the attributes file is not yet created, which later results in hitting<br /> BUG_ON() when hfsplus_create_attributes_file() is called. Replace this<br /> BUG_ON() with -EIO error with a message to suggest running fsck tool.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()<br /> <br /> The hfsplus_readdir() method is capable to crash by calling<br /> hfsplus_uni2asc():<br /> <br /> [ 667.121659][ T9805] ==================================================================<br /> [ 667.122651][ T9805] BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0x902/0xa10<br /> [ 667.123627][ T9805] Read of size 2 at addr ffff88802592f40c by task repro/9805<br /> [ 667.124578][ T9805]<br /> [ 667.124876][ T9805] CPU: 3 UID: 0 PID: 9805 Comm: repro Not tainted 6.16.0-rc3 #1 PREEMPT(full)<br /> [ 667.124886][ T9805] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 667.124890][ T9805] Call Trace:<br /> [ 667.124893][ T9805] <br /> [ 667.124896][ T9805] dump_stack_lvl+0x10e/0x1f0<br /> [ 667.124911][ T9805] print_report+0xd0/0x660<br /> [ 667.124920][ T9805] ? __virt_addr_valid+0x81/0x610<br /> [ 667.124928][ T9805] ? __phys_addr+0xe8/0x180<br /> [ 667.124934][ T9805] ? hfsplus_uni2asc+0x902/0xa10<br /> [ 667.124942][ T9805] kasan_report+0xc6/0x100<br /> [ 667.124950][ T9805] ? hfsplus_uni2asc+0x902/0xa10<br /> [ 667.124959][ T9805] hfsplus_uni2asc+0x902/0xa10<br /> [ 667.124966][ T9805] ? hfsplus_bnode_read+0x14b/0x360<br /> [ 667.124974][ T9805] hfsplus_readdir+0x845/0xfc0<br /> [ 667.124984][ T9805] ? __pfx_hfsplus_readdir+0x10/0x10<br /> [ 667.124994][ T9805] ? stack_trace_save+0x8e/0xc0<br /> [ 667.125008][ T9805] ? iterate_dir+0x18b/0xb20<br /> [ 667.125015][ T9805] ? trace_lock_acquire+0x85/0xd0<br /> [ 667.125022][ T9805] ? lock_acquire+0x30/0x80<br /> [ 667.125029][ T9805] ? iterate_dir+0x18b/0xb20<br /> [ 667.125037][ T9805] ? down_read_killable+0x1ed/0x4c0<br /> [ 667.125044][ T9805] ? putname+0x154/0x1a0<br /> [ 667.125051][ T9805] ? __pfx_down_read_killable+0x10/0x10<br /> [ 667.125058][ T9805] ? apparmor_file_permission+0x239/0x3e0<br /> [ 667.125069][ T9805] iterate_dir+0x296/0xb20<br /> [ 667.125076][ T9805] __x64_sys_getdents64+0x13c/0x2c0<br /> [ 667.125084][ T9805] ? __pfx___x64_sys_getdents64+0x10/0x10<br /> [ 667.125091][ T9805] ? __x64_sys_openat+0x141/0x200<br /> [ 667.125126][ T9805] ? __pfx_filldir64+0x10/0x10<br /> [ 667.125134][ T9805] ? do_user_addr_fault+0x7fe/0x12f0<br /> [ 667.125143][ T9805] do_syscall_64+0xc9/0x480<br /> [ 667.125151][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> [ 667.125158][ T9805] RIP: 0033:0x7fa8753b2fc9<br /> [ 667.125164][ T9805] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 48<br /> [ 667.125172][ T9805] RSP: 002b:00007ffe96f8e0f8 EFLAGS: 00000217 ORIG_RAX: 00000000000000d9<br /> [ 667.125181][ T9805] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa8753b2fc9<br /> [ 667.125185][ T9805] RDX: 0000000000000400 RSI: 00002000000063c0 RDI: 0000000000000004<br /> [ 667.125190][ T9805] RBP: 00007ffe96f8e110 R08: 00007ffe96f8e110 R09: 00007ffe96f8e110<br /> [ 667.125195][ T9805] R10: 0000000000000000 R11: 0000000000000217 R12: 0000556b1e3b4260<br /> [ 667.125199][ T9805] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000<br /> [ 667.125207][ T9805] <br /> [ 667.125210][ T9805]<br /> [ 667.145632][ T9805] Allocated by task 9805:<br /> [ 667.145991][ T9805] kasan_save_stack+0x20/0x40<br /> [ 667.146352][ T9805] kasan_save_track+0x14/0x30<br /> [ 667.146717][ T9805] __kasan_kmalloc+0xaa/0xb0<br /> [ 667.147065][ T9805] __kmalloc_noprof+0x205/0x550<br /> [ 667.147448][ T9805] hfsplus_find_init+0x95/0x1f0<br /> [ 667.147813][ T9805] hfsplus_readdir+0x220/0xfc0<br /> [ 667.148174][ T9805] iterate_dir+0x296/0xb20<br /> [ 667.148549][ T9805] __x64_sys_getdents64+0x13c/0x2c0<br /> [ 667.148937][ T9805] do_syscall_64+0xc9/0x480<br /> [ 667.149291][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> [ 667.149809][ T9805]<br /> [ 667.150030][ T9805] The buggy address belongs to the object at ffff88802592f000<br /> [ 667.150030][ T9805] which belongs to the cache kmalloc-2k of size 2048<br /> [ 667.151282][ T9805] The buggy address is located 0 bytes to the right of<br /> [ 667.151282][ T9805] allocated 1036-byte region [ffff88802592f000, ffff88802592f40c)<br /> [ 667.1<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfs: fix slab-out-of-bounds in hfs_bnode_read()<br /> <br /> This patch introduces is_bnode_offset_valid() method that checks<br /> the requested offset value. Also, it introduces<br /> check_and_correct_requested_length() method that checks and<br /> correct the requested length (if it is necessary). These methods<br /> are used in hfs_bnode_read(), hfs_bnode_write(), hfs_bnode_clear(),<br /> hfs_bnode_copy(), and hfs_bnode_move() with the goal to prevent<br /> the access out of allocated memory and triggering the crash.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Add sanity check for file name<br /> <br /> The length of the file name should be smaller than the directory entry size.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/pm: fix null pointer access<br /> <br /> Writing a string without delimiters (&amp;#39; &amp;#39;, &amp;#39;\n&amp;#39;, &amp;#39;\0&amp;#39;) to the under<br /> gpu_od/fan_ctrl sysfs or pp_power_profile_mode for the CUSTOM profile<br /> will result in a null pointer dereference.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Make dma-fences compliant with the safe access rules<br /> <br /> Xe can free some of the data pointed to by the dma-fences it exports. Most<br /> notably the timeline name can get freed if userspace closes the associated<br /> submit queue. At the same time the fence could have been exported to a<br /> third party (for example a sync_fence fd) which will then cause an use-<br /> after-free on subsequent access.<br /> <br /> To make this safe we need to make the driver compliant with the newly<br /> documented dma-fence rules. Driver has to ensure a RCU grace period<br /> between signalling a fence and freeing any data pointed to by said fence.<br /> <br /> For the timeline name we simply make the queue be freed via kfree_rcu and<br /> for the shared lock associated with multiple queues we add a RCU grace<br /> period before freeing the per GT structure holding the lock.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rcu/nocb: Fix possible invalid rdp&amp;#39;s-&gt;nocb_cb_kthread pointer access<br /> <br /> In the preparation stage of CPU online, if the corresponding<br /> the rdp&amp;#39;s-&gt;nocb_cb_kthread does not exist, will be created,<br /> there is a situation where the rdp&amp;#39;s rcuop kthreads creation fails,<br /> and then de-offload this CPU&amp;#39;s rdp, does not assign this CPU&amp;#39;s<br /> rdp-&gt;nocb_cb_kthread pointer, but this rdp&amp;#39;s-&gt;nocb_gp_rdp and<br /> rdp&amp;#39;s-&gt;rdp_gp-&gt;nocb_gp_kthread is still valid.<br /> <br /> This will cause the subsequent re-offload operation of this offline<br /> CPU, which will pass the conditional check and the kthread_unpark()<br /> will access invalid rdp&amp;#39;s-&gt;nocb_cb_kthread pointer.<br /> <br /> This commit therefore use rdp&amp;#39;s-&gt;nocb_gp_kthread instead of<br /> rdp_gp&amp;#39;s-&gt;nocb_gp_kthread for safety check.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> loop: Avoid updating block size under exclusive owner<br /> <br /> Syzbot came up with a reproducer where a loop device block size is<br /> changed underneath a mounted filesystem. This causes a mismatch between<br /> the block device block size and the block size stored in the superblock<br /> causing confusion in various places such as fs/buffer.c. The particular<br /> issue triggered by syzbot was a warning in __getblk_slow() due to<br /> requested buffer size not matching block device block size.<br /> <br /> Fix the problem by getting exclusive hold of the loop device to change<br /> its block size. This fails if somebody (such as filesystem) has already<br /> an exclusive ownership of the block device and thus prevents modifying<br /> the loop device under some exclusive owner which doesn&amp;#39;t expect it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: core: Check for rtd == NULL in snd_soc_remove_pcm_runtime()<br /> <br /> snd_soc_remove_pcm_runtime() might be called with rtd == NULL which will<br /> leads to null pointer dereference.<br /> This was reproduced with topology loading and marking a link as ignore<br /> due to missing hardware component on the system.<br /> On module removal the soc_tplg_remove_link() would call<br /> snd_soc_remove_pcm_runtime() with rtd == NULL since the link was ignored,<br /> no runtime was created.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drbd: add missing kref_get in handle_write_conflicts<br /> <br /> With `two-primaries` enabled, DRBD tries to detect "concurrent" writes<br /> and handle write conflicts, so that even if you write to the same sector<br /> simultaneously on both nodes, they end up with the identical data once<br /> the writes are completed.<br /> <br /> In handling "superseeded" writes, we forgot a kref_get,<br /> resulting in a premature drbd_destroy_device and use after free,<br /> and further to kernel crashes with symptoms.<br /> <br /> Relevance: No one should use DRBD as a random data generator, and apparently<br /> all users of "two-primaries" handle concurrent writes correctly on layer up.<br /> That is cluster file systems use some distributed lock manager,<br /> and live migration in virtualization environments stops writes on one node<br /> before starting writes on the other node.<br /> <br /> Which means that other than for "test cases",<br /> this code path is never taken in real life.<br /> <br /> FYI, in DRBD 9, things are handled differently nowadays. We still detect<br /> "write conflicts", but no longer try to be smart about them.<br /> We decided to disconnect hard instead: upper layers must not submit concurrent<br /> writes. If they do, that&amp;#39;s their fault.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: bfa: Double-free fix<br /> <br /> When the bfad_im_probe() function fails during initialization, the memory<br /> pointed to by bfad-&gt;im is freed without setting bfad-&gt;im to NULL.<br /> <br /> Subsequently, during driver uninstallation, when the state machine enters<br /> the bfad_sm_stopping state and calls the bfad_im_probe_undo() function,<br /> it attempts to free the memory pointed to by bfad-&gt;im again, thereby<br /> triggering a double-free vulnerability.<br /> <br /> Set bfad-&gt;im to NULL if probing fails.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: do not BUG when INLINE_DATA_FL lacks system.data xattr<br /> <br /> A syzbot fuzzed image triggered a BUG_ON in ext4_update_inline_data()<br /> when an inode had the INLINE_DATA_FL flag set but was missing the<br /> system.data extended attribute.<br /> <br /> Since this can happen due to a maiciouly fuzzed file system, we<br /> shouldn&amp;#39;t BUG, but rather, report it as a corrupted file system.<br /> <br /> Add similar replacements of BUG_ON with EXT4_ERROR_INODE() ii<br /> ext4_create_inline_data() and ext4_inline_data_truncate().