Vulnerabilities

A buffer overflow was addressed with improved size validation. This issue is fixed in macOS Tahoe 26.6. An app may be able to cause unexpected system termination.

An out-of-bounds read was addressed with improved bounds checking. This issue is fixed in iOS 26.6 and iPadOS 26.6, macOS Sequoia 15.7.8, macOS Sonoma 14.8.8, macOS Tahoe 26.6, tvOS 26.6, visionOS 26.6, watchOS 26.6. An app may be able to cause a denial-of-service.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: validate STALE_COOKIE cause length before reading staleness<br /> <br /> When an ERROR chunk with a STALE_COOKIE cause is received in the<br /> COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure<br /> of Staleness that follows the cause header:<br /> <br /> err = (struct sctp_errhdr *)(chunk-&gt;skb-&gt;data);<br /> stale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err)));<br /> <br /> err is the first cause in the chunk, not the STALE_COOKIE cause that<br /> caused the dispatch, and nothing guarantees the staleness field is<br /> present. sctp_walk_errors() only requires a cause to be as long as the<br /> 4-byte header, so for a STALE_COOKIE cause of length 4 the read runs<br /> past the cause, and for a minimal ERROR chunk past skb-&gt;tail. The value<br /> is echoed to the peer in the Cookie Preservative of the reply INIT,<br /> leaking uninitialized memory.<br /> <br /> sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so<br /> check its length there and pass it to sctp_sf_do_5_2_6_stale(), which<br /> reads that cause instead of the first one. A STALE_COOKIE cause too<br /> short to hold the staleness field is discarded.<br /> <br /> The read is reachable by any peer that can drive an association into<br /> COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket<br /> in a user and network namespace.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio-net: fix len check in receive_big()<br /> <br /> receive_big() bounds the device-announced length by<br /> (big_packets_num_skbfrags + 1) * PAGE_SIZE. That is still too loose:<br /> add_recvbuf_big() sets sg[1] to start at offset<br /> sizeof(struct padded_vnet_hdr) into the first page, so the chain<br /> actually carries hdr_len + (PAGE_SIZE - sizeof(padded_vnet_hdr)) +<br /> big_packets_num_skbfrags * PAGE_SIZE bytes -- 20 bytes less than the<br /> check allows for the common hdr_len == 12 case.<br /> <br /> A malicious virtio backend can announce a len in that gap. page_to_skb()<br /> then walks one frag past the page chain, storing a NULL page-&gt;private<br /> into skb_shinfo()-&gt;frags[MAX_SKB_FRAGS], which is both an out-of-bounds<br /> write past the static frag array and a NULL frag handed up the rx path.<br /> <br /> Bound len by the size add_recvbuf_big() actually advertised.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: bridge: fix stale prevhdr pointer in br_ip6_fragment()<br /> <br /> br_ip6_fragment() gets prevhdr, a pointer into the skb head, from<br /> ip6_find_1stfragopt(), then calls skb_checksum_help(). For a cloned skb<br /> skb_checksum_help() reallocates the head via pskb_expand_head(), leaving<br /> prevhdr dangling. It is later dereferenced in ip6_frag_next(), causing a<br /> use-after-free write.<br /> <br /> Save prevhdr&amp;#39;s offset before skb_checksum_help() and recompute it after,<br /> like commit ef0efcd3bd3f ("ipv6: Fix dangling pointer when ipv6<br /> fragment").<br /> <br /> BUG: KASAN: slab-use-after-free in ip6_frag_next (net/ipv6/ip6_output.c:857)<br /> Write of size 1 at addr ffff888013ff5016 by task exploit/141<br /> Call Trace:<br /> ...<br /> kasan_report (mm/kasan/report.c:595)<br /> ip6_frag_next (net/ipv6/ip6_output.c:857)<br /> br_ip6_fragment (net/ipv6/netfilter.c:212)<br /> nf_ct_bridge_post (net/bridge/netfilter/nf_conntrack_bridge.c:407)<br /> nf_hook_slow (net/netfilter/core.c:619)<br /> br_forward_finish (net/bridge/br_forward.c:66)<br /> __br_forward (net/bridge/br_forward.c:115)<br /> maybe_deliver (net/bridge/br_forward.c:191)<br /> br_flood (net/bridge/br_forward.c:245)<br /> br_handle_frame_finish (net/bridge/br_input.c:229)<br /> br_handle_frame (net/bridge/br_input.c:442)<br /> ...<br /> packet_sendmsg (net/packet/af_packet.c:3114)<br /> ...<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:94)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)<br /> Kernel panic - not syncing: Fatal exception in interrupt

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: nv: Fix SPSR_EL2 restore in kvm_hyp_handle_mops()<br /> <br /> kvm_hyp_handle_mops() resets the single-step state machine as part of<br /> rewinding state for a MOPS exception by modifying vcpu_cpsr() and<br /> writing the result directly into hardware.<br /> <br /> In the case of nested virtualization, vcpu_cpsr() is a synthetic value<br /> such that the rest of KVM can deal with vEL2 cleanly. That means the<br /> value requires translation before being written into hardware, which is<br /> unfortunately missing from the MOPS handler.<br /> <br /> Fix it by directly modifying SPSR_EL2 and avoiding the synthetic state<br /> altogether, which will be resynchronized on the next &amp;#39;full&amp;#39; exit back<br /> to KVM.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()<br /> <br /> bpa10x_setup() sends the vendor command 0xfc0e and passes the response<br /> to bt_dev_info() and hci_set_fw_info() as a "%s" string starting at<br /> skb-&gt;data + 1, without checking the length:<br /> <br /> bt_dev_info(hdev, "%s", (char *)(skb-&gt;data + 1));<br /> hci_set_fw_info(hdev, "%s", skb-&gt;data + 1);<br /> <br /> A device that returns a one-byte response (status only) leaves<br /> skb-&gt;data + 1 past the end of the data, and the %s walk reads adjacent<br /> slab memory until it meets a NUL. The same happens when the payload is<br /> not NUL-terminated within skb-&gt;len. The out-of-bounds bytes end up in<br /> the kernel log and the firmware-info debugfs file.<br /> <br /> Print the revision string with a bounded "%.*s" limited to skb-&gt;len - 1<br /> instead. This keeps the string readable for well-behaved devices while<br /> never reading past the received data, and does not fail setup, so a<br /> device returning a short or unterminated response keeps working.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net, bpf: check master for NULL in xdp_master_redirect()<br /> <br /> xdp_master_redirect() dereferences the result of<br /> netdev_master_upper_dev_get_rcu() without a NULL check, but that helper<br /> returns NULL when the receiving device has no upper-master adjacency.<br /> <br /> The reach guard only checks netif_is_bond_slave(). On bond slave release<br /> bond_upper_dev_unlink() drops the upper-master adjacency before clearing<br /> IFF_SLAVE, so an XDP_TX reaching xdp_master_redirect() in that window<br /> still passes netif_is_bond_slave() while master is already NULL, and<br /> faults on master-&gt;flags at offset 0xb0:<br /> <br /> BUG: kernel NULL pointer dereference, address: 00000000000000b0<br /> RIP: 0010:xdp_master_redirect (net/core/filter.c:4432)<br /> Call Trace:<br /> xdp_master_redirect (net/core/filter.c:4432)<br /> bpf_prog_run_generic_xdp (include/net/xdp.h:700)<br /> do_xdp_generic (net/core/dev.c:5608)<br /> __netif_receive_skb_one_core (net/core/dev.c:6204)<br /> process_backlog (net/core/dev.c:6319)<br /> __napi_poll (net/core/dev.c:7729)<br /> net_rx_action (net/core/dev.c:7792)<br /> handle_softirqs (kernel/softirq.c:622)<br /> __dev_queue_xmit (include/linux/bottom_half.h:33)<br /> packet_sendmsg (net/packet/af_packet.c:3082)<br /> __sys_sendto (net/socket.c:2252)<br /> Kernel panic - not syncing: Fatal exception in interrupt<br /> <br /> The missing check dates back to the original code; commit 1921f91298d1<br /> ("net, bpf: fix null-ptr-deref in xdp_master_redirect() for down master")<br /> later added the master-&gt;flags read where the fault now lands but kept the<br /> unconditional deref. Check master for NULL before use; a NULL master is<br /> treated the same as one that is not up.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/edid: fix OOB read in drm_parse_tiled_block()<br /> <br /> drm_parse_tiled_block() casts the DisplayID block to a<br /> struct displayid_tiled_block and reads the full fixed layout up to<br /> tile-&gt;topology_id[7] without checking block-&gt;num_bytes. The DisplayID<br /> iterator only validates the declared payload length, so a crafted EDID<br /> can advertise a tiled-display block (tag DATA_BLOCK_TILED_DISPLAY, or<br /> DATA_BLOCK_2_TILED_DISPLAY_TOPOLOGY for v2.0) with a small num_bytes at<br /> the end of a DisplayID extension. The read then runs past the end of the<br /> exact-sized kmemdup()&amp;#39;d EDID allocation, a heap out-of-bounds read.<br /> <br /> Reject blocks shorter than the spec&amp;#39;s 22-byte tiled payload before<br /> reading the fixed struct, as drm_parse_vesa_mso_data() already does.<br /> <br /> BUG: KASAN: slab-out-of-bounds in drm_edid_connector_update<br /> Read of size 2 at addr ffff888010077700 by task exploit/147<br /> dump_stack_lvl (lib/dump_stack.c:94 ...)<br /> print_report (mm/kasan/report.c:378 ...)<br /> kasan_report (mm/kasan/report.c:595)<br /> drm_edid_connector_update (drivers/gpu/drm/drm_edid.c:7581)<br /> bochs_connector_helper_get_modes (drivers/gpu/drm/tiny/bochs.c:574)<br /> drm_helper_probe_single_connector_modes (drivers/gpu/drm/drm_probe_helper.c:426)<br /> status_store (drivers/gpu/drm/drm_sysfs.c:219)<br /> ...<br /> vfs_write (fs/read_write.c:595 fs/read_write.c:688)<br /> ksys_write (fs/read_write.c:740)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: net1080: validate packet_len before pad-byte access in rx_fixup<br /> <br /> For an even packet_len, net1080_rx_fixup() reads the pad byte at<br /> skb-&gt;data[packet_len] before the skb-&gt;len != packet_len check further<br /> down, and packet_len is only bounded against NC_MAX_PACKET. A malicious<br /> NetChip 1080 device can send a short frame advertising a large even<br /> packet_len (e.g. 0x4000), so the pad-byte read lands past the end of the<br /> skb:<br /> <br /> BUG: KASAN: slab-out-of-bounds in net1080_rx_fixup<br /> Read of size 1 at addr ffff8880106c83c6 by task ksoftirqd/0/14<br /> ...<br /> net1080_rx_fixup (drivers/net/usb/net1080.c:384)<br /> usbnet_bh (drivers/net/usb/usbnet.c:1589)<br /> process_one_work (kernel/workqueue.c:3322)<br /> bh_worker (kernel/workqueue.c:3708)<br /> tasklet_action (kernel/softirq.c:965)<br /> handle_softirqs (kernel/softirq.c:622)<br /> ...<br /> <br /> Reject the frame when packet_len &gt;= skb-&gt;len before reading.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: reject overflowing copy + len in bpf_msg_push_data()<br /> <br /> When the scatterlist ring is full or nearly full, bpf_msg_push_data()<br /> enters a copy fallback path and computes copy + len for the page<br /> allocation size. Since len comes from BPF with arg3_type = ARG_ANYTHING<br /> and both are u32, a crafted len can wrap the sum to a small value,<br /> causing an undersized allocation followed by an out-of-bounds memcpy.<br /> <br /> BUG: unable to handle page fault for address: ffffed104089a402<br /> Oops: Oops: 0000 [#1] SMP KASAN NOPTI<br /> Call Trace:<br /> __asan_memcpy (mm/kasan/shadow.c:105)<br /> bpf_msg_push_data (net/core/filter.c:2852 net/core/filter.c:2788)<br /> bpf_prog_9ed8b5711920a7d7+0x2e/0x36<br /> sk_psock_msg_verdict (net/core/skmsg.c:934)<br /> tcp_bpf_sendmsg (net/ipv4/tcp_bpf.c:421 net/ipv4/tcp_bpf.c:584)<br /> __sys_sendto (net/socket.c:2206)<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:94)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)<br /> <br /> Add an overflow check before the allocation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qualcomm: rmnet: validate MAP frame length before ingress parsing<br /> <br /> When ingress deaggregation is disabled, rmnet_map_ingress_handler() passes<br /> the skb straight to __rmnet_map_ingress_handler(), skipping the length<br /> validation that rmnet_map_deaggregate() performs on the aggregated path.<br /> The parser then dereferences the MAP header and csum header/trailer based on<br /> the on-wire pkt_len without checking skb-&gt;len, so a short frame is read out<br /> of bounds:<br /> <br /> BUG: KASAN: slab-out-of-bounds in rmnet_map_checksum_downlink_packet<br /> Read of size 1 at addr ffff88801118ed00 by task exploit/147<br /> Call Trace:<br /> ...<br /> rmnet_map_checksum_downlink_packet (drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c:413)<br /> __rmnet_map_ingress_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:96)<br /> rmnet_rx_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:129)<br /> __netif_receive_skb_core.constprop.0 (net/core/dev.c:6089)<br /> netif_receive_skb (net/core/dev.c:6460)<br /> tun_get_user (drivers/net/tun.c:1955)<br /> tun_chr_write_iter (drivers/net/tun.c:2001)<br /> vfs_write (fs/read_write.c:688)<br /> ksys_write (fs/read_write.c:740)<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:94)<br /> ...<br /> <br /> Factor that validation out of rmnet_map_deaggregate() into<br /> rmnet_map_validate_packet_len() and run it on the no-aggregation path too.<br /> The MAP header is bounds-checked first, since this path can receive a frame<br /> shorter than the header.