Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix NULL pointer dereference in VRAM logic for APU devices<br /> <br /> Previously, APU platforms (and other scenarios with uninitialized VRAM managers)<br /> triggered a NULL pointer dereference in `ttm_resource_manager_usage()`. The root<br /> cause is not that the `struct ttm_resource_manager *man` pointer itself is NULL,<br /> but that `man-&gt;bdev` (the backing device pointer within the manager) remains<br /> uninitialized (NULL) on APUs—since APUs lack dedicated VRAM and do not fully<br /> set up VRAM manager structures. When `ttm_resource_manager_usage()` attempts to<br /> acquire `man-&gt;bdev-&gt;lru_lock`, it dereferences the NULL `man-&gt;bdev`, leading to<br /> a kernel OOPS.<br /> <br /> 1. **amdgpu_cs.c**: Extend the existing bandwidth control check in<br /> `amdgpu_cs_get_threshold_for_moves()` to include a check for<br /> `ttm_resource_manager_used()`. If the manager is not used (uninitialized<br /> `bdev`), return 0 for migration thresholds immediately—skipping VRAM-specific<br /> logic that would trigger the NULL dereference.<br /> <br /> 2. **amdgpu_kms.c**: Update the `AMDGPU_INFO_VRAM_USAGE` ioctl and memory info<br /> reporting to use a conditional: if the manager is used, return the real VRAM<br /> usage; otherwise, return 0. This avoids accessing `man-&gt;bdev` when it is<br /> NULL.<br /> <br /> 3. **amdgpu_virt.c**: Modify the vf2pf (virtual function to physical function)<br /> data write path. Use `ttm_resource_manager_used()` to check validity: if the<br /> manager is usable, calculate `fb_usage` from VRAM usage; otherwise, set<br /> `fb_usage` to 0 (APUs have no discrete framebuffer to report).<br /> <br /> This approach is more robust than APU-specific checks because it:<br /> - Works for all scenarios where the VRAM manager is uninitialized (not just APUs),<br /> - Aligns with TTM&amp;#39;s design by using its native helper function,<br /> - Preserves correct behavior for discrete GPUs (which have fully initialized<br /> `man-&gt;bdev` and pass the `ttm_resource_manager_used()` check).<br /> <br /> v4: use ttm_resource_manager_used(&amp;adev-&gt;mman.vram_mgr.manager) instead of checking the adev-&gt;gmc.is_app_apu flag (Christian)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: hide VRAM sysfs attributes on GPUs without VRAM<br /> <br /> Otherwise accessing them can cause a crash.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: prevent possible shift-out-of-bounds in sctp_transport_update_rto<br /> <br /> syzbot reported a possible shift-out-of-bounds [1]<br /> <br /> Blamed commit added rto_alpha_max and rto_beta_max set to 1000.<br /> <br /> It is unclear if some sctp users are setting very large rto_alpha<br /> and/or rto_beta.<br /> <br /> In order to prevent user regression, perform the test at run time.<br /> <br /> Also add READ_ONCE() annotations as sysctl values can change under us.<br /> <br /> [1]<br /> <br /> UBSAN: shift-out-of-bounds in net/sctp/transport.c:509:41<br /> shift exponent 64 is too large for 32-bit type &amp;#39;unsigned int&amp;#39;<br /> CPU: 0 UID: 0 PID: 16704 Comm: syz.2.2320 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120<br /> ubsan_epilogue lib/ubsan.c:233 [inline]<br /> __ubsan_handle_shift_out_of_bounds+0x27f/0x420 lib/ubsan.c:494<br /> sctp_transport_update_rto.cold+0x1c/0x34b net/sctp/transport.c:509<br /> sctp_check_transmitted+0x11c4/0x1c30 net/sctp/outqueue.c:1502<br /> sctp_outq_sack+0x4ef/0x1b20 net/sctp/outqueue.c:1338<br /> sctp_cmd_process_sack net/sctp/sm_sideeffect.c:840 [inline]<br /> sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1372 [inline]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: 6lowpan: reset link-local header on ipv6 recv path<br /> <br /> Bluetooth 6lowpan.c netdev has header_ops, so it must set link-local<br /> header for RX skb, otherwise things crash, eg. with AF_PACKET SOCK_RAW<br /> <br /> Add missing skb_reset_mac_header() for uncompressed ipv6 RX path.<br /> <br /> For the compressed one, it is done in lowpan_header_decompress().<br /> <br /> Log: (BlueZ 6lowpan-tester Client Recv Raw - Success)<br /> ------<br /> kernel BUG at net/core/skbuff.c:212!<br /> Call Trace:<br /> <br /> ...<br /> packet_rcv (net/packet/af_packet.c:2152)<br /> ...<br /> <br /> __local_bh_enable_ip (kernel/softirq.c:407)<br /> netif_rx (net/core/dev.c:5648)<br /> chan_recv_cb (net/bluetooth/6lowpan.c:294 net/bluetooth/6lowpan.c:359)<br /> ------

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btusb: reorder cleanup in btusb_disconnect to avoid UAF<br /> <br /> There is a KASAN: slab-use-after-free read in btusb_disconnect().<br /> Calling "usb_driver_release_interface(&amp;btusb_driver, data-&gt;intf)" will<br /> free the btusb data associated with the interface. The same data is<br /> then used later in the function, hence the UAF.<br /> <br /> Fix by moving the accesses to btusb data to before the data is free&amp;#39;d.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: MGMT: cancel mesh send timer when hdev removed<br /> <br /> mesh_send_done timer is not canceled when hdev is removed, which causes<br /> crash if the timer triggers after hdev is gone.<br /> <br /> Cancel the timer when MGMT removes the hdev, like other MGMT timers.<br /> <br /> Should fix the BUG: sporadically seen by BlueZ test bot<br /> (in "Mesh - Send cancel - 1" test).<br /> <br /> Log:<br /> ------<br /> BUG: KASAN: slab-use-after-free in run_timer_softirq+0x76b/0x7d0<br /> ...<br /> Freed by task 36:<br /> kasan_save_stack+0x24/0x50<br /> kasan_save_track+0x14/0x30<br /> __kasan_save_free_info+0x3a/0x60<br /> __kasan_slab_free+0x43/0x70<br /> kfree+0x103/0x500<br /> device_release+0x9a/0x210<br /> kobject_put+0x100/0x1e0<br /> vhci_release+0x18b/0x240<br /> ------

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb/server: fix possible refcount leak in smb2_sess_setup()<br /> <br /> Reference count of ksmbd_session will leak when session need reconnect.<br /> Fix this by adding the missing ksmbd_user_session_put().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb/server: fix possible memory leak in smb2_read()<br /> <br /> Memory leak occurs when ksmbd_vfs_read() fails.<br /> Fix this by adding the missing kvfree().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exfat: fix improper check of dentry.stream.valid_size<br /> <br /> We found an infinite loop bug in the exFAT file system that can lead to a<br /> Denial-of-Service (DoS) condition. When a dentry in an exFAT filesystem is<br /> malformed, the following system calls — SYS_openat, SYS_ftruncate, and<br /> SYS_pwrite64 — can cause the kernel to hang.<br /> <br /> Root cause analysis shows that the size validation code in exfat_find()<br /> does not check whether dentry.stream.valid_size is negative. As a result,<br /> the system calls mentioned above can succeed and eventually trigger the DoS<br /> issue.<br /> <br /> This patch adds a check for negative dentry.stream.valid_size to prevent<br /> this vulnerability.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: free copynotify stateid in nfs4_free_ol_stateid()<br /> <br /> Typically copynotify stateid is freed either when parent&amp;#39;s stateid<br /> is being close/freed or in nfsd4_laundromat if the stateid hasn&amp;#39;t<br /> been used in a lease period.<br /> <br /> However, in case when the server got an OPEN (which created<br /> a parent stateid), followed by a COPY_NOTIFY using that stateid,<br /> followed by a client reboot. New client instance while doing<br /> CREATE_SESSION would force expire previous state of this client.<br /> It leads to the open state being freed thru release_openowner-&gt;<br /> nfs4_free_ol_stateid() and it finds that it still has copynotify<br /> stateid associated with it. We currently print a warning and is<br /> triggerred<br /> <br /> WARNING: CPU: 1 PID: 8858 at fs/nfsd/nfs4state.c:1550 nfs4_free_ol_stateid+0xb0/0x100 [nfsd]<br /> <br /> This patch, instead, frees the associated copynotify stateid here.<br /> <br /> If the parent stateid is freed (without freeing the copynotify<br /> stateids associated with it), it leads to the list corruption<br /> when laundromat ends up freeing the copynotify state later.<br /> <br /> [ 1626.839430] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP<br /> [ 1626.842828] Modules linked in: nfnetlink_queue nfnetlink_log bluetooth cfg80211 rpcrdma rdma_cm iw_cm ib_cm ib_core nfsd nfs_acl lockd grace nfs_localio ext4 crc16 mbcache jbd2 overlay uinput snd_seq_dummy snd_hrtimer qrtr rfkill vfat fat uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops snd_hda_intel uvc snd_intel_dspcfg videobuf2_v4l2 videobuf2_common snd_hda_codec snd_hda_core videodev snd_hwdep snd_seq mc snd_seq_device snd_pcm snd_timer snd soundcore sg loop auth_rpcgss vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs 8021q garp stp llc mrp nvme ghash_ce e1000e nvme_core sr_mod nvme_keyring nvme_auth cdrom vmwgfx drm_ttm_helper ttm sunrpc dm_mirror dm_region_hash dm_log iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi fuse dm_multipath dm_mod nfnetlink<br /> [ 1626.855594] CPU: 2 UID: 0 PID: 199 Comm: kworker/u24:33 Kdump: loaded Tainted: G B W 6.17.0-rc7+ #22 PREEMPT(voluntary)<br /> [ 1626.857075] Tainted: [B]=BAD_PAGE, [W]=WARN<br /> [ 1626.857573] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024<br /> [ 1626.858724] Workqueue: nfsd4 laundromat_main [nfsd]<br /> [ 1626.859304] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> [ 1626.860010] pc : __list_del_entry_valid_or_report+0x148/0x200<br /> [ 1626.860601] lr : __list_del_entry_valid_or_report+0x148/0x200<br /> [ 1626.861182] sp : ffff8000881d7a40<br /> [ 1626.861521] x29: ffff8000881d7a40 x28: 0000000000000018 x27: ffff0000c2a98200<br /> [ 1626.862260] x26: 0000000000000600 x25: 0000000000000000 x24: ffff8000881d7b20<br /> [ 1626.862986] x23: ffff0000c2a981e8 x22: 1fffe00012410e7d x21: ffff0000920873e8<br /> [ 1626.863701] x20: ffff0000920873e8 x19: ffff000086f22998 x18: 0000000000000000<br /> [ 1626.864421] x17: 20747562202c3839 x16: 3932326636383030 x15: 3030666666662065<br /> [ 1626.865092] x14: 6220646c756f6873 x13: 0000000000000001 x12: ffff60004fd9e4a3<br /> [ 1626.865713] x11: 1fffe0004fd9e4a2 x10: ffff60004fd9e4a2 x9 : dfff800000000000<br /> [ 1626.866320] x8 : 00009fffb0261b5e x7 : ffff00027ecf2513 x6 : 0000000000000001<br /> [ 1626.866938] x5 : ffff00027ecf2510 x4 : ffff60004fd9e4a3 x3 : 0000000000000000<br /> [ 1626.867553] x2 : 0000000000000000 x1 : ffff000096069640 x0 : 000000000000006d<br /> [ 1626.868167] Call trace:<br /> [ 1626.868382] __list_del_entry_valid_or_report+0x148/0x200 (P)<br /> [ 1626.868876] _free_cpntf_state_locked+0xd0/0x268 [nfsd]<br /> [ 1626.869368] nfs4_laundromat+0x6f8/0x1058 [nfsd]<br /> [ 1626.869813] laundromat_main+0x24/0x60 [nfsd]<br /> [ 1626.870231] process_one_work+0x584/0x1050<br /> [ 1626.870595] worker_thread+0x4c4/0xc60<br /> [ 1626.870893] kthread+0x2f8/0x398<br /> [ 1626.871146] ret_from_fork+0x10/0x20<br /> [ 1626.871422] Code: aa1303e1 aa1403e3 910e8000 97bc55d7 (d4210000)<br /> [ 1626.871892] SMP: stopping secondary CPUs

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: guest_memfd: Remove bindings on memslot deletion when gmem is dying<br /> <br /> When unbinding a memslot from a guest_memfd instance, remove the bindings<br /> even if the guest_memfd file is dying, i.e. even if its file refcount has<br /> gone to zero. If the memslot is freed before the file is fully released,<br /> nullifying the memslot side of the binding in kvm_gmem_release() will<br /> write to freed memory, as detected by syzbot+KASAN:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in kvm_gmem_release+0x176/0x440 virt/kvm/guest_memfd.c:353<br /> Write of size 8 at addr ffff88807befa508 by task syz.0.17/6022<br /> <br /> CPU: 0 UID: 0 PID: 6022 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0xca/0x240 mm/kasan/report.c:482<br /> kasan_report+0x118/0x150 mm/kasan/report.c:595<br /> kvm_gmem_release+0x176/0x440 virt/kvm/guest_memfd.c:353<br /> __fput+0x44c/0xa70 fs/file_table.c:468<br /> task_work_run+0x1d4/0x260 kernel/task_work.c:227<br /> resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]<br /> exit_to_user_mode_loop+0xe9/0x130 kernel/entry/common.c:43<br /> exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline]<br /> syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline]<br /> syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline]<br /> do_syscall_64+0x2bd/0xfa0 arch/x86/entry/syscall_64.c:100<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7fbeeff8efc9<br /> <br /> <br /> Allocated by task 6023:<br /> kasan_save_stack mm/kasan/common.c:56 [inline]<br /> kasan_save_track+0x3e/0x80 mm/kasan/common.c:77<br /> poison_kmalloc_redzone mm/kasan/common.c:397 [inline]<br /> __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:414<br /> kasan_kmalloc include/linux/kasan.h:262 [inline]<br /> __kmalloc_cache_noprof+0x3e2/0x700 mm/slub.c:5758<br /> kmalloc_noprof include/linux/slab.h:957 [inline]<br /> kzalloc_noprof include/linux/slab.h:1094 [inline]<br /> kvm_set_memory_region+0x747/0xb90 virt/kvm/kvm_main.c:2104<br /> kvm_vm_ioctl_set_memory_region+0x6f/0xd0 virt/kvm/kvm_main.c:2154<br /> kvm_vm_ioctl+0x957/0xc60 virt/kvm/kvm_main.c:5201<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:597 [inline]<br /> __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Freed by task 6023:<br /> kasan_save_stack mm/kasan/common.c:56 [inline]<br /> kasan_save_track+0x3e/0x80 mm/kasan/common.c:77<br /> kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584<br /> poison_slab_object mm/kasan/common.c:252 [inline]<br /> __kasan_slab_free+0x5c/0x80 mm/kasan/common.c:284<br /> kasan_slab_free include/linux/kasan.h:234 [inline]<br /> slab_free_hook mm/slub.c:2533 [inline]<br /> slab_free mm/slub.c:6622 [inline]<br /> kfree+0x19a/0x6d0 mm/slub.c:6829<br /> kvm_set_memory_region+0x9c4/0xb90 virt/kvm/kvm_main.c:2130<br /> kvm_vm_ioctl_set_memory_region+0x6f/0xd0 virt/kvm/kvm_main.c:2154<br /> kvm_vm_ioctl+0x957/0xc60 virt/kvm/kvm_main.c:5201<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:597 [inline]<br /> __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Deliberately don&amp;#39;t acquire filemap invalid lock when the file is dying as<br /> the lifecycle of f_mapping is outside the purview of KVM. Dereferencing<br /> the mapping is *probably* fine, but there&amp;#39;s no need to invalidate anything<br /> as memslot deletion is responsible for zapping SPTEs, and the only code<br /> that can access the dying file is kvm_gmem_release(), whose core code is<br /> mutual<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: Fix NULL pointer dereference in snd_usb_mixer_controls_badd<br /> <br /> In snd_usb_create_streams(), for UAC version 3 devices, the Interface<br /> Association Descriptor (IAD) is retrieved via usb_ifnum_to_if(). If this<br /> call fails, a fallback routine attempts to obtain the IAD from the next<br /> interface and sets a BADD profile. However, snd_usb_mixer_controls_badd()<br /> assumes that the IAD retrieved from usb_ifnum_to_if() is always valid,<br /> without performing a NULL check. This can lead to a NULL pointer<br /> dereference when usb_ifnum_to_if() fails to find the interface descriptor.<br /> <br /> This patch adds a NULL pointer check after calling usb_ifnum_to_if() in<br /> snd_usb_mixer_controls_badd() to prevent the dereference.<br /> <br /> This issue was discovered by syzkaller, which triggered the bug by sending<br /> a crafted USB device descriptor.