Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix race condition in kprobe initialization causing NULL pointer dereference<br /> <br /> There is a critical race condition in kprobe initialization that can lead to<br /> NULL pointer dereference and kernel crash.<br /> <br /> [1135630.084782] Unable to handle kernel paging request at virtual address 0000710a04630000<br /> ...<br /> [1135630.260314] pstate: 404003c9 (nZcv DAIF +PAN -UAO)<br /> [1135630.269239] pc : kprobe_perf_func+0x30/0x260<br /> [1135630.277643] lr : kprobe_dispatcher+0x44/0x60<br /> [1135630.286041] sp : ffffaeff4977fa40<br /> [1135630.293441] x29: ffffaeff4977fa40 x28: ffffaf015340e400<br /> [1135630.302837] x27: 0000000000000000 x26: 0000000000000000<br /> [1135630.312257] x25: ffffaf029ed108a8 x24: ffffaf015340e528<br /> [1135630.321705] x23: ffffaeff4977fc50 x22: ffffaeff4977fc50<br /> [1135630.331154] x21: 0000000000000000 x20: ffffaeff4977fc50<br /> [1135630.340586] x19: ffffaf015340e400 x18: 0000000000000000<br /> [1135630.349985] x17: 0000000000000000 x16: 0000000000000000<br /> [1135630.359285] x15: 0000000000000000 x14: 0000000000000000<br /> [1135630.368445] x13: 0000000000000000 x12: 0000000000000000<br /> [1135630.377473] x11: 0000000000000000 x10: 0000000000000000<br /> [1135630.386411] x9 : 0000000000000000 x8 : 0000000000000000<br /> [1135630.395252] x7 : 0000000000000000 x6 : 0000000000000000<br /> [1135630.403963] x5 : 0000000000000000 x4 : 0000000000000000<br /> [1135630.412545] x3 : 0000710a04630000 x2 : 0000000000000006<br /> [1135630.421021] x1 : ffffaeff4977fc50 x0 : 0000710a04630000<br /> [1135630.429410] Call trace:<br /> [1135630.434828] kprobe_perf_func+0x30/0x260<br /> [1135630.441661] kprobe_dispatcher+0x44/0x60<br /> [1135630.448396] aggr_pre_handler+0x70/0xc8<br /> [1135630.454959] kprobe_breakpoint_handler+0x140/0x1e0<br /> [1135630.462435] brk_handler+0xbc/0xd8<br /> [1135630.468437] do_debug_exception+0x84/0x138<br /> [1135630.475074] el1_dbg+0x18/0x8c<br /> [1135630.480582] security_file_permission+0x0/0xd0<br /> [1135630.487426] vfs_write+0x70/0x1c0<br /> [1135630.493059] ksys_write+0x5c/0xc8<br /> [1135630.498638] __arm64_sys_write+0x24/0x30<br /> [1135630.504821] el0_svc_common+0x78/0x130<br /> [1135630.510838] el0_svc_handler+0x38/0x78<br /> [1135630.516834] el0_svc+0x8/0x1b0<br /> <br /> kernel/trace/trace_kprobe.c: 1308<br /> 0xffff3df8995039ec : ldr x21, [x24,#120]<br /> include/linux/compiler.h: 294<br /> 0xffff3df8995039f0 : ldr x1, [x21,x0]<br /> <br /> kernel/trace/trace_kprobe.c<br /> 1308: head = this_cpu_ptr(call-&gt;perf_events);<br /> 1309: if (hlist_empty(head))<br /> 1310: return 0;<br /> <br /> crash&gt; struct trace_event_call -o<br /> struct trace_event_call {<br /> ...<br /> [120] struct hlist_head *perf_events; //(call-&gt;perf_event)<br /> ...<br /> }<br /> <br /> crash&gt; struct trace_event_call ffffaf015340e528<br /> struct trace_event_call {<br /> ...<br /> perf_events = 0xffff0ad5fa89f088, //this value is correct, but x21 = 0<br /> ...<br /> }<br /> <br /> Race Condition Analysis:<br /> <br /> The race occurs between kprobe activation and perf_events initialization:<br /> <br /> CPU0 CPU1<br /> ==== ====<br /> perf_kprobe_init<br /> perf_trace_event_init<br /> tp_event-&gt;perf_events = list;(1)<br /> tp_event-&gt;class-&gt;reg (2)← KPROBE ACTIVE<br /> Debug exception triggers<br /> ...<br /> kprobe_dispatcher<br /> kprobe_perf_func (tk-&gt;tp.flags &amp; TP_FLAG_PROFILE)<br /> head = this_cpu_ptr(call-&gt;perf_events)(3)<br /> (perf_events is still NULL)<br /> <br /> Problem:<br /> 1. CPU0 executes (1) assigning tp_event-&gt;perf_events = list<br /> 2. CPU0 executes (2) enabling kprobe functionality via class-&gt;reg()<br /> 3. CPU1 triggers and reaches kprobe_dispatcher<br /> 4. CPU1 checks TP_FLAG_PROFILE - condition passes (step 2 completed)<br /> 5. CPU1 calls kprobe_perf_func() and crashes at (3) because<br /> call-&gt;perf_events is still NULL<br /> <br /> CPU1 sees that kprobe functionality is enabled but does not see that<br /> perf_events has been assigned.<br /> <br /> Add pairing read an<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: nfc: nci: Add parameter validation for packet data<br /> <br /> Syzbot reported an uninitialized value bug in nci_init_req, which was<br /> introduced by commit 5aca7966d2a7 ("Merge tag<br /> &amp;#39;perf-tools-fixes-for-v6.17-2025-09-16&amp;#39; of<br /> git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools").<br /> <br /> This bug arises due to very limited and poor input validation<br /> that was done at nic_valid_size(). This validation only<br /> validates the skb-&gt;len (directly reflects size provided at the<br /> userspace interface) with the length provided in the buffer<br /> itself (interpreted as NCI_HEADER). This leads to the processing<br /> of memory content at the address assuming the correct layout<br /> per what opcode requires there. This leads to the accesses to<br /> buffer of `skb_buff-&gt;data` which is not assigned anything yet.<br /> <br /> Following the same silent drop of packets of invalid sizes at<br /> `nic_valid_size()`, add validation of the data in the respective<br /> handlers and return error values in case of failure. Release<br /> the skb if error values are returned from handlers in<br /> `nci_nft_packet` and effectively do a silent drop<br /> <br /> Possible TODO: because we silently drop the packets, the<br /> call to `nci_request` will be waiting for completion of request<br /> and will face timeouts. These timeouts can get excessively logged<br /> in the dmesg. A proper handling of them may require to export<br /> `nci_request_cancel` (or propagate error handling from the<br /> nft packets handlers).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: udf: fix OOB read in lengthAllocDescs handling<br /> <br /> When parsing Allocation Extent Descriptor, lengthAllocDescs comes from<br /> on-disk data and must be validated against the block size. Crafted or<br /> corrupted images may set lengthAllocDescs so that the total descriptor<br /> length (sizeof(allocExtDesc) + lengthAllocDescs) exceeds the buffer,<br /> leading udf_update_tag() to call crc_itu_t() on out-of-bounds memory and<br /> trigger a KASAN use-after-free read.<br /> <br /> BUG: KASAN: use-after-free in crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60<br /> Read of size 1 at addr ffff888041e7d000 by task syz-executor317/5309<br /> <br /> CPU: 0 UID: 0 PID: 5309 Comm: syz-executor317 Not tainted 6.12.0-rc4-syzkaller-00261-g850925a8133c #0<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:377 [inline]<br /> print_report+0x169/0x550 mm/kasan/report.c:488<br /> kasan_report+0x143/0x180 mm/kasan/report.c:601<br /> crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60<br /> udf_update_tag+0x70/0x6a0 fs/udf/misc.c:261<br /> udf_write_aext+0x4d8/0x7b0 fs/udf/inode.c:2179<br /> extent_trunc+0x2f7/0x4a0 fs/udf/truncate.c:46<br /> udf_truncate_tail_extent+0x527/0x7e0 fs/udf/truncate.c:106<br /> udf_release_file+0xc1/0x120 fs/udf/file.c:185<br /> __fput+0x23f/0x880 fs/file_table.c:431<br /> task_work_run+0x24f/0x310 kernel/task_work.c:239<br /> exit_task_work include/linux/task_work.h:43 [inline]<br /> do_exit+0xa2f/0x28e0 kernel/exit.c:939<br /> do_group_exit+0x207/0x2c0 kernel/exit.c:1088<br /> __do_sys_exit_group kernel/exit.c:1099 [inline]<br /> __se_sys_exit_group kernel/exit.c:1097 [inline]<br /> __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097<br /> x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> <br /> Validate the computed total length against epos-&gt;bh-&gt;b_size.<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 /> ASoC: codecs: wcd937x: set the comp soundwire port correctly<br /> <br /> For some reason we endup with setting soundwire port for<br /> HPHL_COMP and HPHR_COMP as zero, this can potentially result<br /> in a memory corruption due to accessing and setting -1 th element of<br /> port_map array.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/zcrx: fix overshooting recv limit<br /> <br /> It&amp;#39;s reported that sometimes a zcrx request can receive more than was<br /> requested. It&amp;#39;s caused by io_zcrx_recv_skb() adjusting desc-&gt;count for<br /> all received buffers including frag lists, but then doing recursive<br /> calls to process frag list skbs, which leads to desc-&gt;count double<br /> accounting and underflow.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/waitid: always prune wait queue entry in io_waitid_wait()<br /> <br /> For a successful return, always remove our entry from the wait queue<br /> entry list. Previously this was skipped if a cancelation was in<br /> progress, but this can race with another invocation of the wait queue<br /> entry callback.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> uio_hv_generic: Let userspace take care of interrupt mask<br /> <br /> Remove the logic to set interrupt mask by default in uio_hv_generic<br /> driver as the interrupt mask value is supposed to be controlled<br /> completely by the user space. If the mask bit gets changed<br /> by the driver, concurrently with user mode operating on the ring,<br /> the mask bit may be set when it is supposed to be clear, and the<br /> user-mode driver will miss an interrupt which will cause a hang.<br /> <br /> For eg- when the driver sets inbound ring buffer interrupt mask to 1,<br /> the host does not interrupt the guest on the UIO VMBus channel.<br /> However, setting the mask does not prevent the host from putting a<br /> message in the inbound ring buffer. So let’s assume that happens,<br /> the host puts a message into the ring buffer but does not interrupt.<br /> <br /> Subsequently, the user space code in the guest sets the inbound ring<br /> buffer interrupt mask to 0, saying “Hey, I’m ready for interrupts”.<br /> User space code then calls pread() to wait for an interrupt.<br /> Then one of two things happens:<br /> <br /> * The host never sends another message. So the pread() waits forever.<br /> * The host does send another message. But because there’s already a<br /> message in the ring buffer, it doesn’t generate an interrupt.<br /> This is the correct behavior, because the host should only send an<br /> interrupt when the inbound ring buffer transitions from empty to<br /> not-empty. Adding an additional message to a ring buffer that is not<br /> empty is not supposed to generate an interrupt on the guest.<br /> Since the guest is waiting in pread() and not removing messages from<br /> the ring buffer, the pread() waits forever.<br /> <br /> This could be easily reproduced in hv_fcopy_uio_daemon if we delay<br /> setting interrupt mask to 0.<br /> <br /> Similarly if hv_uio_channel_cb() sets the interrupt_mask to 1,<br /> there’s a race condition. Once user space empties the inbound ring<br /> buffer, but before user space sets interrupt_mask to 0, the host could<br /> put another message in the ring buffer but it wouldn’t interrupt.<br /> Then the next pread() would hang.<br /> <br /> Fix these by removing all instances where interrupt_mask is changed,<br /> while keeping the one in set_event() unchanged to enable userspace<br /> control the interrupt mask by writing 0/1 to /dev/uioX.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: endpoint: pci-epf-test: Add NULL check for DMA channels before release<br /> <br /> The fields dma_chan_tx and dma_chan_rx of the struct pci_epf_test can be<br /> NULL even after EPF initialization. Then it is prudent to check that<br /> they have non-NULL values before releasing the channels. Add the checks<br /> in pci_epf_test_clean_dma_chan().<br /> <br /> Without the checks, NULL pointer dereferences happen and they can lead<br /> to a kernel panic in some cases:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050<br /> Call trace:<br /> dma_release_channel+0x2c/0x120 (P)<br /> pci_epf_test_epc_deinit+0x94/0xc0 [pci_epf_test]<br /> pci_epc_deinit_notify+0x74/0xc0<br /> tegra_pcie_ep_pex_rst_irq+0x250/0x5d8<br /> irq_thread_fn+0x34/0xb8<br /> irq_thread+0x18c/0x2e8<br /> kthread+0x14c/0x210<br /> ret_from_fork+0x10/0x20<br /> <br /> [mani: trimmed the stack trace]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> remoteproc: pru: Fix potential NULL pointer dereference in pru_rproc_set_ctable()<br /> <br /> pru_rproc_set_ctable() accessed rproc-&gt;priv before the IS_ERR_OR_NULL<br /> check, which could lead to a null pointer dereference. Move the pru<br /> assignment, ensuring we never dereference a NULL rproc pointer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI/AER: Avoid NULL pointer dereference in aer_ratelimit()<br /> <br /> When platform firmware supplies error information to the OS, e.g., via the<br /> ACPI APEI GHES mechanism, it may identify an error source device that<br /> doesn&amp;#39;t advertise an AER Capability and therefore dev-&gt;aer_info, which<br /> contains AER stats and ratelimiting data, is NULL.<br /> <br /> pci_dev_aer_stats_incr() already checks dev-&gt;aer_info for NULL, but<br /> aer_ratelimit() did not, leading to NULL pointer dereferences like this one<br /> from the URL below:<br /> <br /> {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 0<br /> {1}[Hardware Error]: event severity: corrected<br /> {1}[Hardware Error]: device_id: 0000:00:00.0<br /> {1}[Hardware Error]: vendor_id: 0x8086, device_id: 0x2020<br /> {1}[Hardware Error]: aer_cor_status: 0x00001000, aer_cor_mask: 0x00002000<br /> BUG: kernel NULL pointer dereference, address: 0000000000000264<br /> RIP: 0010:___ratelimit+0xc/0x1b0<br /> pci_print_aer+0x141/0x360<br /> aer_recover_work_func+0xb5/0x130<br /> <br /> [8086:2020] is an Intel "Sky Lake-E DMI3 Registers" device that claims to<br /> be a Root Port but does not advertise an AER Capability.<br /> <br /> Add a NULL check in aer_ratelimit() to avoid the NULL pointer dereference.<br /> Note that this also prevents ratelimiting these events from GHES.<br /> <br /> [bhelgaas: add crash details to commit log]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: uinput - zero-initialize uinput_ff_upload_compat to avoid info leak<br /> <br /> Struct ff_effect_compat is embedded twice inside<br /> uinput_ff_upload_compat, contains internal padding. In particular, there<br /> is a hole after struct ff_replay to satisfy alignment requirements for<br /> the following union member. Without clearing the structure,<br /> copy_to_user() may leak stack data to userspace.<br /> <br /> Initialize ff_up_compat to zero before filling valid fields.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: fix possible map leak in fastrpc_put_args<br /> <br /> copy_to_user() failure would cause an early return without cleaning up<br /> the fdlist, which has been updated by the DSP. This could lead to map<br /> leak. Fix this by redirecting to a cleanup path on failure, ensuring<br /> that all mapped buffers are properly released before returning.