Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/srp: bound SRP_RSP sense copy by the received length<br /> <br /> srp_process_rsp() copies sense data from rsp-&gt;data + resp_data_len,<br /> where resp_data_len is the full 32-bit value supplied by the SRP target<br /> and is never checked against the number of bytes actually received<br /> (wc-&gt;byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so<br /> at most 96 bytes are copied, but the source offset is not bounded.<br /> <br /> A malicious or compromised SRP target on the InfiniBand/RoCE fabric that<br /> the initiator has logged into can return an SRP_RSP with<br /> SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer<br /> is allocated at the target-chosen max_ti_iu_len, so the source of the<br /> sense copy lands past the bytes actually received; with resp_data_len<br /> near 0xFFFFFFFF it is gigabytes past the buffer and the read faults.<br /> <br /> Copy the sense data only if it has not been truncated, that is, only if<br /> the response header, the response data, and the sense region fit within<br /> the bytes actually received; otherwise drop the sense and log. The<br /> in-tree iSER and NVMe-RDMA receive paths already bound their parse by<br /> wc-&gt;byte_len; this brings ib_srp into line with them.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: serial: kl5kusb105: fix bulk-out buffer overflow<br /> <br /> klsi_105_prepare_write_buffer() is called by the generic write path<br /> with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It<br /> stores a two-byte length header at the start of the buffer and copies<br /> the payload from the write fifo starting at buf + KLSI_HDR_LEN, but<br /> passes the full buffer size as the number of bytes to copy:<br /> <br /> count = kfifo_out_locked(&amp;port-&gt;write_fifo, buf + KLSI_HDR_LEN,<br /> size, &amp;port-&gt;lock);<br /> <br /> When the fifo holds at least size bytes, size bytes are copied starting<br /> two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its<br /> end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for<br /> the header as safe_serial already does.<br /> <br /> Writing bulk_out_size or more bytes to the tty triggers a slab<br /> out-of-bounds write, observed with KASAN by emulating the device with<br /> dummy_hcd and raw-gadget:<br /> <br /> BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0<br /> Write of size 64 at addr ffff888112c62202 by task python3<br /> kfifo_copy_out<br /> klsi_105_prepare_write_buffer [kl5kusb105]<br /> usb_serial_generic_write_start [usbserial]<br /> Allocated by task 139:<br /> usb_serial_probe [usbserial]<br /> The buggy address is located 2 bytes inside of allocated 64-byte region<br /> <br /> The out-of-bounds write no longer occurs with this change applied.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: fix buffer over-read in rtw_update_protection<br /> <br /> rtw_update_protection() is called with a pointer offset into the<br /> ies buffer but the full ie_length is passed, causing a potential<br /> buffer over-read.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en: Fix NULL pointer dereference<br /> <br /> PCIe errors detected by a Root Port or Downstream Port cause error<br /> recovery services to run on all subordinate devices regardless of<br /> administrative state.<br /> <br /> The .error_detected() callback, bnxt_io_error_detected(), disables<br /> and synchronizes IRQs via bnxt_disable_int_sync(), which calls<br /> bnxt_cp_num_to_irq_num() to map completion rings to IRQs using<br /> bp-&gt;bnapi.<br /> <br /> Since bp-&gt;bnapi is allocated on NIC open and freed on NIC close, PCIe<br /> error recovery on a closed NIC can dereference a NULL pointer.<br /> <br /> Check if bp-&gt;bnapi is NULL before disabling and synchronizing IRQs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udp: clear skb-&gt;dev before running a sockmap verdict<br /> <br /> On the UDP receive path skb-&gt;dev is repurposed as dev_scratch (the<br /> truesize/state cache set by udp_set_dev_scratch()), through the<br /> union { struct net_device *dev; unsigned long dev_scratch; } in sk_buff.<br /> <br /> When a UDP socket is in a sockmap, sk_data_ready is<br /> sk_psock_verdict_data_ready(), which calls udp_read_skb() -&gt; recv_actor()<br /> (sk_psock_verdict_recv) to run the attached SK_SKB verdict program in softirq.<br /> If that program calls a socket-lookup helper (bpf_sk_lookup_tcp/udp,<br /> bpf_skc_lookup_tcp), bpf_skc_lookup() does:<br /> <br /> if (skb-&gt;dev)<br /> caller_net = dev_net(skb-&gt;dev);<br /> <br /> skb-&gt;dev still holds the dev_scratch value (a non-NULL integer), so dev_net()<br /> dereferences it as a struct net_device * and the kernel takes a general<br /> protection fault on a non-canonical address in softirq:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0x1010000800004a0<br /> CPU: 1 UID: 0 PID: 1406 Comm: syz.2.19 Not tainted 7.1.0-rc6 #1 PREEMPT(full)<br /> RIP: 0010:bpf_skc_lookup net/core/filter.c:7033 [inline]<br /> RIP: 0010:bpf_sk_lookup+0x45/0x160 net/core/filter.c:7047<br /> Call Trace:<br /> <br /> bpf_prog_4675cb904b7071f8+0x12e/0x14e<br /> bpf_prog_run_pin_on_cpu+0xc6/0x1f0<br /> sk_psock_verdict_recv+0x1ba/0x350<br /> udp_read_skb+0x31a/0x370<br /> sk_psock_verdict_data_ready+0x2e3/0x600<br /> __udp_enqueue_schedule_skb+0x4c8/0x650<br /> udpv6_queue_rcv_one_skb+0x3ec/0x740<br /> udp6_unicast_rcv_skb+0x11d/0x140<br /> ip6_protocol_deliver_rcu+0x61e/0x950<br /> ip6_input_finish+0xa9/0x150<br /> NF_HOOK+0x286/0x2f0<br /> ip6_input+0x117/0x220<br /> NF_HOOK+0x286/0x2f0<br /> __netif_receive_skb+0x85/0x200<br /> process_backlog+0x374/0x9a0<br /> __napi_poll+0x4f/0x1c0<br /> net_rx_action+0x3b0/0x770<br /> handle_softirqs+0x15a/0x460<br /> do_softirq+0x57/0x80<br /> <br /> <br /> The rmem charge that dev_scratch accounted for is released by skb_recv_udp() on<br /> dequeue, just above, so the scratch is dead by the time recv_actor() runs. Clear<br /> skb-&gt;dev so bpf_skc_lookup() falls back to sock_net(skb-&gt;sk), which<br /> skb_set_owner_sk_safe() set just above.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: allow subflow rcv wnd to shrink<br /> <br /> In MPTCP connection, the `window` field in the TCP header refers to the<br /> MPTCP-level rcv_nxt and it&amp;#39;s right edge should not move backward. Such<br /> constraint is enforced at DSS option generation time.<br /> <br /> At the same time, the TCP stack ensures independently that the TCP-level<br /> rcv wnd right&amp;#39;s edge does not move backward. That in turn causes artificial<br /> inflating of the MPTCP rcv window when the incoming data is acked at the<br /> TCP level and is OoO in the MPTCP sequence space (or lands in the backlog).<br /> <br /> As a consequence, the incoming traffic can exceed the receiver rcvbuf size<br /> even when the sender is not misbehaving.<br /> <br /> Prevent such scenario forcibly allowing the TCP subflow to shrink the<br /> TCP-level rcv wnd regardless of the current netns setting.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: nl80211: reject oversized EMA RNR lists<br /> <br /> nl80211_parse_rnr_elems() stores the parsed element count in a<br /> u8-backed cfg80211_rnr_elems::cnt field and uses that count to size<br /> the flexible array allocation.<br /> <br /> Reject nested NL80211_ATTR_EMA_RNR_ELEMS input once the count reaches<br /> 255, before incrementing it again. This keeps the parser aligned with<br /> the data structure it fills and matches the existing bound check used<br /> by nl80211_parse_mbssid_elems().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock/vmci: fix sk_ack_backlog leak on failed handshake<br /> <br /> When vmci_transport_recv_connecting_server() returns an error,<br /> vmci_transport_recv_listen() calls vsock_remove_pending() but never<br /> calls sk_acceptq_removed(). This leaves sk_ack_backlog incremented<br /> permanently.<br /> <br /> Repeated handshake failures (malformed packets, queue pair alloc<br /> failure, event subscribe failure) cause sk_ack_backlog to climb<br /> toward sk_max_ack_backlog. Once it reaches the limit the listener<br /> permanently refuses all new connections with -ECONNREFUSED, a<br /> silent denial of service requiring a process restart to recover.<br /> <br /> The two existing sk_acceptq_removed() calls in af_vsock.c do not<br /> cover this path: line 764 checks vsock_is_pending() which returns<br /> false after vsock_remove_pending(), and line 1889 is only reached<br /> on successful accept().<br /> <br /> Fix by balancing sk_acceptq_added() with sk_acceptq_removed() on<br /> the error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> timers/migration: Fix livelock in tmigr_handle_remote_up()<br /> <br /> tmigr_handle_remote_cpu() skips timer_expire_remote() when cpu ==<br /> smp_processor_id(), assuming the local softirq path already handled this<br /> CPU&amp;#39;s timers.<br /> <br /> This assumption is wrong because jiffies can advance after the handling of<br /> the CPU&amp;#39;s global timers in run_timer_base(BASE_GLOBAL) and before<br /> tmigr_handle_remote() evaluates the expiry times.<br /> <br /> As a consequence a timer which expires after the CPU local timer wheel<br /> advanced and becomes expired in the remote handling is ignored and the<br /> callback is never invoked and removed from the timer wheel.<br /> <br /> What&amp;#39;s worse is that fetch_next_timer_interrupt_remote() keeps reporting it<br /> as expired, and the event is re-queued with expires == now on each<br /> iteration. The goto-again loop spins indefinitely.<br /> <br /> Fix this by calling timer_expire_remote() unconditionally. That&amp;#39;s minimal<br /> overhead for the common case as __run_timer_base() returns immediately if<br /> there is nothing to expire in the local wheel.<br /> <br /> [ tglx: Amend change log and add a comment ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: rtw_mlme: add bounds checks before ie_length subtraction<br /> <br /> Add guards to ensure ie_length is large enough before subtracting<br /> fixed IE offsets to prevent unsigned integer underflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> zram: fix use-after-free in zram_bvec_write_partial()<br /> <br /> zram_read_page() picks the sync or async backing device read path based on<br /> whether the parent bio is NULL. zram_bvec_write_partial() passes its<br /> parent bio down, so for ZRAM_WB slots the read is dispatched<br /> asynchronously and zram_read_page() returns 0 while the bio is still in<br /> flight. The caller then runs memcpy_from_bvec(), zram_write_page() and<br /> __free_page() on the buffer, leaving the async read to write into a freed<br /> page.<br /> <br /> zram_bvec_read_partial() was switched to NULL in commit 4e3c87b9421d<br /> ("zram: fix synchronous reads") for the same reason; the write_partial<br /> counterpart was missed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/ethosu: fix OOB write in ethosu_gem_cmdstream_copy_and_validate()<br /> <br /> The command stream parsing loop increments the index variable a second<br /> time when a 64-bit command word is encountered (bit 14 set), but does<br /> not re-check the loop bound before writing the second word:<br /> <br /> for (i = 0; i