Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: isotp: fix tx.buf use-after-free in isotp_sendmsg()<br /> <br /> isotp_sendmsg() uses only cmpxchg() on so-&gt;tx.state to serialize access<br /> to so-&gt;tx.buf. isotp_release() waits for ISOTP_IDLE via<br /> wait_event_interruptible() and then calls kfree(so-&gt;tx.buf).<br /> <br /> If a signal interrupts the wait_event_interruptible() inside close()<br /> while tx.state is ISOTP_SENDING, the loop exits early and release<br /> proceeds to force ISOTP_SHUTDOWN and continues to kfree(so-&gt;tx.buf)<br /> while sendmsg may still be reading so-&gt;tx.buf for the final CAN frame<br /> in isotp_fill_dataframe().<br /> <br /> The so-&gt;tx.buf can be allocated once when the standard tx.buf length needs<br /> to be extended. Move the kfree() of this potentially extended tx.buf to<br /> sk_destruct time when either isotp_sendmsg() and isotp_release() are done.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: sma1307: fix double free of devm_kzalloc() memory<br /> <br /> A previous change added NULL checks and cleanup for allocation<br /> failures in sma1307_setting_loaded().<br /> <br /> However, the cleanup for mode_set entries is wrong. Those entries are<br /> allocated with devm_kzalloc(), so they are device-managed resources and<br /> must not be freed with kfree(). Manually freeing them in the error path<br /> can lead to a double free when devres later releases the same memory.<br /> <br /> Drop the manual kfree() loop and let devres handle the cleanup.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: do not expire session on binding failure<br /> <br /> When a multichannel session binding request fails (e.g. wrong password),<br /> the error path unconditionally sets sess-&gt;state = SMB2_SESSION_EXPIRED.<br /> However, during binding, sess points to the target session looked up via<br /> ksmbd_session_lookup_slowpath() -- which belongs to another connection&amp;#39;s<br /> user. This allows a remote attacker to invalidate any active session by<br /> simply sending a binding request with a wrong password (DoS).<br /> <br /> Fix this by skipping session expiration when the failed request was<br /> a binding attempt, since the session does not belong to the current<br /> connection. The reference taken by ksmbd_session_lookup_slowpath() is<br /> still correctly released via ksmbd_user_session_put().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix memory leaks and NULL deref in smb2_lock()<br /> <br /> smb2_lock() has three error handling issues after list_del() detaches<br /> smb_lock from lock_list at no_check_cl:<br /> <br /> 1) If vfs_lock_file() returns an unexpected error in the non-UNLOCK<br /> path, goto out leaks smb_lock and its flock because the out:<br /> handler only iterates lock_list and rollback_list, neither of<br /> which contains the detached smb_lock.<br /> <br /> 2) If vfs_lock_file() returns -ENOENT in the UNLOCK path, goto out<br /> leaks smb_lock and flock for the same reason. The error code<br /> returned to the dispatcher is also stale.<br /> <br /> 3) In the rollback path, smb_flock_init() can return NULL on<br /> allocation failure. The result is dereferenced unconditionally,<br /> causing a kernel NULL pointer dereference. Add a NULL check to<br /> prevent the crash and clean up the bookkeeping; the VFS lock<br /> itself cannot be rolled back without the allocation and will be<br /> released at file or connection teardown.<br /> <br /> Fix cases 1 and 2 by hoisting the locks_free_lock()/kfree() to before<br /> the if(!rc) check in the UNLOCK branch so all exit paths share one<br /> free site, and by freeing smb_lock and flock before goto out in the<br /> non-UNLOCK branch. Propagate the correct error code in both cases.<br /> Fix case 3 by wrapping the VFS unlock in an if(rlock) guard and adding<br /> a NULL check for locks_free_lock(rlock) in the shared cleanup.<br /> <br /> Found via call-graph analysis using sqry.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: replace hardcoded hdr2_len with offsetof() in smb2_calc_max_out_buf_len()<br /> <br /> After this commit (e2b76ab8b5c9 "ksmbd: add support for read compound"),<br /> response buffer management was changed to use dynamic iov array.<br /> In the new design, smb2_calc_max_out_buf_len() expects the second<br /> argument (hdr2_len) to be the offset of -&gt;Buffer field in the<br /> response structure, not a hardcoded magic number.<br /> Fix the remaining call sites to use the correct offsetof() value.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: always keep track of remap prev/next<br /> <br /> During 3D workload, user is reporting hitting:<br /> <br /> [ 413.361679] WARNING: drivers/gpu/drm/xe/xe_vm.c:1217 at vm_bind_ioctl_ops_unwind+0x1e2/0x2e0 [xe], CPU#7: vkd3d_queue/9925<br /> [ 413.361944] CPU: 7 UID: 1000 PID: 9925 Comm: vkd3d_queue Kdump: loaded Not tainted 7.0.0-070000rc3-generic #202603090038 PREEMPT(lazy)<br /> [ 413.361949] RIP: 0010:vm_bind_ioctl_ops_unwind+0x1e2/0x2e0 [xe]<br /> [ 413.362074] RSP: 0018:ffffd4c25c3df930 EFLAGS: 00010282<br /> [ 413.362077] RAX: 0000000000000000 RBX: ffff8f3ee817ed10 RCX: 0000000000000000<br /> [ 413.362078] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> [ 413.362079] RBP: ffffd4c25c3df980 R08: 0000000000000000 R09: 0000000000000000<br /> [ 413.362081] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8f41fbf99380<br /> [ 413.362082] R13: ffff8f3ee817e968 R14: 00000000ffffffef R15: ffff8f43d00bd380<br /> [ 413.362083] FS: 00000001040ff6c0(0000) GS:ffff8f4696d89000(0000) knlGS:00000000330b0000<br /> [ 413.362085] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033<br /> [ 413.362086] CR2: 00007ddfc4747000 CR3: 00000002e6262005 CR4: 0000000000f72ef0<br /> [ 413.362088] PKRU: 55555554<br /> [ 413.362089] Call Trace:<br /> [ 413.362092] <br /> [ 413.362096] xe_vm_bind_ioctl+0xa9a/0xc60 [xe]<br /> <br /> Which seems to hint that the vma we are re-inserting for the ops unwind<br /> is either invalid or overlapping with something already inserted in the<br /> vm. It shouldn&amp;#39;t be invalid since this is a re-insertion, so must have<br /> worked before. Leaving the likely culprit as something already placed<br /> where we want to insert the vma.<br /> <br /> Following from that, for the case where we do something like a rebind in<br /> the middle of a vma, and one or both mapped ends are already compatible,<br /> we skip doing the rebind of those vma and set next/prev to NULL. As well<br /> as then adjust the original unmap va range, to avoid unmapping the ends.<br /> However, if we trigger the unwind path, we end up with three va, with<br /> the two ends never being removed and the original va range in the middle<br /> still being the shrunken size.<br /> <br /> If this occurs, one failure mode is when another unwind op needs to<br /> interact with that range, which can happen with a vector of binds. For<br /> example, if we need to re-insert something in place of the original va.<br /> In this case the va is still the shrunken version, so when removing it<br /> and then doing a re-insert it can overlap with the ends, which were<br /> never removed, triggering a warning like above, plus leaving the vm in a<br /> bad state.<br /> <br /> With that, we need two things here:<br /> <br /> 1) Stop nuking the prev/next tracking for the skip cases. Instead<br /> relying on checking for skip prev/next, where needed. That way on the<br /> unwind path, we now correctly remove both ends.<br /> <br /> 2) Undo the unmap va shrinkage, on the unwind path. With the two ends<br /> now removed the unmap va should expand back to the original size again,<br /> before re-insertion.<br /> <br /> v2:<br /> - Update the explanation in the commit message, based on an actual IGT of<br /> triggering this issue, rather than conjecture.<br /> - Also undo the unmap shrinkage, for the skip case. With the two ends<br /> now removed, the original unmap va range should expand back to the<br /> original range.<br /> v3:<br /> - Track the old start/range separately. vma_size/start() uses the va<br /> info directly.<br /> <br /> (cherry picked from commit aec6969f75afbf4e01fd5fb5850ed3e9c27043ac)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio/pci: Fix double free in dma-buf feature<br /> <br /> The error path through vfio_pci_core_feature_dma_buf() ignores its<br /> own advice to only use dma_buf_put() after dma_buf_export(), instead<br /> falling through the entire unwind chain. In the unlikely event that<br /> we encounter file descriptor exhaustion, this can result in an<br /> unbalanced refcount on the vfio device and double free of allocated<br /> objects.<br /> <br /> Avoid this by moving the "put" directly into the error path and return<br /> the errno rather than entering the unwind chain.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio_net: Fix UAF on dst_ops when IFF_XMIT_DST_RELEASE is cleared and napi_tx is false<br /> <br /> A UAF issue occurs when the virtio_net driver is configured with napi_tx=N<br /> and the device&amp;#39;s IFF_XMIT_DST_RELEASE flag is cleared<br /> (e.g., during the configuration of tc route filter rules).<br /> <br /> When IFF_XMIT_DST_RELEASE is removed from the net_device, the network stack<br /> expects the driver to hold the reference to skb-&gt;dst until the packet<br /> is fully transmitted and freed. In virtio_net with napi_tx=N,<br /> skbs may remain in the virtio transmit ring for an extended period.<br /> <br /> If the network namespace is destroyed while these skbs are still pending,<br /> the corresponding dst_ops structure has freed. When a subsequent packet<br /> is transmitted, free_old_xmit() is triggered to clean up old skbs.<br /> It then calls dst_release() on the skb associated with the stale dst_entry.<br /> Since the dst_ops (referenced by the dst_entry) has already been freed,<br /> a UAF kernel paging request occurs.<br /> <br /> fix it by adds skb_dst_drop(skb) in start_xmit to explicitly release<br /> the dst reference before the skb is queued in virtio_net.<br /> <br /> Call Trace:<br /> Unable to handle kernel paging request at virtual address ffff80007e150000<br /> CPU: 2 UID: 0 PID: 6236 Comm: ping Kdump: loaded Not tainted 7.0.0-rc1+ #6 PREEMPT<br /> ...<br /> percpu_counter_add_batch+0x3c/0x158 lib/percpu_counter.c:98 (P)<br /> dst_release+0xe0/0x110 net/core/dst.c:177<br /> skb_release_head_state+0xe8/0x108 net/core/skbuff.c:1177<br /> sk_skb_reason_drop+0x54/0x2d8 net/core/skbuff.c:1255<br /> dev_kfree_skb_any_reason+0x64/0x78 net/core/dev.c:3469<br /> napi_consume_skb+0x1c4/0x3a0 net/core/skbuff.c:1527<br /> __free_old_xmit+0x164/0x230 drivers/net/virtio_net.c:611 [virtio_net]<br /> free_old_xmit drivers/net/virtio_net.c:1081 [virtio_net]<br /> start_xmit+0x7c/0x530 drivers/net/virtio_net.c:3329 [virtio_net]<br /> ...<br /> <br /> Reproduction Steps:<br /> NETDEV="enp3s0"<br /> <br /> config_qdisc_route_filter() {<br /> tc qdisc del dev $NETDEV root<br /> tc qdisc add dev $NETDEV root handle 1: prio<br /> tc filter add dev $NETDEV parent 1:0 \<br /> protocol ip prio 100 route to 100 flowid 1:1<br /> ip route add 192.168.1.100/32 dev $NETDEV realm 100<br /> }<br /> <br /> test_ns() {<br /> ip netns add testns<br /> ip link set $NETDEV netns testns<br /> ip netns exec testns ifconfig $NETDEV 10.0.32.46/24<br /> ip netns exec testns ping -c 1 10.0.32.1<br /> ip netns del testns<br /> }<br /> <br /> config_qdisc_route_filter<br /> <br /> test_ns<br /> sleep 2<br /> test_ns

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virt: tdx-guest: Fix handling of host controlled &amp;#39;quote&amp;#39; buffer length<br /> <br /> Validate host controlled value `quote_buf-&gt;out_len` that determines how<br /> many bytes of the quote are copied out to guest userspace. In TDX<br /> environments with remote attestation, quotes are not considered private,<br /> and can be forwarded to an attestation server.<br /> <br /> Catch scenarios where the host specifies a response length larger than<br /> the guest&amp;#39;s allocation, or otherwise races modifying the response while<br /> the guest consumes it.<br /> <br /> This prevents contents beyond the pages allocated for `quote_buf`<br /> (up to TSM_REPORT_OUTBLOB_MAX) from being read out to guest userspace,<br /> and possibly forwarded in attestation requests.<br /> <br /> Recall that some deployments want per-container configs-tsm-report<br /> interfaces, so the leak may cross container protection boundaries, not<br /> just local root.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: iptfs: only publish mode_data after clone setup<br /> <br /> iptfs_clone_state() stores x-&gt;mode_data before allocating the reorder<br /> window. If that allocation fails, the code frees the cloned state and<br /> returns -ENOMEM, leaving x-&gt;mode_data pointing at freed memory.<br /> <br /> The xfrm clone unwind later runs destroy_state() through x-&gt;mode_data,<br /> so the failed clone path tears down IPTFS state that clone_state()<br /> already freed.<br /> <br /> Keep the cloned IPTFS state private until all allocations succeed so<br /> failed clones leave x-&gt;mode_data unset. The destroy path already<br /> handles a NULL mode_data pointer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: iptfs: validate inner IPv4 header length in IPTFS payload<br /> <br /> Add validation of the inner IPv4 packet tot_len and ihl fields parsed<br /> from decrypted IPTFS payloads in __input_process_payload(). A crafted<br /> ESP packet containing an inner IPv4 header with tot_len=0 causes an<br /> infinite loop: iplen=0 leads to capturelen=min(0, remaining)=0, so the<br /> data offset never advances and the while(data

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mc, v4l2: serialize REINIT and REQBUFS with req_queue_mutex<br /> <br /> MEDIA_REQUEST_IOC_REINIT can run concurrently with VIDIOC_REQBUFS(0)<br /> queue teardown paths. This can race request object cleanup against vb2<br /> queue cancellation and lead to use-after-free reports.<br /> <br /> We already serialize request queueing against STREAMON/OFF with<br /> req_queue_mutex. Extend that serialization to REQBUFS, and also take<br /> the same mutex in media_request_ioctl_reinit() so REINIT is in the<br /> same exclusion domain.<br /> <br /> This keeps request cleanup and queue cancellation from running in<br /> parallel for request-capable devices.