Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix potential cfid UAF in smb2_query_info_compound<br /> <br /> When smb2_query_info_compound() retries, a previously allocated cfid may<br /> have been freed in the first attempt.<br /> Because cfid wasn&amp;#39;t reset on replay, later cleanup could act on a stale<br /> pointer, leading to a potential use-after-free.<br /> <br /> Reinitialize cfid to NULL under the replay label.<br /> <br /> Example trace (trimmed):<br /> <br /> refcount_t: underflow; use-after-free.<br /> WARNING: CPU: 1 PID: 11224 at ../lib/refcount.c:28 refcount_warn_saturate+0x9c/0x110<br /> [...]<br /> RIP: 0010:refcount_warn_saturate+0x9c/0x110<br /> [...]<br /> Call Trace:<br /> <br /> smb2_query_info_compound+0x29c/0x5c0 [cifs f90b72658819bd21c94769b6a652029a07a7172f]<br /> ? step_into+0x10d/0x690<br /> ? __legitimize_path+0x28/0x60<br /> smb2_queryfs+0x6a/0xf0 [cifs f90b72658819bd21c94769b6a652029a07a7172f]<br /> smb311_queryfs+0x12d/0x140 [cifs f90b72658819bd21c94769b6a652029a07a7172f]<br /> ? kmem_cache_alloc+0x18a/0x340<br /> ? getname_flags+0x46/0x1e0<br /> cifs_statfs+0x9f/0x2b0 [cifs f90b72658819bd21c94769b6a652029a07a7172f]<br /> statfs_by_dentry+0x67/0x90<br /> vfs_statfs+0x16/0xd0<br /> user_statfs+0x54/0xa0<br /> __do_sys_statfs+0x20/0x50<br /> do_syscall_64+0x58/0x80

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: brcmfmac: fix crash while sending Action Frames in standalone AP Mode<br /> <br /> Currently, whenever there is a need to transmit an Action frame,<br /> the brcmfmac driver always uses the P2P vif to send the "actframe" IOVAR to<br /> firmware. The P2P interfaces were available when wpa_supplicant is managing<br /> the wlan interface.<br /> <br /> However, the P2P interfaces are not created/initialized when only hostapd<br /> is managing the wlan interface. And if hostapd receives an ANQP Query REQ<br /> Action frame even from an un-associated STA, the brcmfmac driver tries<br /> to use an uninitialized P2P vif pointer for sending the IOVAR to firmware.<br /> This NULL pointer dereferencing triggers a driver crash.<br /> <br /> [ 1417.074538] Unable to handle kernel NULL pointer dereference at virtual<br /> address 0000000000000000<br /> [...]<br /> [ 1417.075188] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT)<br /> [...]<br /> [ 1417.075653] Call trace:<br /> [ 1417.075662] brcmf_p2p_send_action_frame+0x23c/0xc58 [brcmfmac]<br /> [ 1417.075738] brcmf_cfg80211_mgmt_tx+0x304/0x5c0 [brcmfmac]<br /> [ 1417.075810] cfg80211_mlme_mgmt_tx+0x1b0/0x428 [cfg80211]<br /> [ 1417.076067] nl80211_tx_mgmt+0x238/0x388 [cfg80211]<br /> [ 1417.076281] genl_family_rcv_msg_doit+0xe0/0x158<br /> [ 1417.076302] genl_rcv_msg+0x220/0x2a0<br /> [ 1417.076317] netlink_rcv_skb+0x68/0x140<br /> [ 1417.076330] genl_rcv+0x40/0x60<br /> [ 1417.076343] netlink_unicast+0x330/0x3b8<br /> [ 1417.076357] netlink_sendmsg+0x19c/0x3f8<br /> [ 1417.076370] __sock_sendmsg+0x64/0xc0<br /> [ 1417.076391] ____sys_sendmsg+0x268/0x2a0<br /> [ 1417.076408] ___sys_sendmsg+0xb8/0x118<br /> [ 1417.076427] __sys_sendmsg+0x90/0xf8<br /> [ 1417.076445] __arm64_sys_sendmsg+0x2c/0x40<br /> [ 1417.076465] invoke_syscall+0x50/0x120<br /> [ 1417.076486] el0_svc_common.constprop.0+0x48/0xf0<br /> [ 1417.076506] do_el0_svc+0x24/0x38<br /> [ 1417.076525] el0_svc+0x30/0x100<br /> [ 1417.076548] el0t_64_sync_handler+0x100/0x130<br /> [ 1417.076569] el0t_64_sync+0x190/0x198<br /> [ 1417.076589] Code: f9401e80 aa1603e2 f9403be1 5280e483 (f9400000)<br /> <br /> Fix this, by always using the vif corresponding to the wdev on which the<br /> Action frame Transmission request was initiated by the userspace. This way,<br /> even if P2P vif is not available, the IOVAR is sent to firmware on AP vif<br /> and the ANQP Query RESP Action frame is transmitted without crashing the<br /> driver.<br /> <br /> Move init_completion() for "send_af_done" from brcmf_p2p_create_p2pdev()<br /> to brcmf_p2p_attach(). Because the former function would not get executed<br /> when only hostapd is managing wlan interface, and it is not safe to do<br /> reinit_completion() later in brcmf_p2p_tx_action_frame(), without any prior<br /> init_completion().<br /> <br /> And in the brcmf_p2p_tx_action_frame() function, the condition check for<br /> P2P Presence response frame is not needed, since the wpa_supplicant is<br /> properly sending the P2P Presense Response frame on the P2P-GO vif instead<br /> of the P2P-Device vif.<br /> <br /> [Cc stable]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: bitblit: bound-check glyph index in bit_putcs*<br /> <br /> bit_putcs_aligned()/unaligned() derived the glyph pointer from the<br /> character value masked by 0xff/0x1ff, which may exceed the actual font&amp;#39;s<br /> glyph count and read past the end of the built-in font array.<br /> Clamp the index to the actual glyph count before computing the address.<br /> <br /> This fixes a global out-of-bounds read reported by syzbot.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: SCO: Fix UAF on sco_conn_free<br /> <br /> BUG: KASAN: slab-use-after-free in sco_conn_free net/bluetooth/sco.c:87 [inline]<br /> BUG: KASAN: slab-use-after-free in kref_put include/linux/kref.h:65 [inline]<br /> BUG: KASAN: slab-use-after-free in sco_conn_put+0xdd/0x410<br /> net/bluetooth/sco.c:107<br /> Write of size 8 at addr ffff88811cb96b50 by task kworker/u17:4/352<br /> <br /> CPU: 1 UID: 0 PID: 352 Comm: kworker/u17:4 Not tainted<br /> 6.17.0-rc5-g717368f83676 #4 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> Workqueue: hci13 hci_cmd_sync_work<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x10b/0x170 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0x191/0x550 mm/kasan/report.c:482<br /> kasan_report+0xc4/0x100 mm/kasan/report.c:595<br /> sco_conn_free net/bluetooth/sco.c:87 [inline]<br /> kref_put include/linux/kref.h:65 [inline]<br /> sco_conn_put+0xdd/0x410 net/bluetooth/sco.c:107<br /> sco_connect_cfm+0xb4/0xae0 net/bluetooth/sco.c:1441<br /> hci_connect_cfm include/net/bluetooth/hci_core.h:2082 [inline]<br /> hci_conn_failed+0x20a/0x2e0 net/bluetooth/hci_conn.c:1313<br /> hci_conn_unlink+0x55f/0x810 net/bluetooth/hci_conn.c:1121<br /> hci_conn_del+0xb6/0x1110 net/bluetooth/hci_conn.c:1147<br /> hci_abort_conn_sync+0x8c5/0xbb0 net/bluetooth/hci_sync.c:5689<br /> hci_cmd_sync_work+0x281/0x380 net/bluetooth/hci_sync.c:332<br /> process_one_work kernel/workqueue.c:3236 [inline]<br /> process_scheduled_works+0x77e/0x1040 kernel/workqueue.c:3319<br /> worker_thread+0xbee/0x1200 kernel/workqueue.c:3400<br /> kthread+0x3c7/0x870 kernel/kthread.c:463<br /> ret_from_fork+0x13a/0x1e0 arch/x86/kernel/process.c:148<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245<br /> <br /> <br /> Allocated by task 31370:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x30/0x70 mm/kasan/common.c:68<br /> poison_kmalloc_redzone mm/kasan/common.c:388 [inline]<br /> __kasan_kmalloc+0x82/0x90 mm/kasan/common.c:405<br /> kasan_kmalloc include/linux/kasan.h:260 [inline]<br /> __do_kmalloc_node mm/slub.c:4382 [inline]<br /> __kmalloc_noprof+0x22f/0x390 mm/slub.c:4394<br /> kmalloc_noprof include/linux/slab.h:909 [inline]<br /> sk_prot_alloc+0xae/0x220 net/core/sock.c:2239<br /> sk_alloc+0x34/0x5a0 net/core/sock.c:2295<br /> bt_sock_alloc+0x3c/0x330 net/bluetooth/af_bluetooth.c:151<br /> sco_sock_alloc net/bluetooth/sco.c:562 [inline]<br /> sco_sock_create+0xc0/0x350 net/bluetooth/sco.c:593<br /> bt_sock_create+0x161/0x3b0 net/bluetooth/af_bluetooth.c:135<br /> __sock_create+0x3ad/0x780 net/socket.c:1589<br /> sock_create net/socket.c:1647 [inline]<br /> __sys_socket_create net/socket.c:1684 [inline]<br /> __sys_socket+0xd5/0x330 net/socket.c:1731<br /> __do_sys_socket net/socket.c:1745 [inline]<br /> __se_sys_socket net/socket.c:1743 [inline]<br /> __x64_sys_socket+0x7a/0x90 net/socket.c:1743<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xc7/0x240 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Freed by task 31374:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x30/0x70 mm/kasan/common.c:68<br /> kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:576<br /> poison_slab_object mm/kasan/common.c:243 [inline]<br /> __kasan_slab_free+0x3d/0x50 mm/kasan/common.c:275<br /> kasan_slab_free include/linux/kasan.h:233 [inline]<br /> slab_free_hook mm/slub.c:2428 [inline]<br /> slab_free mm/slub.c:4701 [inline]<br /> kfree+0x199/0x3b0 mm/slub.c:4900<br /> sk_prot_free net/core/sock.c:2278 [inline]<br /> __sk_destruct+0x4aa/0x630 net/core/sock.c:2373<br /> sco_sock_release+0x2ad/0x300 net/bluetooth/sco.c:1333<br /> __sock_release net/socket.c:649 [inline]<br /> sock_close+0xb8/0x230 net/socket.c:1439<br /> __fput+0x3d1/0x9e0 fs/file_table.c:468<br /> task_work_run+0x206/0x2a0 kernel/task_work.c:227<br /> get_signal+0x1201/0x1410 kernel/signal.c:2807<br /> arch_do_signal_or_restart+0x34/0x740 arch/x86/kernel/signal.c:337<br /> exit_to_user_mode_loop+0x68/0xc0 kernel/entry/common.c:40<br /> exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline]<br /> s<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: bcsp: receive data only if registered<br /> <br /> Currently, bcsp_recv() can be called even when the BCSP protocol has not<br /> been registered. This leads to a NULL pointer dereference, as shown in<br /> the following stack trace:<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f]<br /> RIP: 0010:bcsp_recv+0x13d/0x1740 drivers/bluetooth/hci_bcsp.c:590<br /> Call Trace:<br /> <br /> hci_uart_tty_receive+0x194/0x220 drivers/bluetooth/hci_ldisc.c:627<br /> tiocsti+0x23c/0x2c0 drivers/tty/tty_io.c:2290<br /> tty_ioctl+0x626/0xde0 drivers/tty/tty_io.c:2706<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:907 [inline]<br /> __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> To prevent this, ensure that the HCI_UART_REGISTERED flag is set before<br /> processing received data. If the protocol is not registered, return<br /> -EUNATCH.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> amd/amdkfd: resolve a race in amdgpu_amdkfd_device_fini_sw<br /> <br /> There is race in amdgpu_amdkfd_device_fini_sw and interrupt.<br /> if amdgpu_amdkfd_device_fini_sw run in b/w kfd_cleanup_nodes and<br /> kfree(kfd), and KGD interrupt generated.<br /> <br /> kernel panic log:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000098<br /> amdgpu 0000:c8:00.0: amdgpu: Requesting 4 partitions through PSP<br /> <br /> PGD d78c68067 P4D d78c68067<br /> <br /> kfd kfd: amdgpu: Allocated 3969056 bytes on gart<br /> <br /> PUD 1465b8067 PMD @<br /> <br /> Oops: @002 [#1] SMP NOPTI<br /> <br /> kfd kfd: amdgpu: Total number of KFD nodes to be created: 4<br /> CPU: 115 PID: @ Comm: swapper/115 Kdump: loaded Tainted: G S W OE K<br /> <br /> RIP: 0010:_raw_spin_lock_irqsave+0x12/0x40<br /> <br /> Code: 89 e@ 41 5c c3 cc cc cc cc 66 66 2e Of 1f 84 00 00 00 00 00 OF 1f 40 00 Of 1f 44% 00 00 41 54 9c 41 5c fa 31 cO ba 01 00 00 00 OF b1 17 75 Ba 4c 89 e@ 41 Sc<br /> <br /> 89 c6 e8 07 38 5d<br /> <br /> RSP: 0018: ffffc90@1a6b0e28 EFLAGS: 00010046<br /> <br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000018<br /> 0000000000000001 RSI: ffff8883bb623e00 RDI: 0000000000000098<br /> ffff8883bb000000 RO8: ffff888100055020 ROO: ffff888100055020<br /> 0000000000000000 R11: 0000000000000000 R12: 0900000000000002<br /> ffff888F2b97da0@ R14: @000000000000098 R15: ffff8883babdfo00<br /> <br /> CS: 010 DS: 0000 ES: 0000 CRO: 0000000080050033<br /> <br /> CR2: 0000000000000098 CR3: 0000000e7cae2006 CR4: 0000000002770ce0<br /> 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> 0000000000000000 DR6: 00000000fffeO7FO DR7: 0000000000000400<br /> <br /> PKRU: 55555554<br /> <br /> Call Trace:<br /> <br /> <br /> <br /> kgd2kfd_interrupt+@x6b/0x1f@ [amdgpu]<br /> <br /> ? amdgpu_fence_process+0xa4/0x150 [amdgpu]<br /> <br /> kfd kfd: amdgpu: Node: 0, interrupt_bitmap: 3 YcpxFl Rant tErace<br /> <br /> amdgpu_irq_dispatch+0x165/0x210 [amdgpu]<br /> <br /> amdgpu_ih_process+0x80/0x100 [amdgpu]<br /> <br /> amdgpu: Virtual CRAT table created for GPU<br /> <br /> amdgpu_irq_handler+0x1f/@x60 [amdgpu]<br /> <br /> __handle_irq_event_percpu+0x3d/0x170<br /> <br /> amdgpu: Topology: Add dGPU node [0x74a2:0x1002]<br /> <br /> handle_irq_event+0x5a/@xcO<br /> <br /> handle_edge_irq+0x93/0x240<br /> <br /> kfd kfd: amdgpu: KFD node 1 partition @ size 49148M<br /> <br /> asm_call_irq_on_stack+0xf/@x20<br /> <br /> <br /> <br /> common_interrupt+0xb3/0x130<br /> <br /> asm_common_interrupt+0x1le/0x40<br /> <br /> 5.10.134-010.a1i5000.a18.x86_64 #1

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/habanalabs: support mapping cb with vmalloc-backed coherent memory<br /> <br /> When IOMMU is enabled, dma_alloc_coherent() with GFP_USER may return<br /> addresses from the vmalloc range. If such an address is mapped without<br /> VM_MIXEDMAP, vm_insert_page() will trigger a BUG_ON due to the<br /> VM_PFNMAP restriction.<br /> <br /> Fix this by checking for vmalloc addresses and setting VM_MIXEDMAP<br /> in the VMA before mapping. This ensures safe mapping and avoids kernel<br /> crashes. The memory is still driver-allocated and cannot be accessed<br /> directly by userspace.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: Verify inode mode when loading from disk<br /> <br /> The inode mode loaded from corrupted disk can be invalid. Do like what<br /> commit 0a9e74051313 ("isofs: Verify inode mode when loading from disk")<br /> does.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntfs3: pretend $Extend records as regular files<br /> <br /> Since commit af153bb63a33 ("vfs: catch invalid modes in may_open()")<br /> requires any inode be one of S_IFDIR/S_IFLNK/S_IFREG/S_IFCHR/S_IFBLK/<br /> S_IFIFO/S_IFSOCK type, use S_IFREG for $Extend records.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: cdns3: gadget: Use-after-free during failed initialization and exit of cdnsp gadget<br /> <br /> In the __cdnsp_gadget_init() and cdnsp_gadget_exit() functions, the gadget<br /> structure (pdev-&gt;gadget) was freed before its endpoints.<br /> The endpoints are linked via the ep_list in the gadget structure.<br /> Freeing the gadget first leaves dangling pointers in the endpoint list.<br /> When the endpoints are subsequently freed, this results in a use-after-free.<br /> <br /> Fix:<br /> By separating the usb_del_gadget_udc() operation into distinct "del" and<br /> "put" steps, cdnsp_gadget_free_endpoints() can be executed prior to the<br /> final release of the gadget structure with usb_put_gadget().<br /> <br /> A patch similar to bb9c74a5bd14("usb: dwc3: gadget: Free gadget structure<br /> only after freeing endpoints").

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> 9p/trans_fd: p9_fd_request: kick rx thread if EPOLLIN<br /> <br /> p9_read_work() doesn&amp;#39;t set Rworksched and doesn&amp;#39;t do schedule_work(m-&gt;rq)<br /> if list_empty(&amp;m-&gt;req_list).<br /> <br /> However, if the pipe is full, we need to read more data and this used to<br /> work prior to commit aaec5a95d59615 ("pipe_read: don&amp;#39;t wake up the writer<br /> if the pipe is still full").<br /> <br /> p9_read_work() does p9_fd_read() -&gt; ... -&gt; anon_pipe_read() which (before<br /> the commit above) triggered the unnecessary wakeup. This wakeup calls<br /> p9_pollwake() which kicks p9_poll_workfn() -&gt; p9_poll_mux(), p9_poll_mux()<br /> will notice EPOLLIN and schedule_work(&amp;m-&gt;rq).<br /> <br /> This no longer happens after the optimization above, change p9_fd_request()<br /> to use p9_poll_mux() instead of only checking for EPOLLOUT.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> orangefs: fix xattr related buffer overflow...<br /> <br /> Willy Tarreau forwarded me a message from<br /> Disclosure with the following<br /> warning:<br /> <br /> &gt; The helper `xattr_key()` uses the pointer variable in the loop condition<br /> &gt; rather than dereferencing it. As `key` is incremented, it remains non-NULL<br /> &gt; (until it runs into unmapped memory), so the loop does not terminate on<br /> &gt; valid C strings and will walk memory indefinitely, consuming CPU or hanging<br /> &gt; the thread.<br /> <br /> I easily reproduced this with setfattr and getfattr, causing a kernel<br /> oops, hung user processes and corrupted orangefs files. Disclosure<br /> sent along a diff (not a patch) with a suggested fix, which I based<br /> this patch on.<br /> <br /> After xattr_key started working right, xfstest generic/069 exposed an<br /> xattr related memory leak that lead to OOM. xattr_key returns<br /> a hashed key. When adding xattrs to the orangefs xattr cache, orangefs<br /> used hash_add, a kernel hashing macro. hash_add also hashes the key using<br /> hash_log which resulted in additions to the xattr cache going to the wrong<br /> hash bucket. generic/069 tortures a single file and orangefs does a<br /> getattr for the xattr "security.capability" every time. Orangefs<br /> negative caches on xattrs which includes a kmalloc. Since adds to the<br /> xattr cache were going to the wrong bucket, every getattr for<br /> "security.capability" resulted in another kmalloc, none of which were<br /> ever freed.<br /> <br /> I changed the two uses of hash_add to hlist_add_head instead<br /> and the memory leak ceased and generic/069 quit throwing furniture.