Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_log: validate MAC header was set before dumping it<br /> <br /> The fallback path of dump_mac_header() guards the MAC header access<br /> only with "skb-&gt;mac_header != skb-&gt;network_header", without checking<br /> skb_mac_header_was_set(). When the MAC header is unset, mac_header is<br /> 0xffff, so the test passes and skb_mac_header(skb) returns<br /> skb-&gt;head + 0xffff, ~64 KiB past the buffer; the loop then reads<br /> dev-&gt;hard_header_len bytes out of bounds into the kernel log.<br /> <br /> This is reachable via the netdev logger: nf_log_unknown_packet() calls<br /> dump_mac_header() unconditionally, and an skb sent through AF_PACKET<br /> with PACKET_QDISC_BYPASS reaches the egress hook with mac_header still<br /> unset (__dev_queue_xmit(), which would reset it, is bypassed).<br /> <br /> Add the skb_mac_header_was_set() check the ARPHRD_ETHER path already<br /> uses, and replace the open-coded MAC header length test with<br /> skb_mac_header_len(). Only skbs with an unset MAC header are affected;<br /> valid ones are dumped as before.<br /> <br /> BUG: KASAN: slab-out-of-bounds in dump_mac_header (net/netfilter/nf_log_syslog.c:831)<br /> Read of size 1 at addr ffff88800ea49d3f by task exploit/148<br /> Call Trace:<br /> kasan_report (mm/kasan/report.c:595)<br /> dump_mac_header (net/netfilter/nf_log_syslog.c:831)<br /> nf_log_netdev_packet (net/netfilter/nf_log_syslog.c:938 net/netfilter/nf_log_syslog.c:963)<br /> nf_log_packet (net/netfilter/nf_log.c:260)<br /> nft_log_eval (net/netfilter/nft_log.c:60)<br /> nft_do_chain (net/netfilter/nf_tables_core.c:285)<br /> nft_do_chain_netdev (net/netfilter/nft_chain_filter.c:307)<br /> nf_hook_slow (net/netfilter/core.c:619)<br /> nf_hook_direct_egress (net/packet/af_packet.c:257)<br /> packet_xmit (net/packet/af_packet.c:280)<br /> packet_sendmsg (net/packet/af_packet.c:3114)<br /> __sys_sendto (net/socket.c:2265)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tap: fix stack info leak in tap_ioctl() SIOCGIFHWADDR<br /> <br /> In the SIOCGIFHWADDR path, tap_ioctl() copies 16 bytes of an<br /> uninitialised on-stack struct sockaddr_storage to userspace via<br /> ifr_hwaddr, but netif_get_mac_address() only writes sa_family and<br /> dev-&gt;addr_len (6 for Ethernet) bytes, leaving sa_data[6..13] uninitialised.<br /> <br /> Those 8 trailing bytes leak kernel stack contents; SIOCGIFHWADDR on a<br /> macvtap chardev returns kernel .text and direct-map pointers, defeating<br /> KASLR.<br /> <br /> Initialise ss at declaration.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: jitterentropy - replace long-held spinlock with mutex<br /> <br /> jent_kcapi_random() serializes the shared jitterentropy state, but it<br /> currently holds a spinlock across the jent_read_entropy() call. That<br /> path performs expensive jitter collection and SHA3 conditioning, so<br /> parallel readers can trigger stalls as contending waiters spin for<br /> the same lock.<br /> <br /> To prevent non-preemptible lock hold, replace rng-&gt;jent_lock with a<br /> mutex so contended readers sleep instead of spinning on a shared lock<br /> held across expensive entropy generation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: espintcp: do not reuse an in-progress partial send<br /> <br /> espintcp keeps a single in-flight transmit in ctx-&gt;partial.<br /> Before building a new sk_msg, espintcp_sendmsg() first tries to flush<br /> that state through espintcp_push_msgs().<br /> <br /> For blocking callers, espintcp_push_msgs() may return success even when<br /> the previous partial send is still pending. espintcp_sendmsg() would<br /> then reinitialize emsg-&gt;skmsg and reuse ctx-&gt;partial while the old<br /> transfer still owns that state.<br /> <br /> Do not rebuild the send message when ctx-&gt;partial is still in progress.<br /> If espintcp_push_msgs() returns with emsg-&gt;len still set, fail the new<br /> send instead of overwriting the live partial state.<br /> <br /> This is a memory-safety fix: reusing the live partial-send state can<br /> leave a stale offset attached to a new sk_msg and lead to an out-of-<br /> bounds read in the send path.<br /> <br /> tcp_sendmsg_locked() already handles waiting for send buffer memory, so<br /> the fix here is just to preserve espintcp&amp;#39;s one-message-at-a-time<br /> transmit state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/poll: fix signed comparison in io_poll_get_ownership()<br /> <br /> io_poll_get_ownership() uses a signed comparison to check whether<br /> poll_refs has reached the threshold for the slowpath:<br /> <br /> if (unlikely(atomic_read(&amp;req-&gt;poll_refs) &gt;= IO_POLL_REF_BIAS))<br /> <br /> atomic_read() returns int (signed). When IO_POLL_CANCEL_FLAG<br /> (BIT(31)) is set in poll_refs, the value becomes negative in<br /> signed arithmetic, so the &gt;= 128 comparison always evaluates to<br /> false and the slowpath is never taken.<br /> <br /> Fix this by casting the atomic_read() result to unsigned int<br /> before the comparison, so that the cancel flag is treated as a<br /> large positive value and correctly triggers the slowpath.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: ipcomp: Free destination pages on acomp errors<br /> <br /> Move the out_free_req label up by a couple of lines so that the<br /> allocated dst SG list gets freed on error as well as success.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: tp_meter: avoid use of uninit sender vars<br /> <br /> batadv_tp_recv_ack() and batadv_tp_stop() are only valid for tp_vars in the<br /> BATADV_TP_SENDER role. When called with a BATADV_TP_RECEIVER role, it<br /> proceeds to read sender-only members that were never initialized, leading<br /> to undefined behavior.<br /> <br /> This can be triggered when a node that is currently acting as a receiver in<br /> an ongoing tp_meter session receives a malicious ACK packet.<br /> <br /> Guard against this by checking tp_vars-&gt;role immediately after the<br /> lookup and bailing out if it is not BATADV_TP_SENDER, before any of<br /> those members are accessed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipc/shm: serialize orphan cleanup with shm_nattch updates<br /> <br /> shm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that<br /> does not serialize all fields tested by shm_may_destroy(). In particular,<br /> shm_nattch is updated while holding shm_perm.lock, and attach paths can do<br /> that without holding the rwsem.<br /> <br /> Do not decide that an orphaned segment is unused before taking the object<br /> lock. Move the shm_may_destroy() check under shm_perm.lock, matching the<br /> other destroy paths, and unlock the segment when it no longer qualifies<br /> for removal.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: stream: fully roll back denied add-stream state<br /> <br /> When ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and<br /> then lowers outcnt. That leaves removed stream metadata behind, so a<br /> later re-add can reuse a stale ext and hit a null-pointer dereference in<br /> the scheduler get path.<br /> <br /> Fix the rollback by tearing down the removed stream state the same way<br /> other stream resizes do. Unschedule the current scheduler state, drop<br /> the removed stream ext state with sctp_stream_outq_migrate(), and then<br /> reschedule the remaining streams.<br /> <br /> This keeps scheduler-private RR/FC/PRIO lists consistent while fully<br /> rolling back denied outgoing stream additions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: tvlv: reject oversized TVLV packets<br /> <br /> batadv_tvlv_container_ogm_append() builds a TVLV packet section from<br /> the tvlv.container_list. The total size of this section is computed by<br /> batadv_tvlv_container_list_size(), which sums the sizes of all registered<br /> containers.<br /> <br /> The return type and accumulator in batadv_tvlv_container_list_size() were<br /> u16. If the accumulated size exceeds U16_MAX, the value wraps around,<br /> causing the subsequent allocation in batadv_tvlv_container_ogm_append()<br /> to be undersized. The memcpy-style copy that follows would then write<br /> beyond the end of the allocated buffer, corrupting kernel memory.<br /> <br /> Fix this by widening the return type of batadv_tvlv_container_list_size()<br /> to size_t. In batadv_tvlv_container_ogm_append(), check the computed length<br /> against U16_MAX before proceeding, and bail out as if the allocation had<br /> failed when the limit is exceeded.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: purge outqueue on stale COOKIE-ECHO handling<br /> <br /> sctp_stream_update() is only invoked when the association is moved into<br /> COOKIE_WAIT during association setup/reconfiguration. In this path, the<br /> outbound stream scheduler state (stream-&gt;out_curr) is expected to be<br /> clean, since no user data should have been transmitted yet unless the<br /> state machine has already partially progressed.<br /> <br /> However, a corner case exists in sctp_sf_do_5_2_6_stale(): when a<br /> Stale Cookie ERROR is received, the association is rolled back from<br /> COOKIE_ECHOED to COOKIE_WAIT. In this scenario, user data may already<br /> have been queued and even bundled with the COOKIE-ECHO chunk.<br /> <br /> During the rollback, sctp_stream_update() frees the old stream table<br /> and installs a new one, but it does not invalidate stream-&gt;out_curr.<br /> As a result, out_curr may still point to a freed sctp_stream_out<br /> entry from the previous stream state.<br /> <br /> Later, SCTP scheduler dequeue paths (FCFS, RR, PRIO, etc.) rely on<br /> stream-&gt;out_curr-&gt;ext, which can lead to use-after-free once the old<br /> stream state has been released via sctp_stream_free().<br /> <br /> This results in crashes such as (reported by Yuqi):<br /> <br /> BUG: KASAN: slab-use-after-free in sctp_sched_fcfs_dequeue+0x13a/0x140<br /> Read of size 8 at addr ff1100004d4d3208 by task mini_poc/9312<br /> CPU: 1 UID: 1001 PID: 9312 Comm: mini_poc Not tainted<br /> 7.1.0-rc1-00305-gbd3a4795d574 #5 PREEMPT(full)<br /> sctp_sched_fcfs_dequeue+0x13a/0x140<br /> sctp_outq_flush+0x1603/0x33e0<br /> sctp_do_sm+0x31c9/0x5d30<br /> sctp_assoc_bh_rcv+0x392/0x6f0<br /> sctp_inq_push+0x1db/0x270<br /> sctp_rcv+0x138d/0x3c10<br /> <br /> Fix this by fully purging the association outqueue when handling the<br /> Stale Cookie case. This ensures all pending transmit and retransmit<br /> state is dropped, and any scheduler cached pointers are invalidated,<br /> making it safe to rebuild stream state during COOKIE_WAIT restart.<br /> <br /> Updating only stream-&gt;out_curr would be insufficient, since queued<br /> and retransmittable data would still reference the old stream state and<br /> trigger later use-after-free in dequeue paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_unix: Reject SIOCATMARK on non-stream sockets<br /> <br /> SIOCATMARK reports whether the receive queue is at the urgent mark for<br /> MSG_OOB.<br /> <br /> In AF_UNIX, MSG_OOB is supported only for SOCK_STREAM sockets.<br /> SOCK_DGRAM and SOCK_SEQPACKET reject MSG_OOB in sendmsg() and recvmsg(),<br /> so they should not support SIOCATMARK either.<br /> <br /> Return -EOPNOTSUPP for non-stream sockets before checking the receive<br /> queue.