Vulnerabilidades

*** Pendiente de traducción *** A use after free issue was addressed with improved memory management. 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 unexpected system termination.

*** Pendiente de traducción *** An access issue was addressed with additional sandbox restrictions. This issue is fixed in macOS Sequoia 15.7.8, macOS Sonoma 14.8.8, macOS Tahoe 26.6. An app may be able to break out of its sandbox.

*** Pendiente de traducción *** A use after free issue was addressed with improved memory management. This issue is fixed in macOS Sequoia 15.7.8, macOS Sonoma 14.8.8, macOS Tahoe 26.6. An app may be able to cause a denial-of-service.

*** Pendiente de traducción *** A type confusion issue was addressed with improved memory handling. This issue is fixed in macOS Sequoia 15.7.8, macOS Sonoma 14.8.8, macOS Tahoe 26.6. An app may be able to cause unexpected system termination.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: psample: fix info leak in PSAMPLE_ATTR_DATA<br /> <br /> psample open codes nla_put() presumably to avoid wiping<br /> the data with 0s just to override it with packet data.<br /> This open coding is missing clearing the pad, however,<br /> each netlink attr is padded to 4B and data_len may<br /> not be divisible by 4B.

*** Pendiente de traducción *** 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

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** A type confusion issue was addressed with improved checks. 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. Processing a maliciously crafted image may lead to a denial-of-service.