Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: also call xfrm_state_delete_tunnel at destroy time for states that were never added<br /> <br /> In commit b441cf3f8c4b ("xfrm: delete x-&gt;tunnel as we delete x"), I<br /> missed the case where state creation fails between full<br /> initialization (-&gt;init_state has been called) and being inserted on<br /> the lists.<br /> <br /> In this situation, -&gt;init_state has been called, so for IPcomp<br /> tunnels, the fallback tunnel has been created and added onto the<br /> lists, but the user state never gets added, because we fail before<br /> that. The user state doesn&amp;#39;t go through __xfrm_state_delete, so we<br /> don&amp;#39;t call xfrm_state_delete_tunnel for those states, and we end up<br /> leaking the FB tunnel.<br /> <br /> There are several codepaths affected by this: the add/update paths, in<br /> both net/key and xfrm, and the migrate code (xfrm_migrate,<br /> xfrm_state_migrate). A "proper" rollback of the init_state work would<br /> probably be doable in the add/update code, but for migrate it gets<br /> more complicated as multiple states may be involved.<br /> <br /> At some point, the new (not-inserted) state will be destroyed, so call<br /> xfrm_state_delete_tunnel during xfrm_state_gc_destroy. Most states<br /> will have their fallback tunnel cleaned up during __xfrm_state_delete,<br /> which solves the issue that b441cf3f8c4b (and other patches before it)<br /> aimed at. All states (including FB tunnels) will be removed from the<br /> lists once xfrm_state_fini has called flush_work(&amp;xfrm_state_gc_work).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: Fix pgtable prealloc error path<br /> <br /> The following splat was reported:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010<br /> Mem abort info:<br /> ESR = 0x0000000096000004<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x04: level 0 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000<br /> [0000000000000010] pgd=0000000000000000, p4d=0000000000000000<br /> Internal error: Oops: 0000000096000004 [#1] SMP<br /> CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S 6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT<br /> Tainted: [S]=CPU_OUT_OF_SPEC<br /> Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT)<br /> pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)<br /> pc : build_detached_freelist+0x28/0x224<br /> lr : kmem_cache_free_bulk.part.0+0x38/0x244<br /> sp : ffff000a508c7a20<br /> x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350<br /> x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000<br /> x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000<br /> x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8<br /> x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640<br /> x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30<br /> x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940<br /> x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000<br /> x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8<br /> x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00<br /> Call trace:<br /> build_detached_freelist+0x28/0x224 (P)<br /> kmem_cache_free_bulk.part.0+0x38/0x244<br /> kmem_cache_free_bulk+0x10/0x1c<br /> msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0<br /> msm_vma_job_free+0x30/0x240<br /> msm_ioctl_vm_bind+0x1d0/0x9a0<br /> drm_ioctl_kernel+0x84/0x104<br /> drm_ioctl+0x358/0x4d4<br /> __arm64_sys_ioctl+0x8c/0xe0<br /> invoke_syscall+0x44/0x100<br /> el0_svc_common.constprop.0+0x3c/0xe0<br /> do_el0_svc+0x18/0x20<br /> el0_svc+0x30/0x100<br /> el0t_64_sync_handler+0x104/0x130<br /> el0t_64_sync+0x170/0x174<br /> Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6)<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Since msm_vma_job_free() is called directly from the ioctl, this looks<br /> like an error path cleanup issue. Which I think results from<br /> prealloc_cleanup() called without a preceding successful<br /> prealloc_allocate() call. So handle that case better.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/678677/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: cdev: make sure the cdev fd is still active before emitting events<br /> <br /> With the final call to fput() on a file descriptor, the release action<br /> may be deferred and scheduled on a work queue. The reference count of<br /> that descriptor is still zero and it must not be used. It&amp;#39;s possible<br /> that a GPIO change, we want to notify the user-space about, happens<br /> AFTER the reference count on the file descriptor associated with the<br /> character device went down to zero but BEFORE the .release() callback<br /> was called from the workqueue and so BEFORE we unregistered from the<br /> notifier.<br /> <br /> Using the regular get_file() routine in this situation triggers the<br /> following warning:<br /> <br /> struct file::f_count incremented from zero; use-after-free condition present!<br /> <br /> So use the get_file_active() variant that will return NULL on file<br /> descriptors that have been or are being released.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Clean up only new IRQ glue on request_irq() failure<br /> <br /> The mlx5_irq_alloc() function can inadvertently free the entire rmap<br /> and end up in a crash[1] when the other threads tries to access this,<br /> when request_irq() fails due to exhausted IRQ vectors. This commit<br /> modifies the cleanup to remove only the specific IRQ mapping that was<br /> just added.<br /> <br /> This prevents removal of other valid mappings and ensures precise<br /> cleanup of the failed IRQ allocation&amp;#39;s associated glue object.<br /> <br /> Note: This error is observed when both fwctl and rds configs are enabled.<br /> <br /> [1]<br /> mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1<br /> mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to<br /> request irq. err = -28<br /> infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while<br /> trying to test write-combining support<br /> mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1<br /> mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1<br /> mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to<br /> request irq. err = -28<br /> infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while<br /> trying to test write-combining support<br /> mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1<br /> mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to<br /> request irq. err = -28<br /> mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to<br /> request irq. err = -28<br /> general protection fault, probably for non-canonical address<br /> 0xe277a58fde16f291: 0000 [#1] SMP NOPTI<br /> <br /> RIP: 0010:free_irq_cpu_rmap+0x23/0x7d<br /> Call Trace:<br /> <br /> ? show_trace_log_lvl+0x1d6/0x2f9<br /> ? show_trace_log_lvl+0x1d6/0x2f9<br /> ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core]<br /> ? __die_body.cold+0x8/0xa<br /> ? die_addr+0x39/0x53<br /> ? exc_general_protection+0x1c4/0x3e9<br /> ? dev_vprintk_emit+0x5f/0x90<br /> ? asm_exc_general_protection+0x22/0x27<br /> ? free_irq_cpu_rmap+0x23/0x7d<br /> mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core]<br /> irq_pool_request_vector+0x7d/0x90 [mlx5_core]<br /> mlx5_irq_request+0x2e/0xe0 [mlx5_core]<br /> mlx5_irq_request_vector+0xad/0xf7 [mlx5_core]<br /> comp_irq_request_pci+0x64/0xf0 [mlx5_core]<br /> create_comp_eq+0x71/0x385 [mlx5_core]<br /> ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core]<br /> mlx5_comp_eqn_get+0x72/0x90 [mlx5_core]<br /> ? xas_load+0x8/0x91<br /> mlx5_comp_irqn_get+0x40/0x90 [mlx5_core]<br /> mlx5e_open_channel+0x7d/0x3c7 [mlx5_core]<br /> mlx5e_open_channels+0xad/0x250 [mlx5_core]<br /> mlx5e_open_locked+0x3e/0x110 [mlx5_core]<br /> mlx5e_open+0x23/0x70 [mlx5_core]<br /> __dev_open+0xf1/0x1a5<br /> __dev_change_flags+0x1e1/0x249<br /> dev_change_flags+0x21/0x5c<br /> do_setlink+0x28b/0xcc4<br /> ? __nla_parse+0x22/0x3d<br /> ? inet6_validate_link_af+0x6b/0x108<br /> ? cpumask_next+0x1f/0x35<br /> ? __snmp6_fill_stats64.constprop.0+0x66/0x107<br /> ? __nla_validate_parse+0x48/0x1e6<br /> __rtnl_newlink+0x5ff/0xa57<br /> ? kmem_cache_alloc_trace+0x164/0x2ce<br /> rtnl_newlink+0x44/0x6e<br /> rtnetlink_rcv_msg+0x2bb/0x362<br /> ? __netlink_sendskb+0x4c/0x6c<br /> ? netlink_unicast+0x28f/0x2ce<br /> ? rtnl_calcit.isra.0+0x150/0x146<br /> netlink_rcv_skb+0x5f/0x112<br /> netlink_unicast+0x213/0x2ce<br /> netlink_sendmsg+0x24f/0x4d9<br /> __sock_sendmsg+0x65/0x6a<br /> ____sys_sendmsg+0x28f/0x2c9<br /> ? import_iovec+0x17/0x2b<br /> ___sys_sendmsg+0x97/0xe0<br /> __sys_sendmsg+0x81/0xd8<br /> do_syscall_64+0x35/0x87<br /> entry_SYSCALL_64_after_hwframe+0x6e/0x0<br /> RIP: 0033:0x7fc328603727<br /> Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed<br /> ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 3d 00<br /> f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48<br /> RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727<br /> RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d<br /> RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000<br /> R13: 00000000000<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> devlink: rate: Unset parent pointer in devl_rate_nodes_destroy<br /> <br /> The function devl_rate_nodes_destroy is documented to "Unset parent for<br /> all rate objects". However, it was only calling the driver-specific<br /> `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing<br /> the parent&amp;#39;s refcount, without actually setting the<br /> `devlink_rate-&gt;parent` pointer to NULL.<br /> <br /> This leaves a dangling pointer in the `devlink_rate` struct, which cause<br /> refcount error in netdevsim[1] and mlx5[2]. In addition, this is<br /> inconsistent with the behavior of `devlink_nl_rate_parent_node_set`,<br /> where the parent pointer is correctly cleared.<br /> <br /> This patch fixes the issue by explicitly setting `devlink_rate-&gt;parent`<br /> to NULL after notifying the driver, thus fulfilling the function&amp;#39;s<br /> documented behavior for all rate objects.<br /> <br /> [1]<br /> repro steps:<br /> echo 1 &gt; /sys/bus/netdevsim/new_device<br /> devlink dev eswitch set netdevsim/netdevsim1 mode switchdev<br /> echo 1 &gt; /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs<br /> devlink port function rate add netdevsim/netdevsim1/test_node<br /> devlink port function rate set netdevsim/netdevsim1/128 parent test_node<br /> echo 1 &gt; /sys/bus/netdevsim/del_device<br /> <br /> dmesg:<br /> refcount_t: decrement hit 0; leaking memory.<br /> WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0<br /> CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:refcount_warn_saturate+0x42/0xe0<br /> Call Trace:<br /> <br /> devl_rate_leaf_destroy+0x8d/0x90<br /> __nsim_dev_port_del+0x6c/0x70 [netdevsim]<br /> nsim_dev_reload_destroy+0x11c/0x140 [netdevsim]<br /> nsim_drv_remove+0x2b/0xb0 [netdevsim]<br /> device_release_driver_internal+0x194/0x1f0<br /> bus_remove_device+0xc6/0x130<br /> device_del+0x159/0x3c0<br /> device_unregister+0x1a/0x60<br /> del_device_store+0x111/0x170 [netdevsim]<br /> kernfs_fop_write_iter+0x12e/0x1e0<br /> vfs_write+0x215/0x3d0<br /> ksys_write+0x5f/0xd0<br /> do_syscall_64+0x55/0x10f0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> [2]<br /> devlink dev eswitch set pci/0000:08:00.0 mode switchdev<br /> devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000<br /> devlink port function rate add pci/0000:08:00.0/group1<br /> devlink port function rate set pci/0000:08:00.0/32768 parent group1<br /> modprobe -r mlx5_ib mlx5_fwctl mlx5_core<br /> <br /> dmesg:<br /> refcount_t: decrement hit 0; leaking memory.<br /> WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0<br /> CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:refcount_warn_saturate+0x42/0xe0<br /> Call Trace:<br /> <br /> devl_rate_leaf_destroy+0x8d/0x90<br /> mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core]<br /> mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core]<br /> mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core]<br /> mlx5_sf_esw_event+0xc4/0x120 [mlx5_core]<br /> notifier_call_chain+0x33/0xa0<br /> blocking_notifier_call_chain+0x3b/0x50<br /> mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core]<br /> mlx5_eswitch_disable+0x63/0x90 [mlx5_core]<br /> mlx5_unload+0x1d/0x170 [mlx5_core]<br /> mlx5_uninit_one+0xa2/0x130 [mlx5_core]<br /> remove_one+0x78/0xd0 [mlx5_core]<br /> pci_device_remove+0x39/0xa0<br /> device_release_driver_internal+0x194/0x1f0<br /> unbind_store+0x99/0xa0<br /> kernfs_fop_write_iter+0x12e/0x1e0<br /> vfs_write+0x215/0x3d0<br /> ksys_write+0x5f/0xd0<br /> do_syscall_64+0x53/0x1f0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock: Ignore signal/timeout on connect() if already established<br /> <br /> During connect(), acting on a signal/timeout by disconnecting an already<br /> established socket leads to several issues:<br /> <br /> 1. connect() invoking vsock_transport_cancel_pkt() -&gt;<br /> virtio_transport_purge_skbs() may race with sendmsg() invoking<br /> virtio_transport_get_credit(). This results in a permanently elevated<br /> `vvs-&gt;bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling.<br /> <br /> 2. connect() resetting a connected socket&amp;#39;s state may race with socket<br /> being placed in a sockmap. A disconnected socket remaining in a sockmap<br /> breaks sockmap&amp;#39;s assumptions. And gives rise to WARNs.<br /> <br /> 3. connect() transitioning SS_CONNECTED -&gt; SS_UNCONNECTED allows for a<br /> transport change/drop after TCP_ESTABLISHED. Which poses a problem for<br /> any simultaneous sendmsg() or connect() and may result in a<br /> use-after-free/null-ptr-deref.<br /> <br /> Do not disconnect socket on signal/timeout. Keep the logic for unconnected<br /> sockets: they don&amp;#39;t linger, can&amp;#39;t be placed in a sockmap, are rejected by<br /> sendmsg().<br /> <br /> [1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/<br /> [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/<br /> [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end()<br /> <br /> The loops in &amp;#39;qede_tpa_cont()&amp;#39; and &amp;#39;qede_tpa_end()&amp;#39;, iterate<br /> over &amp;#39;cqe-&gt;len_list[]&amp;#39; using only a zero-length terminator as<br /> the stopping condition. If the terminator was missing or<br /> malformed, the loop could run past the end of the fixed-size array.<br /> <br /> Add an explicit bound check using ARRAY_SIZE() in both loops to prevent<br /> a potential out-of-bounds access.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/ctcm: Fix double-kfree<br /> <br /> The function &amp;#39;mpc_rcvd_sweep_req(mpcginfo)&amp;#39; is called conditionally<br /> from function &amp;#39;ctcmpc_unpack_skb&amp;#39;. It frees passed mpcginfo.<br /> After that a call to function &amp;#39;kfree&amp;#39; in function &amp;#39;ctcmpc_unpack_skb&amp;#39;<br /> frees it again.<br /> <br /> Remove &amp;#39;kfree&amp;#39; call in function &amp;#39;mpc_rcvd_sweep_req(mpcginfo)&amp;#39;.<br /> <br /> Bug detected by the clang static analyzer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: avoid NULL dereference when chunk data buffer is missing<br /> <br /> chunk-&gt;skb pointer is dereferenced in the if-block where it&amp;#39;s supposed<br /> to be NULL only.<br /> <br /> chunk-&gt;skb can only be NULL if chunk-&gt;head_skb is not. Check for frag_list<br /> instead and do it just before replacing chunk-&gt;skb. We&amp;#39;re sure that<br /> otherwise chunk-&gt;skb is non-NULL because of outer if() condition.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: fix crafted invalid cases for encoded extents<br /> <br /> Robert recently reported two corrupted images that can cause system<br /> crashes, which are related to the new encoded extents introduced<br /> in Linux 6.15:<br /> <br /> - The first one [1] has plen != 0 (e.g. plen == 0x2000000) but<br /> (plen &amp; Z_EROFS_EXTENT_PLEN_MASK) == 0. It is used to represent<br /> special extents such as sparse extents (!EROFS_MAP_MAPPED), but<br /> previously only plen == 0 was handled;<br /> <br /> - The second one [2] has pa 0xffffffffffdcffed and plen 0xb4000,<br /> then "cur [0xfffffffffffff000] += bvec.bv_len [0x1000]" in<br /> "} while ((cur += bvec.bv_len) compressed_bvecs[] in<br /> z_erofs_submit_queue(). EROFS only supports 48-bit physical block<br /> addresses (up to 1EiB for 4k blocks), so add a sanity check to<br /> enforce this.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gfs2: Fix unlikely race in gdlm_put_lock<br /> <br /> In gdlm_put_lock(), there is a small window of time in which the<br /> DFL_UNMOUNT flag has been set but the lockspace hasn&amp;#39;t been released,<br /> yet. In that window, dlm may still call gdlm_ast() and gdlm_bast().<br /> To prevent it from dereferencing freed glock objects, only free the<br /> glock if the lockspace has actually been released.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfs: fix KMSAN uninit-value issue in hfs_find_set_zero_bits()<br /> <br /> The syzbot reported issue in hfs_find_set_zero_bits():<br /> <br /> =====================================================<br /> BUG: KMSAN: uninit-value in hfs_find_set_zero_bits+0x74d/0xb60 fs/hfs/bitmap.c:45<br /> hfs_find_set_zero_bits+0x74d/0xb60 fs/hfs/bitmap.c:45<br /> hfs_vbm_search_free+0x13c/0x5b0 fs/hfs/bitmap.c:151<br /> hfs_extend_file+0x6a5/0x1b00 fs/hfs/extent.c:408<br /> hfs_get_block+0x435/0x1150 fs/hfs/extent.c:353<br /> __block_write_begin_int+0xa76/0x3030 fs/buffer.c:2151<br /> block_write_begin fs/buffer.c:2262 [inline]<br /> cont_write_begin+0x10e1/0x1bc0 fs/buffer.c:2601<br /> hfs_write_begin+0x85/0x130 fs/hfs/inode.c:52<br /> cont_expand_zero fs/buffer.c:2528 [inline]<br /> cont_write_begin+0x35a/0x1bc0 fs/buffer.c:2591<br /> hfs_write_begin+0x85/0x130 fs/hfs/inode.c:52<br /> hfs_file_truncate+0x1d6/0xe60 fs/hfs/extent.c:494<br /> hfs_inode_setattr+0x964/0xaa0 fs/hfs/inode.c:654<br /> notify_change+0x1993/0x1aa0 fs/attr.c:552<br /> do_truncate+0x28f/0x310 fs/open.c:68<br /> do_ftruncate+0x698/0x730 fs/open.c:195<br /> do_sys_ftruncate fs/open.c:210 [inline]<br /> __do_sys_ftruncate fs/open.c:215 [inline]<br /> __se_sys_ftruncate fs/open.c:213 [inline]<br /> __x64_sys_ftruncate+0x11b/0x250 fs/open.c:213<br /> x64_sys_call+0xfe3/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:78<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slub.c:4154 [inline]<br /> slab_alloc_node mm/slub.c:4197 [inline]<br /> __kmalloc_cache_noprof+0x7f7/0xed0 mm/slub.c:4354<br /> kmalloc_noprof include/linux/slab.h:905 [inline]<br /> hfs_mdb_get+0x1cc8/0x2a90 fs/hfs/mdb.c:175<br /> hfs_fill_super+0x3d0/0xb80 fs/hfs/super.c:337<br /> get_tree_bdev_flags+0x6e3/0x920 fs/super.c:1681<br /> get_tree_bdev+0x38/0x50 fs/super.c:1704<br /> hfs_get_tree+0x35/0x40 fs/hfs/super.c:388<br /> vfs_get_tree+0xb0/0x5c0 fs/super.c:1804<br /> do_new_mount+0x738/0x1610 fs/namespace.c:3902<br /> path_mount+0x6db/0x1e90 fs/namespace.c:4226<br /> do_mount fs/namespace.c:4239 [inline]<br /> __do_sys_mount fs/namespace.c:4450 [inline]<br /> __se_sys_mount+0x6eb/0x7d0 fs/namespace.c:4427<br /> __x64_sys_mount+0xe4/0x150 fs/namespace.c:4427<br /> x64_sys_call+0xfa7/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:166<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> CPU: 1 UID: 0 PID: 12609 Comm: syz.1.2692 Not tainted 6.16.0-syzkaller #0 PREEMPT(none)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025<br /> =====================================================<br /> <br /> The HFS_SB(sb)-&gt;bitmap buffer is allocated in hfs_mdb_get():<br /> <br /> HFS_SB(sb)-&gt;bitmap = kmalloc(8192, GFP_KERNEL);<br /> <br /> Finally, it can trigger the reported issue because kmalloc()<br /> doesn&amp;#39;t clear the allocated memory. If allocated memory contains<br /> only zeros, then everything will work pretty fine.<br /> But if the allocated memory contains the "garbage", then<br /> it can affect the bitmap operations and it triggers<br /> the reported issue.<br /> <br /> This patch simply exchanges the kmalloc() on kzalloc()<br /> with the goal to guarantee the correctness of bitmap operations.<br /> Because, newly created allocation bitmap should have all<br /> available blocks free. Potentially, initialization bitmap&amp;#39;s read<br /> operation could not fill the whole allocated memory and<br /> "garbage" in the not initialized memory will be the reason of<br /> volume coruptions and file system driver bugs.