Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/amdxdna: Fix leak when pinning ubuf pages<br /> <br /> When pin_user_pages_fast() returns fewer pages than requested, the pages<br /> that were successfully pinned are not released, leading to a leak.<br /> <br /> Fix this by unpinning any partially pinned pages before returning failure.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbcon: fix NULL pointer dereference for a console without vc_data<br /> <br /> fbcon_new_modelist() runs when a framebuffer&amp;#39;s modelist changes. For each<br /> console mapped to it with fb_display[i].mode set, it reads vc_cons[i].d and<br /> passes the vc_num to fbcon_set_disp(). This assumes a console with a mode<br /> set has a vc_data, but it can be NULL. fbcon_set_disp() sets<br /> fb_display[i].mode before it checks vc_data, and fbcon_deinit() leaves the<br /> mode set after the vc_data is freed. fbcon_new_modelist() then dereferences<br /> the NULL vc_data.<br /> <br /> Keep fb_display[i].mode set only while the console has a vc_data. Check<br /> vc_data before setting the mode in fbcon_set_disp(), and clear the mode in<br /> fbcon_deinit(). The existing mode check in fbcon_new_modelist() then skips<br /> such consoles.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> afs: handle CB.InitCallBackState3 requests without a server record<br /> <br /> The cache manager callback path now attaches the server record to an<br /> incoming call through the rxrpc peer&amp;#39;s app data. That association is<br /> not guaranteed to exist for every callback request, and most callback<br /> handlers already tolerate that case.<br /> <br /> Make CB.InitCallBackState3 follow the same pattern by checking whether a<br /> server record was attached before using it. If the peer is not mapped<br /> to a server record, trace the request and ignore it, matching the<br /> existing behaviour for other unmatched callback requests.<br /> <br /> This keeps the callback handler consistent with the rest of the cache<br /> manager service and avoids depending on peer state that may not be<br /> available for a given request.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> afs: fix NULL pointer dereference in afs_get_tree()<br /> <br /> afs_alloc_sbi() uses kzalloc for memory allocation. And, if<br /> ctx-&gt;dyn_root is not null, as-&gt;cell and as-&gt;volume are null.<br /> In trace_afs_get_tree() they are dereferenced.<br /> <br /> KASAN error message:<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> CPU: 2 PID: 18478 Comm: syz-executor.7 Not tainted 5.10.246-syzkaller #0<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1<br /> 04/01/2014<br /> RIP: 0010:perf_trace_afs_get_tree+0x1d9/0x550<br /> include/trace/events/afs.h:1365<br /> <br /> Call Trace:<br /> trace_afs_get_tree include/trace/events/afs.h:1365 [inline]<br /> afs_get_tree+0x922/0x1350 fs/afs/super.c:599<br /> vfs_get_tree+0x8e/0x300 fs/super.c:1572<br /> do_new_mount fs/namespace.c:3011 [inline]<br /> path_mount+0x14a5/0x2220 fs/namespace.c:3341<br /> do_mount fs/namespace.c:3354 [inline]<br /> __do_sys_mount fs/namespace.c:3562 [inline]<br /> __se_sys_mount fs/namespace.c:3539 [inline]<br /> __x64_sys_mount+0x283/0x300 fs/namespace.c:3539<br /> do_syscall_64+0x33/0x50 arch/x86/entry/common.c:46<br /> entry_SYSCALL_64_after_hwframe+0x67/0xd1<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> afs: Fix netns teardown to cancel the preallocation charger<br /> <br /> Fix the teardown of an afs network namespace to make sure it cancels the<br /> work item that keeps the preallocated rxrpc call/conn/peer queue charged<br /> before incoming calls are disabled (i.e. listen 0).<br /> <br /> Also, if net-&gt;live is false because the afs netns is being deleted, make<br /> afs_charge_preallocation() skip charging and make afs_rx_new_call() avoid<br /> requeuing the charger.<br /> <br /> (This was found by AI review).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix double unlock in rxrpc_recvmsg()<br /> <br /> Fix a double unlock in rxrpc_recvmsg() when dealing with OOB messages.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw88: fix OOB read from firmware RX descriptor exceeding DMA buffer<br /> <br /> In rtw_pci_rx_napi(), new_len is computed as the sum of pkt_len (14-bit<br /> descriptor field, max 16383) and pkt_offset (drv_info_sz + shift, both<br /> firmware-controlled). The result can exceed RTK_PCI_RX_BUF_SIZE (11478),<br /> causing an out-of-bounds read from the pre-allocated DMA buffer when<br /> skb_put_data copies new_len bytes. The USB transport already validates<br /> this (rtw_usb_rx_data_put checks against RTW_USB_MAX_RECVBUF_SZ); the<br /> PCIe path does not.<br /> <br /> Add a check that new_len does not exceed the DMA buffer size.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: Correct data type for scan index to avoid infinite loop<br /> <br /> A kernel soft lockup was observed during Wi-Fi scanning on the 6GHz band.<br /> The CPU becomes stuck in rtw89_hw_scan_add_chan_ax for over 20 seconds,<br /> leading to a system panic.<br /> <br /> RIP points to 0f b6 c3 (movzbl %bl, %eax), which zero-extends<br /> the low 8 bits of RBX into RAX.<br /> RBX (the counter i) has reached a huge value: 0x137466a1.<br /> <br /> watchdog: BUG: soft lockup - CPU#2 stuck for 26s! [kworker/u16:4:6124]<br /> Workqueue: events_unbound cfg80211_wiphy_work [cfg80211]<br /> RIP: 0010:rtw89_hw_scan_add_chan_ax+0xb3/0x6e0 [rtw89_core]<br /> Code: a0 48 89 45 a8 44 89 6d 9c 44 89 75 98 eb 29 66 66 2e 0f 1f<br /> 84 00 00 00 00 00 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 83 c3 01<br /> b6 c3 41 3b 44 24 74 0f 83 0b 02 00 00 0f b6 c3 48 8d 14 80 49<br /> RSP: 0018:ffffcb48cbaa39f8 EFLAGS: 00000202<br /> RAX: 0000000000000005 RBX: 00000000137466a1 RCX: 0000000000000000<br /> RDX: ffff89ffc9d851a8 RSI: 0000000000004f0d RDI: 0000000096af0130<br /> RBP: ffffcb48cbaa3a60 R08: 0000000000000000 R09: ffff8a00b7502080<br /> R10: ffff8a00b75ff600 R11: 0000000000000000 R12: ffff89ffc7553870<br /> R13: ffff8a00b7ac8f19 R14: ffff8a00b75020d8 R15: ffff89ffc3d54d80<br /> FS: 0000000000000000(0000) GS:ffff8a014f962000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007558d7f9f4c4 CR3: 0000000178040001 CR4: 00000000001706f0<br /> Call Trace:<br /> <br /> rtw89_hw_scan_prep_chan_list_ax+0x8a/0x400 [rtw89_core]<br /> rtw89_hw_scan_start+0x546/0x8a0 [rtw89_core]<br /> ? rtw89_fw_h2c_default_cmac_tbl+0x13c/0x1f0 [rtw89_core]<br /> rtw89_ops_hw_scan+0xae/0x120 [rtw89_core]<br /> drv_hw_scan+0xbb/0x180 [mac80211]<br /> __ieee80211_start_scan+0x2fc/0x750 [mac80211]<br /> ieee80211_request_scan+0xe/0x20 [mac80211]<br /> ieee80211_scan+0x123/0x190 [mac80211]<br /> rdev_scan+0x40/0x110 [cfg80211]<br /> cfg80211_scan_6ghz+0x5a1/0xa30 [cfg80211]<br /> <br /> By objdump with source:<br /> <br /> for (i = 0; i n_6ghz_params; i++) {<br /> 5fbc0: 83 c3 01 add $0x1,%ebx --&gt; i++<br /> 5fbc3: 0f b6 c3 movzbl %bl,%eax --&gt; get counter<br /> fbc6: 41 3b 44 24 74 cmp 0x74(%r12),%eax<br /> <br /> * RBX: 00000000137466a1 -&gt; %bl = a1 -&gt; EAX = 000000a1 (161)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw88: fix wrong pci_get_drvdata type in AER handlers<br /> <br /> rtw88 stores an ieee80211_hw pointer via pci_set_drvdata() at probe<br /> time, but io_error_detected() and io_resume() retrieve it as a<br /> net_device pointer. This causes netif_device_detach/attach to<br /> operate on an ieee80211_hw struct, reading and writing at wrong<br /> offsets.<br /> <br /> Use ieee80211_stop_queues/wake_queues instead, consistent with<br /> every other queue stop/start path in the driver.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: fix wrong pci_get_drvdata type in AER handlers<br /> <br /> rtw89 stores an ieee80211_hw pointer via pci_set_drvdata() at probe<br /> time, but io_error_detected() and io_resume() retrieve it as a<br /> net_device pointer. This causes netif_device_detach/attach to<br /> operate on an ieee80211_hw struct, reading and writing at wrong<br /> offsets. The adjacent io_slot_reset() already does it correctly.<br /> <br /> Use ieee80211_stop_queues/wake_queues instead, consistent with<br /> every other queue stop/start path in the driver.<br /> <br /> Tested on RTL8852CE by calling the handlers from a test module<br /> before and after the fix.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfsplus: Remove the duplicate attr inode dirty marking action<br /> <br /> Syzbot reported a null-ptr-deref in [1].<br /> If the attributes file is not loaded during system mount, a trigger<br /> occurs [1] when setxattr is executed in userspace.<br /> <br /> Remove the first mark attr inode dirty operation.<br /> <br /> [1]<br /> KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]<br /> Call Trace:<br /> hfsplus_setxattr+0x124/0x340 fs/hfsplus/xattr.c:555<br /> hfsplus_trusted_setxattr+0x40/0x60 fs/hfsplus/xattr_trusted.c:30<br /> __vfs_setxattr+0x43c/0x480 fs/xattr.c:218<br /> __vfs_setxattr_noperm+0x12d/0x660 fs/xattr.c:252<br /> vfs_setxattr+0x163/0x360 fs/xattr.c:339<br /> do_setxattr fs/xattr.c:654 [inline]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: atcspi200: fix use-after-free when driver unbind<br /> <br /> DMA resource is initialized after SPI controller registration. So<br /> when driver unbind, this can trigger a use-after-free when DMA is<br /> torn down while the controller is still alive and triggers DMA transfers.