Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: eir: Fix stack OOB write when prepending the Flags AD<br /> <br /> eir_create_adv_data() builds the advertising data into a fixed-size<br /> buffer ("size", 31 for the legacy path). It may prepend a 3-byte "Flags"<br /> AD structure (LE_AD_NO_BREDR on an LE-only controller) and then copies<br /> the per-instance data without checking that it still fits:<br /> <br /> memcpy(ptr, adv-&gt;adv_data, adv-&gt;adv_data_len);<br /> <br /> tlv_data_max_len() only reserves those 3 bytes when the user-supplied<br /> flags carry a managed-flags bit, so an instance added with flags == 0 is<br /> accepted with adv_data_len up to the full buffer. At advertise time the<br /> flags are still prepended, and the memcpy() writes 3 + adv_data_len<br /> bytes into the size-byte buffer:<br /> <br /> BUG: KASAN: stack-out-of-bounds in eir_create_adv_data (net/bluetooth/eir.c:301)<br /> Write of size 31 at addr ffff88800a547bdc by task kworker/u9:0/65<br /> Workqueue: hci0 hci_cmd_sync_work<br /> __asan_memcpy (mm/kasan/shadow.c:106)<br /> eir_create_adv_data (net/bluetooth/eir.c:301)<br /> hci_update_adv_data_sync (net/bluetooth/hci_sync.c:1310)<br /> hci_schedule_adv_instance_sync (net/bluetooth/hci_sync.c:1817)<br /> hci_cmd_sync_work (net/bluetooth/hci_sync.c:332)<br /> This frame has 1 object:<br /> [32, 64) &amp;#39;cp&amp;#39;<br /> <br /> The "Flags" structure is added by the kernel, not requested by<br /> userspace, so only prepend it when it fits together with the instance<br /> advertising data; when there is no room for both, drop the flags rather<br /> than the user-provided data.<br /> <br /> Reachable by a local user with CAP_NET_ADMIN owning an LE-only<br /> controller on the legacy advertising path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup()<br /> <br /> genelink_rx_fixup() splits an aggregated RX frame into its individual<br /> packets, using a per-packet length taken from device-supplied data. That<br /> length is only bounded by GL_MAX_PACKET_LEN (1514); it is never compared<br /> against how many bytes were actually received.<br /> <br /> A malicious GeneLink (GL620A) device can therefore send a short URB whose<br /> header claims packet_count &gt; 1 and a first packet of up to 1514 bytes.<br /> <br /> skb_put_data(gl_skb, packet-&gt;packet_data, size);<br /> <br /> then copies past the end of the receive buffer and hands the adjacent slab<br /> contents up the network stack, an out-of-bounds read that leaks kernel heap.<br /> No privilege is required: the path runs in the usbnet RX softirq as soon as<br /> the interface is up.<br /> <br /> BUG: KASAN: slab-out-of-bounds in genelink_rx_fixup (drivers/net/usb/gl620a.c:112)<br /> Read of size 1514 at addr ffff888011309708 by task ksoftirqd/0/14<br /> Call Trace:<br /> ...<br /> __asan_memcpy (mm/kasan/shadow.c:105)<br /> genelink_rx_fixup (include/linux/skbuff.h:2814 drivers/net/usb/gl620a.c:112)<br /> usbnet_bh (drivers/net/usb/usbnet.c:572 drivers/net/usb/usbnet.c:1589)<br /> process_one_work (kernel/workqueue.c:3322)<br /> bh_worker (kernel/workqueue.c:3405)<br /> tasklet_action (kernel/softirq.c:965)<br /> handle_softirqs (kernel/softirq.c:622)<br /> run_ksoftirqd (kernel/softirq.c:1076)<br /> ...<br /> <br /> skb_pull() already verifies that the requested length fits the buffer and<br /> returns NULL otherwise. Move it ahead of the copy and check its result, so<br /> a packet that overruns the received data is rejected before it is read.<br /> Well-formed frames, whose packets are fully present, are unaffected.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket<br /> <br /> smc_cdc_rx_handler() looks up the connection by token under the link<br /> group&amp;#39;s conns_lock, drops the lock, and then dereferences conn and the<br /> smc_sock derived from it, ending in sock_hold(&amp;smc-&gt;sk) inside<br /> smc_cdc_msg_recv(). No reference is held across the lock release.<br /> <br /> The only reference pinning the socket while the connection is<br /> discoverable in the link group is taken in smc_lgr_register_conn()<br /> (sock_hold) and dropped in __smc_lgr_unregister_conn() (sock_put), both<br /> under conns_lock. Once the handler drops conns_lock, a concurrent<br /> close() -&gt; smc_release() -&gt; smc_conn_free() -&gt; smc_lgr_unregister_conn()<br /> can drop that reference and free the smc_sock, so the handler&amp;#39;s later<br /> sock_hold() runs on freed memory:<br /> <br /> WARNING: lib/refcount.c:25 at refcount_warn_saturate<br /> Workqueue: rxe_wq do_work<br /> refcount_warn_saturate (lib/refcount.c:25)<br /> smc_cdc_msg_recv (net/smc/smc_cdc.c:430)<br /> smc_cdc_rx_handler (net/smc/smc_cdc.c:502)<br /> smc_wr_rx_tasklet_fn (net/smc/smc_wr.c:445)<br /> tasklet_action_common (kernel/softirq.c:938)<br /> handle_softirqs (kernel/softirq.c:622)<br /> Kernel panic - not syncing: panic_on_warn set<br /> <br /> Only SMC-R is affected. The SMC-D receive tasklet is stopped by<br /> tasklet_kill(&amp;conn-&gt;rx_tsklet) in smc_conn_free() before the connection<br /> is unregistered, so it cannot run concurrently with the free.<br /> <br /> Take the socket reference while still holding conns_lock, so the<br /> registration reference can no longer be the last one, and drop it once<br /> the handler is done.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: ndisc: fix NULL deref in accept_untracked_na()<br /> <br /> accept_untracked_na() re-fetches the inet6_dev with __in6_dev_get(dev)<br /> and dereferences idev-&gt;cnf.accept_untracked_na without a NULL check,<br /> even though its only caller ndisc_recv_na() already fetched and<br /> NULL-checked idev for the same device.<br /> <br /> Both reads of dev-&gt;ip6_ptr run in the same RCU read-side critical<br /> section, but a concurrent addrconf_ifdown() can clear dev-&gt;ip6_ptr<br /> between them: lowering the MTU below IPV6_MIN_MTU calls addrconf_ifdown()<br /> without the synchronize_net() that orders the unregister path, so the<br /> re-fetch returns NULL and oopses:<br /> <br /> BUG: KASAN: null-ptr-deref in ndisc_recv_na (net/ipv6/ndisc.c:974)<br /> Read of size 4 at addr 0000000000000364<br /> Call Trace:<br /> <br /> ndisc_recv_na (net/ipv6/ndisc.c:974)<br /> icmpv6_rcv (net/ipv6/icmp.c:1193)<br /> ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:479)<br /> ip6_input_finish (net/ipv6/ip6_input.c:534)<br /> ip6_input (net/ipv6/ip6_input.c:545)<br /> ip6_mc_input (net/ipv6/ip6_input.c:635)<br /> ipv6_rcv (net/ipv6/ip6_input.c:351)<br /> <br /> <br /> It is reachable by an unprivileged user via a network namespace.<br /> <br /> Pass the caller&amp;#39;s already validated idev instead of re-fetching it; the<br /> idev stays alive for the whole RCU critical section, so it is safe even<br /> after dev-&gt;ip6_ptr has been cleared.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: fix use-after-free of the discoverer in tipc_disc_rcv()<br /> <br /> bearer_disable() frees b-&gt;disc with tipc_disc_delete()&amp;#39;s plain kfree(),<br /> but tipc_disc_rcv() still dereferences b-&gt;disc in RX softirq under<br /> rcu_read_lock() (tipc_udp_recv -&gt; tipc_rcv -&gt; tipc_disc_rcv).<br /> <br /> L2 bearers are safe thanks to the synchronize_net() in<br /> tipc_disable_l2_media(), but the UDP bearer defers that call to the<br /> cleanup_bearer() workqueue, so the discoverer is freed with no grace<br /> period:<br /> <br /> BUG: KASAN: slab-use-after-free in tipc_disc_rcv (net/tipc/discover.c:149)<br /> Read of size 8 at addr ffff88802348b728 by task poc_tipc/184<br /> <br /> tipc_disc_rcv (net/tipc/discover.c:149)<br /> tipc_rcv (net/tipc/node.c:2126)<br /> tipc_udp_recv (net/tipc/udp_media.c:391)<br /> udp_rcv (net/ipv4/udp.c:2643)<br /> ip_local_deliver_finish (net/ipv4/ip_input.c:241)<br /> <br /> Freed by task 181:<br /> kfree (mm/slub.c:6565)<br /> bearer_disable (net/tipc/bearer.c:418)<br /> tipc_nl_bearer_disable (net/tipc/bearer.c:1001)<br /> <br /> The bearer is freed with kfree_rcu(); free the discoverer the same way.<br /> Add an rcu_head to struct tipc_discoverer and free it and its skb from an<br /> RCU callback.<br /> <br /> Because the RCU callback (tipc_disc_free_rcu) lives in module text, a<br /> call_rcu() that is still pending when the tipc module is unloaded would<br /> invoke a freed function. Add an rcu_barrier() to tipc_exit() after the<br /> bearer subsystem has been torn down, so all pending discoverer callbacks<br /> have run before the module text goes away.<br /> <br /> Reachable from an unprivileged user namespace: the TIPCv2 genl family is<br /> netnsok and its bearer commands have no GENL_ADMIN_PERM. Needs CONFIG_TIPC<br /> and CONFIG_TIPC_MEDIA_UDP.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: asymmetric_keys - fix OOB read in pefile_digest_pe_contents<br /> <br /> pefile_digest_pe_contents() computes the trailing-data hash length as<br /> pelen - (hashed_bytes + certs_size). A crafted PE can make the addition<br /> exceed pelen, causing the unsigned subtraction to underflow to ~4 GiB.<br /> This is passed to crypto_shash_update() which reads out of bounds and<br /> panics on unmapped vmalloc guard pages.<br /> <br /> BUG: unable to handle page fault for address: ffffc900038d8000<br /> Oops: Oops: 0000 [#1] SMP KASAN NOPTI<br /> RIP: 0010:sha256_blocks_generic (lib/crypto/sha256.c:152)<br /> Call Trace:<br /> <br /> __sha256_update (lib/crypto/sha256.c:208)<br /> crypto_sha256_update (crypto/sha256.c:142)<br /> verify_pefile_signature (crypto/asymmetric_keys/verify_pefile.c:436)<br /> kexec_kernel_verify_pe_sig (kernel/kexec_file.c:151)<br /> __do_sys_kexec_file_load (kernel/kexec_file.c:406)<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 /> <br /> Kernel panic - not syncing: Fatal exception<br /> <br /> Validate that the addition does not overflow and the result does not<br /> exceed pelen before the subtraction. Return -ELIBBAD on failure.

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.

An access issue was addressed with improved access restrictions. This issue is fixed in Safari 26.6, iOS 26.6 and iPadOS 26.6, macOS Tahoe 26.6, tvOS 26.6, visionOS 26.6, watchOS 26.6. An app may be able to read files outside of its sandbox.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bridge: cfm: reject invalid CCM interval at configuration time<br /> <br /> ccm_tx_work_expired() re-arms itself via queue_delayed_work() using<br /> the configured exp_interval converted by interval_to_us(). When<br /> exp_interval is BR_CFM_CCM_INTERVAL_NONE or out of range,<br /> interval_to_us() returns 0, causing the worker to fire immediately in<br /> a tight loop that allocates skbs until OOM.<br /> <br /> Fix this by validating exp_interval at configuration time:<br /> <br /> - Constrain IFLA_BRIDGE_CFM_CC_CONFIG_EXP_INTERVAL to the valid range<br /> [BR_CFM_CCM_INTERVAL_3_3_MS, BR_CFM_CCM_INTERVAL_10_MIN] in the<br /> netlink policy so userspace cannot set an invalid value.<br /> <br /> - Reject starting CCM TX in br_cfm_cc_ccm_tx() when exp_interval has<br /> not yet been configured (defaults to 0 from kzalloc).

Astro is a web framework for content-driven websites. In versions 1.0.0 through 4.0.18, the source.title and enclosure.type item fields in packages/astro-rss/src/index.ts are interpolated directly into XML template strings without XML-character escaping before being parsed by fast-xml-parser. Both fields are validated only as z.string(), placing no restriction on XML special characters. An attacker who controls these values can inject arbitrary XML into the generated RSS feed: a value containing " can break out of an attribute (as with enclosure.type), and a value containing can close an element early and inject additional nodes (as with source.title). This corrupts feed structure, injects false metadata (for example, a fake pointing to a malicious URL), and can cause feed readers to misparse or display attacker-controlled content. In SSR mode (output: &amp;#39;server&amp;#39;), the poisoned feed is served on every request to all subscribers. This issue has been fixed in version 4.0.19.

Astro is a web framework for content-driven websites. In versions 8.1.0 through 11.0.1, when trailingSlash: &amp;#39;always&amp;#39; is configured, the @astrojs/node standalone server&amp;#39;s static file handler appends a trailing slash to request paths and issues a 301 redirect. Paths beginning with /\ (slash-backslash) were not recognized as internal paths, so the handler would echo the raw path back in the Location header. Because browsers treat \ as / per the WHATWG URL specification, the resulting redirect could resolve to an external host. Preconditions for exploitation: trailingSlash: &amp;#39;always&amp;#39; must be set (non-default; the default is &amp;#39;ignore&amp;#39;), the request path must not have a file extension in its final segment, and an attacker must deliver the crafted link to a user. This issue has been fixed in version 11.0.2.

A race condition was addressed with improved checks. This issue is fixed in iOS 26.6 and iPadOS 26.6. An app may be able to modify protected parts of the file system.