Vulnerabilidades

*** 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.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exfat: validate cluster allocation bits of the allocation bitmap<br /> <br /> syzbot created an exfat image with cluster bits not set for the allocation<br /> bitmap. exfat-fs reads and uses the allocation bitmap without checking<br /> this. The problem is that if the start cluster of the allocation bitmap<br /> is 6, cluster 6 can be allocated when creating a directory with mkdir.<br /> exfat zeros out this cluster in exfat_mkdir, which can delete existing<br /> entries. This can reallocate the allocated entries. In addition,<br /> the allocation bitmap is also zeroed out, so cluster 6 can be reallocated.<br /> This patch adds exfat_test_bitmap_range to validate that clusters used for<br /> the allocation bitmap are correctly marked as in-use.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gve: Implement gettimex64 with -EOPNOTSUPP<br /> <br /> gve implemented a ptp_clock for sole use of do_aux_work at this time.<br /> ptp_clock_gettime() and ptp_sys_offset() assume every ptp_clock has<br /> implemented either gettimex64 or gettime64. Stub gettimex64 and return<br /> -EOPNOTSUPP to prevent NULL dereferencing.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_event: validate skb length for unknown CC opcode<br /> <br /> In hci_cmd_complete_evt(), if the command complete event has an unknown<br /> opcode, we assume the first byte of the remaining skb-&gt;data contains the<br /> return status. However, parameter data has previously been pulled in<br /> hci_event_func(), which may leave the skb empty. If so, using skb-&gt;data[0]<br /> for the return status uses un-init memory.<br /> <br /> The fix is to check skb-&gt;len before using skb-&gt;data.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: videobuf2: forbid remove_bufs when legacy fileio is active<br /> <br /> vb2_ioctl_remove_bufs() call manipulates queue internal buffer list,<br /> potentially overwriting some pointers used by the legacy fileio access<br /> mode. Forbid that ioctl when fileio is active to protect internal queue<br /> state between subsequent read/write calls.