Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, skmsg: fix verdict sk_data_ready racing with ktls rx<br /> <br /> sk_psock_strp_data_ready() already checks tls_sw_has_ctx_rx() and<br /> defers to psock-&gt;saved_data_ready when a TLS RX context is present,<br /> avoiding a conflict with the TLS strparser&amp;#39;s ownership of the receive<br /> queue (commit e91de6afa81c, "bpf: Fix running sk_skb program types<br /> with ktls").<br /> <br /> sk_psock_verdict_data_ready() has no equivalent guard. When a socket<br /> is inserted into a sockmap (BPF_SK_SKB_VERDICT) before TLS RX is<br /> configured, tls_sw_strparser_arm() saves sk_psock_verdict_data_ready<br /> as rx_ctx-&gt;saved_data_ready. On data arrival:<br /> <br /> tls_data_ready -&gt; tls_strp_data_ready -&gt; tls_rx_msg_ready<br /> -&gt; saved_data_ready() = sk_psock_verdict_data_ready()<br /> -&gt; tcp_read_skb() drains sk_receive_queue via __skb_unlink()<br /> without calling tcp_eat_skb(), so copied_seq is not advanced.<br /> <br /> tls_strp_msg_load() then finds tcp_inq() &gt;= full_len (stale), calls<br /> tcp_recv_skb() on the now-empty queue, hits WARN_ON_ONCE(!first), and<br /> returns with rx_ctx-&gt;strp.anchor.frag_list pointing at a psock-owned<br /> (potentially freed) skb. tls_decrypt_sg() subsequently walks that<br /> frag_list: use-after-free.<br /> <br /> Apply the same fix as sk_psock_strp_data_ready(): if a TLS RX context<br /> is present, call psock-&gt;saved_data_ready (sock_def_readable) to wake<br /> recv() waiters and return immediately, leaving the receive queue<br /> untouched. TLS retains sole ownership of the queue and decrypts the<br /> record normally through tls_sw_recvmsg().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix DATA decrypt vs splice() by copying data to buffer in recvmsg<br /> <br /> This improves the fix for CVE-2026-43500.<br /> <br /> Fix the pagecache corruption from in-place decryption of a DATA packet<br /> transmitted locally by splice() by getting rid of the packet sharing in the<br /> I/O thread and unconditionally extracting the packet content into a bounce<br /> buffer in which the buffer is decrypted. recvmsg() (or the kernel<br /> equivalent) then copies the data from the bounce buffer to the destination<br /> buffer. The sk_buff then remains unmodified.<br /> <br /> This has an additional advantage in that the packet is then arranged in the<br /> buffer with the correct alignment required for the crypto algorithms to<br /> process directly. The performance of the crypto does seem to be a little<br /> faster and, surprisingly, the unencrypted performance doesn&amp;#39;t seem to<br /> change much - possibly due to removing complexity from the I/O thread.<br /> <br /> Yet another advantage is that the I/O thread doesn&amp;#39;t have to copy packets<br /> which would slow down packet distribution, ACK generation, etc..<br /> <br /> The buffer belongs to the call and is allocated initially at 2K,<br /> sufficiently large to hold a whole jumbo subpacket, but the buffer will be<br /> increased in size if needed. However, to take this work, MSG_PEEK may<br /> cause a later packet to be decrypted into the buffer, in which case the<br /> earlier one will need re-decrypting for a subsequent recvmsg().<br /> <br /> Note that rx_pkt_offset may legitimately see 0 as a valid offset now, so<br /> switch to using USHRT_MAX to indicate an invalid offset.<br /> <br /> Note also that I would generally prefer to replace the buffers of the<br /> current sk_buff with a new kmalloc&amp;#39;d buffer of the right size, ditching the<br /> old data and frags as this makes the handling of MSG_PEEK easier and<br /> removes the re-decryption issue, but this looks like quite a complicated<br /> thing to achieve. skb_morph() looks half way to what I want, but I don&amp;#39;t<br /> want to have to allocate a new sk_buff.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: shaper: rework the VALID marking (again)<br /> <br /> Recent commit changed the semantics from NOT_VALID to VALID.<br /> I didn&amp;#39;t realize that the flags are not stored atomically<br /> with the entry in XArray. There&amp;#39;s still a race of reader<br /> observing a VALID mark for a slot, getting interrupted,<br /> writer replacing the entry with a different one, reader<br /> continuing, fetching the entry which is now a different<br /> pointer than the pointer for which VALID was meant.<br /> <br /> The biggest consequence of this is that we may see a UAF<br /> since net_shaper_rollback() assumed that entries without<br /> VALID can be freed without observing RCU.<br /> <br /> Looks like the XArray marks are buying us nothing at this<br /> point. Let&amp;#39;s convert the code to an explicit valid field.<br /> The smp_load_acquire() / smp_store_release() barriers are<br /> marginally cleaner.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Avoid NULL return from hist_field_name() on truncation<br /> <br /> hist_field_name() returns "" everywhere except the fully-qualified<br /> VAR_REF/EXPR case, where snprintf() truncation returns NULL early<br /> and bypasses the bottom NULL-&gt;"" guard. Callers don&amp;#39;t expect NULL:<br /> strcat(expr, hist_field_name(field, 0)) at trace_events_hist.c:1758<br /> and the strcmp() in the sort-key match loop at :4804 both deref it.<br /> <br /> system and event_name are bounded by MAX_EVENT_NAME_LEN, but the<br /> field name on a VAR_REF is kstrdup&amp;#39;d from a histogram variable<br /> name parsed out of the trigger string and has no length cap, so<br /> a long enough var name in a fully qualified reference can reach<br /> the truncation path.<br /> <br /> Keep the length check but leave field_name as "" on overflow.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: seq: Serialize UMP output teardown with event_input<br /> <br /> seq_ump_process_event() borrows client-&gt;out_rfile.output without<br /> synchronizing with the first-open and last-close transition in<br /> seq_ump_client_open() and seq_ump_client_close().<br /> <br /> The last output unuse can therefore drop opened[STR_OUT] to zero and<br /> release the rawmidi file while an in-flight event_input callback is still<br /> inside snd_rawmidi_kernel_write(). That leaves the rawmidi substream<br /> runtime exposed to teardown before the write path has taken its own<br /> buffer reference.<br /> <br /> Add a per-client rwlock for the event_input-visible output file. Publish<br /> a newly opened output file under the write side, and hold the read side<br /> from the output lookup through snd_rawmidi_kernel_write(). The last<br /> output close copies and clears the visible output file under the write<br /> side, then drops the lock and releases the saved rawmidi file. Use<br /> IRQ-safe rwlock guards because event_input can also be reached from<br /> atomic sequencer delivery.<br /> <br /> The buggy scenario involves two paths, with each column showing the<br /> order within that path:<br /> <br /> path A label: event_input path path B label: last unuse path<br /> 1. seq_ump_process_event() reads 1. seq_ump_client_close()<br /> client-&gt;out_rfile.output. drops opened[STR_OUT] to zero.<br /> 2. snd_rawmidi_kernel_write1() 2. snd_rawmidi_kernel_release()<br /> has not yet pinned runtime. closes the output file.<br /> 3. The writer continues using 3. close_substream() frees<br /> the borrowed substream. substream-&gt;runtime.<br /> <br /> This keeps the output substream and runtime alive for the full<br /> event_input write while keeping rawmidi release outside the rwlock.<br /> <br /> KASAN reproduced this as a slab-use-after-free in<br /> snd_rawmidi_kernel_write1(), with allocation through<br /> seq_ump_use()/snd_seq_port_connect() and free through<br /> seq_ump_unuse()/snd_seq_port_disconnect().<br /> <br /> <br /> Validation reproduced this kernel report:<br /> KASAN slab-use-after-free in snd_rawmidi_kernel_write1+0x9d/0x400<br /> RIP: 0033:0x7f5528af837f<br /> Read of size 8<br /> Call trace:<br /> dump_stack_lvl+0x73/0xb0 (?:?)<br /> print_report+0xd1/0x650 (?:?)<br /> srso_alias_return_thunk+0x5/0xfbef5 (?:?)<br /> __virt_addr_valid+0x1a7/0x340 (?:?)<br /> kasan_complete_mode_report_info+0x64/0x200 (?:?)<br /> kasan_report+0xf7/0x130 (?:?)<br /> snd_rawmidi_kernel_write1+0x9d/0x400 (?:?)<br /> __asan_load8+0x82/0xb0 (?:?)<br /> update_stack_state+0x1ef/0x2d0 (?:?)<br /> snd_rawmidi_kernel_write+0x1a/0x20 (?:?)<br /> seq_ump_process_event+0xd4/0x120 (sound/core/seq/seq_ump_client.c:82)<br /> __snd_seq_deliver_single_event+0x8a/0xe0 (?:?)<br /> snd_seq_deliver_from_ump+0x2b2/0xd60 (?:?)<br /> lock_acquire+0x14e/0x2e0 (?:?)<br /> find_held_lock+0x31/0x90 (?:?)<br /> snd_seq_port_use_ptr+0xa6/0xe0 (?:?)<br /> __kasan_check_write+0x18/0x20 (?:?)<br /> do_raw_read_unlock+0x32/0xa0 (?:?)<br /> _raw_read_unlock+0x26/0x50 (?:?)<br /> snd_seq_deliver_single_event+0x45c/0x4b0 (?:?)<br /> snd_seq_deliver_event+0x10d/0x1b0 (?:?)<br /> snd_seq_client_enqueue_event+0x192/0x240 (?:?)<br /> snd_seq_write+0x2cd/0x450 (?:?)<br /> apparmor_file_permission+0x20/0x30 (?:?)<br /> security_file_permission+0x51/0x60 (?:?)<br /> vfs_write+0x1ce/0x850 (?:?)<br /> __fget_files+0x12b/0x220 (?:?)<br /> lock_release+0xc8/0x2a0 (?:?)<br /> __rcu_read_unlock+0x74/0x2d0 (?:?)<br /> __fget_files+0x135/0x220 (?:?)<br /> ksys_write+0x15a/0x180 (?:?)<br /> rcu_is_watching+0x24/0x60 (?:?)<br /> __x64_sys_write+0x46/0x60 (?:?)<br /> x64_sys_call+0x7d/0x20d0 (?:?)<br /> do_syscall_64+0xc1/0x360 (arch/x86/entry/syscall_64.c:87)<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: sch_sfb: Replace direct dequeue call with peek and qdisc_dequeue_peeked<br /> <br /> When sfb has children (eg qfq qdisc) whose peek() callback is<br /> qdisc_peek_dequeued(), we could get a kernel panic. When the parent of such<br /> qdiscs (eg illustrated in patch #3 as tbf) wants to retrieve an skb from<br /> its child (sfb in this case), it will do the following:<br /> 1a. do a peek() - and when sensing there&amp;#39;s an skb the child can offer, then<br /> - the child in this case(sfb) calls its child&amp;#39;s (qfq) peek.<br /> qfq does the right thing and will return the gso_skb queue packet.<br /> Note: if there wasnt a gso_skb entry then qfq will store it there.<br /> 1b. invoke a dequeue() on the child (sfb). And herein lies the problem.<br /> - sfb will call the child&amp;#39;s dequeue() which will essentially just<br /> try to grab something of qfq&amp;#39;s queue.<br /> <br /> [ 127.594489][ T453] KASAN: null-ptr-deref in range [0x0000000000000048-0x000000000000004f]<br /> [ 127.594741][ T453] CPU: 2 UID: 0 PID: 453 Comm: ping Not tainted 7.1.0-rc1-00035-gac961974495b-dirty #793 PREEMPT(full)<br /> [ 127.595059][ T453] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011<br /> [ 127.595254][ T453] RIP: 0010:qfq_dequeue+0x35c/0x1650 [sch_qfq]<br /> [ 127.595461][ T453] Code: 00 fc ff df 80 3c 02 00 0f 85 17 0e 00 00 4c 8d 73 48 48 89 9d b8 02 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 ea 03 3c 02 00 0f 85 76 0c 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b<br /> [ 127.596081][ T453] RSP: 0018:ffff88810e5af440 EFLAGS: 00010216<br /> [ 127.596337][ T453] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: dffffc0000000000<br /> [ 127.596623][ T453] RDX: 0000000000000009 RSI: 0000001880000000 RDI: ffff888104fd82b0<br /> [ 127.596917][ T453] RBP: ffff888104fd8000 R08: ffff888104fd8280 R09: 1ffff110211893a3<br /> [ 127.597165][ T453] R10: 1ffff110211893a6 R11: 1ffff110211893a7 R12: 0000001880000000<br /> [ 127.597404][ T453] R13: ffff888104fd82b8 R14: 0000000000000048 R15: 0000000040000000<br /> [ 127.597644][ T453] FS: 00007fc380cbfc40(0000) GS:ffff88816f2a8000(0000) knlGS:0000000000000000<br /> [ 127.597956][ T453] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 127.598160][ T453] CR2: 00005610aa9890a8 CR3: 000000010369e000 CR4: 0000000000750ef0<br /> [ 127.598390][ T453] PKRU: 55555554<br /> [ 127.598509][ T453] Call Trace:<br /> [ 127.598629][ T453] <br /> [ 127.598718][ T453] ? mark_held_locks+0x40/0x70<br /> [ 127.598890][ T453] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 127.599053][ T453] sfb_dequeue+0x88/0x4d0<br /> [ 127.599174][ T453] ? ktime_get+0x137/0x230<br /> [ 127.599328][ T453] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 127.599480][ T453] ? qdisc_peek_dequeued+0x7b/0x350 [sch_qfq]<br /> [ 127.599670][ T453] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 127.599831][ T453] tbf_dequeue+0x6b1/0x1098 [sch_tbf]<br /> [ 127.599988][ T453] __qdisc_run+0x169/0x1900<br /> <br /> The right thing to do in #1b is to grab the skb off gso_skb queue.<br /> This patchset fixes that issue by changing #1b to use qdisc_dequeue_peeked()<br /> method instead.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: button: Fix ACPI GPE handler leak during removal<br /> <br /> Commit a7e23ec17fee ("ACPI: button: Install notifier for system events<br /> as well") changed the ACPI notify handler type for ACPI buttons to<br /> ACPI_ALL_NOTIFY, but it forgot to update acpi_button_remove() to reflect<br /> that change. This leads to leaking the notify handler past driver<br /> removal, which may cause a kernel crash to occur if ACPI notify on<br /> the given device is triggered after removing the driver, and causes a<br /> subsequent probe of the given device with the same driver to fail.<br /> <br /> Address this by updating the acpi_remove_notify_handler() call in<br /> acpi_button_remove() as appropriate.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: usbtouchscreen - clamp NEXIO data_len/x_len to URB buffer size<br /> <br /> nexio_read_data() pulls data_len and x_len from a packed __be16 header<br /> in the device&amp;#39;s interrupt packet and then walks packet-&gt;data[0..x_len)<br /> and packet-&gt;data[x_len..data_len) comparing each byte against a<br /> threshold.<br /> <br /> Both fields are 16-bit on the wire (max 65535). The existing<br /> adjustments shave at most 0x100 / 0x80 off, so the loop bound can still<br /> reach roughly 0xfeff. The URB transfer buffer for NEXIO is rept_size<br /> (1024) bytes from usb_alloc_coherent(), with the first 7 occupied by the<br /> packed header — so packet-&gt;data[] has 1017 valid bytes. read_data()<br /> callbacks are not given urb-&gt;actual_length, and nothing else bounds the<br /> walk.<br /> <br /> A device that lies about its length can get a ~64 KiB out-of-bounds read<br /> past the coherent DMA allocation. The first index whose byte exceeds<br /> NEXIO_THRESHOLD lands in begin_x / begin_y and from there into the<br /> reported touch coordinates, so adjacent kernel memory contents leak to<br /> userspace as ABS_X / ABS_Y events. Far enough out, the read can also<br /> hit an unmapped page and fault.<br /> <br /> Fix this all by clamping data_len to the buffer&amp;#39;s data[] capacity and<br /> x_len to data_len.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> security/keys: fix missed RCU read section on lookup<br /> <br /> Nicholas Carlini reports that the keyring code calls assoc_array_find()<br /> in find_key_to_update() without holding the RCU read lock, while the<br /> assoc_array_gc() code really is designed around removing the node from<br /> the tree and then freeing it after an RCU grace-period.<br /> <br /> The regular key handling doesn&amp;#39;t see this because holding the keyring<br /> semaphore hides any lifetime issues, but the persistent key handling<br /> uses a different model.<br /> <br /> Instead of extending the keyring locking, just do the simple RCU locking<br /> that the assoc_array was designed for.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix durable reconnect error path file lifetime<br /> <br /> After a durable reconnect succeeds, ksmbd_reopen_durable_fd() republishes<br /> the same ksmbd_file into the session volatile-id table. If smb2_open()<br /> then takes a later error path, cleanup first calls ksmbd_fd_put(work, fp)<br /> and then unconditionally calls ksmbd_put_durable_fd(dh_info.fp).<br /> <br /> In this case fp and dh_info.fp are the same object. The first put drops the<br /> reconnect lookup reference, but the final durable put can run<br /> __ksmbd_close_fd(NULL, fp). Because the final close is not session-aware,<br /> it can free the file object without removing the volatile-id entry that was<br /> just published into the session table.<br /> <br /> Use the session-aware put for the final reconnect drop when the reconnect<br /> had already succeeded and the error path is cleaning up the republished<br /> file. Earlier reconnect failures, before fp is assigned to dh_info.fp, keep<br /> using the durable-only put path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-mq: pop cached request if it is usable<br /> <br /> When submitting a bio to blk-mq, if the task should sleep after peeking<br /> a cached request, but before it pops it, the plug flushes and calls<br /> blk_mq_free_plug_rqs, freeing the cached_rqs. This creates a<br /> use-after-free bug. Fix this by popping the cached request before any<br /> possible blocking calls if it is suitable for use.<br /> <br /> Popping this request first holds a queue reference, so avoid any<br /> serialization races with queue freezes and can safely proceed with<br /> dispatching that request to the driver. This potentially increases a<br /> timing window from when a driver wants to freeze its queue to when<br /> requests stop being dispatched. That scenario is off the fast path<br /> though, and drivers need to appropriately handle requests during a<br /> freeze request anyway.<br /> <br /> The downside is the popped element needs to be individually freed when<br /> we performed a bio plug merge. The cached request would have had to be<br /> freed later anyway, but this patch does it inline with building the plug<br /> list instead of after flushing it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mana: validate rx_req_idx to prevent out-of-bounds array access<br /> <br /> In mana_hwc_rx_event_handler(), rx_req_idx is derived from<br /> sge-&gt;address in DMA-coherent memory. In Confidential VMs<br /> (SEV-SNP/TDX), this memory is shared unencrypted and HW can modify<br /> WQE contents at any time. No bounds check exists on rx_req_idx,<br /> which can lead to an out-of-bounds access into reqs[].<br /> <br /> Add bounds check on rx_req_idx in mana_hwc_rx_event_handler() before<br /> using it to index the reqs[] array.