Buffer Overflow

Spoofed or injected ICMP echo replies can steer mport's mirror-latency selection toward an attacker-chosen mirror and, if the reply carries IP options, shift the parsed ICMP header past the hardcoded offset used by ping() in libmport/ping.c, causing an out-of-bounds read. The flaw affects MidnightBSD mport releases prior to 2.7.8 and is only reachable by an unauthenticated attacker on the same adjacent network segment who can place visible ICMP traffic on-path while an mport client is actively probing mirrors (assessed CVSS:3.1 AV:A/AC:H/PR:N/UI:N/C:N/I:L/A:L; CVSS 4.0 base 2.3). Impact is low and confined to the transient probing window; no public exploit code and no confirmed active exploitation were identified at time of analysis, and the vendor has released version 2.7.8 as the fix.

In the Linux kernel, the following vulnerability has been resolved: HID: roccat: bound device-supplied profile index kone_keep_values_up_to_date() and kone_profile_activated() use an 8-bit, device-supplied profile value as an index into the 5-element kone->profiles[] array without a range check. A malicious USB device claiming the Roccat Kone id can send a switch-profile event (or a startup_profile read at probe) with an out-of-range value and make the driver read out of bounds; the result is exposed via the actual_dpi sysfs attribute. Reject out-of-range indices in both paths. This was found with static analysis and confirmed with the KUnit test added in the following patch (KASAN: slab-out-of-bounds).

In the Linux kernel, the following vulnerability has been resolved: usb: gadget: configfs: fix out-of-bounds read of qw_sign os_desc_qw_sign_show() passes OS_STRING_QW_SIGN_LEN as the input length to utf16s_to_utf8s(), but that argument counts UTF-16 code units while OS_STRING_QW_SIGN_LEN (14) is the byte size of qw_sign[]. The array holds only OS_STRING_QW_SIGN_LEN / 2 (7) code units, so the conversion reads up to 7 units (14 bytes) past the end of qw_sign[] into the following members of struct gadget_info when the stored signature fills the array without a NUL terminator, exposing those bytes through the configfs attribute. The store path halves the count for its input bound but passes the full byte count as the utf8s_to_utf16s() output limit; use the destination code-unit count in both directions.

In the Linux kernel, the following vulnerability has been resolved: usb: ljca: bound bank_num in ljca_enumerate_gpio() ljca_enumerate_gpio() reads desc->bank_num from the device and loops valid_pin[i] = get_unaligned_le32(...) for i < bank_num. valid_pin[] holds only LJCA_MAX_GPIO_NUM / 32 = 2 entries. Two checks run before the loop. The reply length must match struct_size(desc, bank_desc, bank_num). The product pins_per_bank * bank_num must not exceed LJCA_MAX_GPIO_NUM. Neither one bounds bank_num against the size of valid_pin[]. The reply is capped at LJCA_MAX_PAYLOAD_SIZE (60) bytes, so the struct_size check limits bank_num to 9. A device that reports bank_num 9 with pins_per_bank 7 still passes both checks. gpio_num is 63 and the reply is 56 bytes. The loop then writes nine u32 into the two entry array and overruns valid_pin[] on the stack. A broken or malicious LJCA device can therefore overflow the stack. Reject a bank_num that does not fit valid_pin[].

In the Linux kernel, the following vulnerability has been resolved: fs/resctrl: Fix UAF from worker threads when domains are removed The mbm_handle_overflow() and cqm_handle_limbo() workers read event counters and may sleep while doing so. They are scheduled via delayed_work embedded in struct rdt_l3_mon_domain. Architecture allocates and frees these domains from CPU hotplug callbacks under cpus_write_lock(), and the workers acquire cpus_read_lock() to keep the domain alive across their access. A use-after-free can occur when a worker is blocked waiting for cpus_read_lock() while the hotplug core holds cpus_write_lock(): the architecture frees the rdt_l3_mon_domain that contains the worker's work_struct. When the worker unblocks, the container_of() it performs on the embedded work pointer dereferences freed memory. Drop cpus_read_lock() from the workers and instead drain pending and in-flight work synchronously before the architecture can free the domain. Since architecture offlines the domain under cpus_write_lock() after it has been unlinked from the RCU list and a grace period has elapsed, no new work can be scheduled. The cancel only needs to wait out existing work. Drop rdtgroup_mutex during CPU offline around cancel_delayed_work_sync() so that a worker waiting on the mutex can complete before re-pinning the work on a different CPU. When offlining a CPU the architecture may iterate over resources in any order. For example, the MBA control domain may be offlined before or after a corresponding L3 monitor domain. Ensure that resctrl fs cancels the workers no matter what order the architecture offlines the domains.

In the Linux kernel, the following vulnerability has been resolved: cxl/features: Clamp Get Feature output size to the remaining buffer cxl_get_feature() reads a feature in a loop but passes a fixed size_out as the output capacity every iteration. On the last partial iteration the buffer has less room left, so a device that returns more than asked can overflow feat_out. Use the per-iter size data_to_rd_size, which already tracks the remaining room, as the output capacity.

In the Linux kernel, the following vulnerability has been resolved: UDF symlink pathComponent header OOB read udf_symlink_filler() can enter udf_pc_to_char() with a partial pathComponent header. Validate that enough input remains for a complete pathComponent header before accessing it. Reject malformed symlink data that would otherwise make udf_pc_to_char() perform an out-of-bounds read.

In the Linux kernel, the following vulnerability has been resolved: ext4: validate readdir offset before accessing dirent A corrupted directory can trigger the following KASAN report when ext4_readdir() resumes from an invalid position: BUG: KASAN: use-after-free in __ext4_check_dir_entry+0x5ef/0x820 Read of size 2 at addr ffff88810a646000 by task repro_linear/509 Call Trace: <TASK> dump_stack_lvl+0x53/0x70 print_report+0xd0/0x630 kasan_report+0xce/0x100 __ext4_check_dir_entry+0x5ef/0x820 ext4_readdir+0xcde/0x2b70 iterate_dir+0x1a1/0x520 __x64_sys_getdents64+0x12b/0x220 do_syscall_64+0xf9/0x540 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> KASAN reports use-after-free because the out-of-bounds access lands in an adjacent freed page. The directory buffer itself is still referenced. ext4_dir_llseek() invalidates the directory cookie so that ext4_readdir() rescans directory entries from the start of the block. The rescan checks only the lower bound of rec_len before advancing. A corrupted rec_len can therefore place the offset where the block has insufficient space for a complete directory entry. The rescan itself may dereference that truncated entry, or the main loop may pass it to __ext4_check_dir_entry(). The latter reads de->rec_len before validating the range. For example: block offset 0 4092 4096 |---- de1.rec_len = 4092 -----|----| de2.inode | de2.rec_len ^ OOB, reported as UAF de2 starts at offset 4092 in this 4 KiB block. Its four-byte inode fits in the block, but its rec_len starts at offset 4096 and crosses the boundary. The minimum safe length is inode-dependent. Encrypted and casefolded directory entries need eight additional hash bytes, while a valid metadata checksum tail is only 12 bytes. Cache the metadata checksum feature state and derive the minimum directory entry length from the on-disk format. Use it to bound both the rescan and the offset passed to the main loop. Report an offset in a truncated block tail and skip the remainder of the block, while continuing to accept an offset exactly at the block boundary.

In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix stack out-of-bounds read in cc_params debugfs get_param() reads a congestion parameter as a u32 but formats it with the signed "%d" into an 11-byte stack buffer. A value with bit 31 set, such as 0x80000000, renders as "-2147483648\n" whose full length is 12. snprintf() stores only 11 bytes yet returns 12, so simple_read_from_buffer() treats 12 bytes as valid and reads one byte past lbuf[]. Size the buffer for the widest unsigned decimal, format with "%u" to match the u32, and use scnprintf() so the length passed to simple_read_from_buffer() reflects the bytes actually stored.

In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Add vm_bind region with kbo range overlap check When a VM is created, caller has to specify the range of the address space carve-out set aside for mapping kernel BO's. That means vm_bind mappings of UM-exposed BO's should not intersect with that region, but at the moment we're not checking this. At first, I thought of giving these values to drm_gpuvm_init() through its reserve_{offset, range} arguments, but it turns out that is meant for VM address spans that are not managed through the usual drm_gpuvm split/merge circuit, so storing the end of the user VA range at VM creation time and doing a quick check in the vm_bind ioctl path was the simplest workaround. The new check also makes sure vm_bind range doesn't overflow the size of a 64-bit unsigned integer. That was already being done further down the call stack inside drm_gpuvm_sm_map -> drm_gpuvm_range_valid, but it's best to fail early in the driver before GPUVM functions are invoked so that we won't waste time allocating vm_bind context resources.

In the Linux kernel, the following vulnerability has been resolved: i3c: dw: avoid shift-out-of-bounds when DAA assigns no devices On an empty bus ENTDAA assigns nothing, so cmd->rx_len (the count of addresses left unassigned) equals master->maxdevs. The GENMASK() index master->maxdevs - cmd->rx_len - 1 then becomes -1, which trips up UBSAN. This happens every time on boot on a Gigabyte/AMD server: UBSAN: shift-out-of-bounds in drivers/i3c/master/dw-i3c-master.c:905:12 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 7 UID: 0 PID: 963 Comm: (udev-worker) Not tainted 7.0.11-200.fc44.x86_64 #1 PREEMPT(lazy) Hardware name: Giga Computing E163-Z34-AAH1-000/MZ33-DC1-000, BIOS R32_F45 04/01/2026 Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_shift_out_of_bounds.cold+0xd7/0x1ab dw_i3c_master_daa.cold+0x1b/0x96 [dw_i3c_master] i3c_master_do_daa_ext.part.0+0x3e/0xf0 [i3c] Skip the mask when no new device was assigned.

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: fix out-of-bounds access in mmio copy helpers mt76_mmio_write_copy() and mt76_mmio_read_copy() iterate up to ALIGN(len, 4), so a length that is not a multiple of four reads past the source buffer (write_copy) or writes past the destination (read_copy). Copy the aligned body in the loop and handle the remaining tail through a 4-byte bounce buffer, keeping the register access width unchanged.

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix out-of-bounds link array access in mt7996_tx() When mac80211 leaves the link unspecified, mt7996_tx() substitutes the primary link id of the station or vif. That value is IEEE80211_LINK_UNSPECIFIED (0xf) until the first link has been added, and it is then used unchecked to index vif->link_conf[], mvif->mt76.link[] and sta->link[], all of which hold IEEE80211_MLD_MAX_NUM_LINKS (15) entries. Clamp the primary link id to the default link before using it, and use the clamped value for the link_sta fallback as well.

In the Linux kernel, the following vulnerability has been resolved: ocfs2/cluster: keep heartbeat local node stable o2nm_node_local_store() handles local=0 by stopping o2net and setting cl_local_node to O2NM_INVALID_NODE_NUM, but it leaves cl_has_local set. That stale state makes o2nm_this_node() return 255, blocks a later local=1 attempt with -EBUSY, and can feed 255 to heartbeat users that call o2nm_this_node() dynamically. Clearing cl_has_local is required when the local node is reset. But heartbeat threads can still be running at that point. They pin the local node config item at startup, yet o2hb_do_disk_heartbeat() and thread teardown re-read o2nm_this_node() for the local slot and for o2nm_undepend_this_node(). Once local=0 has cleared the live local-node state, those dynamic reads return O2NM_MAX_NODES, which is also the invalid node number 255. Store the local node number in the heartbeat region when the region starts. Use that stable node for heartbeat slot writes/checks, negotiation messages, and the final configfs undepend. Stop the heartbeat loop when the current local node no longer matches the stored node, and clear cl_has_local together with cl_local_node in the local=0 path so nodemanager state matches node removal. Validation reproduced this kernel report: KASAN slab-out-of-bounds in o2hb_do_disk_heartbeat+0x372/0xb30 RIP: 0010:memset+0xf/0x20 Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xd0/0x630 o2hb_do_disk_heartbeat+0x372/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079) srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x188/0x2f0 kasan_report+0xe4/0x120 o2hb_do_disk_heartbeat+0x5/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079) o2hb_thread+0x14e/0x770 kthread_affine_node+0x139/0x180 lockdep_hardirqs_on_prepare+0xda/0x190 trace_hardirqs_on+0x18/0x130 kthread+0x19d/0x1e0 ret_from_fork+0x37a/0x4d0 __switch_to+0x2d5/0x6f0 ret_from_fork_asm+0x1a/0x30

In the Linux kernel, the following vulnerability has been resolved: remoteproc: fix OOB read via signed offset in rsc_table_for_each_entry() table->offset[i] is a u32 from firmware, but was stored into a signed int. A crafted offset like 0xFFFFFFF0 becomes -16, placing hdr 16 bytes before the table buffer. The subsequent avail check was bypassed because the negative int was promoted to a large size_t in the expression "table_sz - offset - sizeof(*hdr)", yielding a large positive avail and letting the out-of-bounds hdr->type read proceed undetected. Store the offset as u32 and validate it with unsigned comparisons before any pointer arithmetic.

In the Linux kernel, the following vulnerability has been resolved: cpufreq: imx6q: fix out-of-bounds write when probed more than once imx6_soc_volt is allocated fresh on every probe, sized to the number of ARM OPPs: imx6_soc_volt = devm_kcalloc(cpu_dev, num, sizeof(*imx6_soc_volt), GFP_KERNEL); but it is filled through soc_opp_count, which has static storage and is never reset. A second bind after an unbind keeps indexing from where the first one stopped, and writes past the end of the new array. Unbinding and rebinding the driver on qemu's mcimx6ul-evk, under KASAN: BUG: KASAN: slab-out-of-bounds in imx6q_cpufreq_probe+0x3b0/0xa34 Write of size 4 at addr c5e90480 by task binder/73 imx6q_cpufreq_probe from platform_probe+0x88/0xe4 platform_probe from really_probe+0x108/0x384 bind_store from kernfs_fop_write_iter+0x1b4/0x28c The write lands one u32 past the end of the allocation. soc_opp_count is only read a few lines below the loop that fills it, so it never needed static storage. Make it a local.

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MSFT: validate evt_prefix_len against the response length read_supported_features() only checks that the response covers the fixed part of struct msft_rp_read_supported_features, which is 11 bytes: if (skb->len < sizeof(*rp)) { bt_dev_err(hdev, "MSFT supported features length mismatch"); goto failed; } evt_prefix[] is a flexible array member and rp->evt_prefix_len is an unvalidated u8 taken straight out of that response, so msft->evt_prefix = kmemdup(rp->evt_prefix, rp->evt_prefix_len, GFP_KERNEL); copies up to 255 bytes from a reply that may have carried none of them. What is copied is data the controller never sent, and it is then used to match incoming vendor events in msft_vendor_evt(). This is not an out-of-bounds access. An skb data allocation always has at least SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) bytes past the payload, which is more than the 255 byte maximum, so the read stays inside the allocation and KASAN does not report it. It is still a read of bytes the host was never given, with the length fully controlled by the controller. Reject a response that is too short for the prefix it declares. Verified with an emulated controller over /dev/vhci on a KASAN kernel, with vhci made to advertise an MSFT opcode the way btintel, btqca, btmtk and btrtl do unconditionally. A reply of exactly 11 bytes declaring evt_prefix_len = 255 reaches kmemdup and copies 255 bytes ("skb->len=11 evt_prefix_len=255", with the copied buffer dumped); since the reply ends at the fixed part, all 255 come from past the end of the response. No KASAN report is produced, as expected from the allocation slack described above. With this patch the response is rejected with "MSFT event prefix length mismatch" and msft->evt_prefix is left unset.

In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: avoid userspace overflow on invalid optlen nfc_llcp_getsockopt() casts optval to (u32 __user *) for put_user(), so the kernel always stores 4 bytes regardless of the caller-supplied optlen. The existing min_t(u32, len, sizeof(u32)) only clamps the length reported back to userspace; it does not constrain the store. A call with optlen < 4 therefore writes past the user buffer, violating the getsockopt(2) contract for all five supported optnames. Reject any call with optlen < sizeof(u32) up front. 'len' is int, so a plain size comparison would promote a negative optlen to size_t and slip past the check; an explicit 'len < 0' test is added first to catch negative values before the size compare.

In the Linux kernel, the following vulnerability has been resolved: nvmet: fix max_qid race between configfs and controller allocation The function nvmet_subsys_attr_qid_max_store() can race against nvmet_alloc_ctrl() when a subsystem's max_qid limit is modified. Suppose max_qid is currently 64. If nvmet_alloc_ctrl() executes: ctrl->sqs = kzalloc_objs(struct nvmet_sq *, subsys->max_qid + 1); and at this exact point, a userspace process changes max_qid to 128, nvmet_subsys_attr_qid_max_store() will set the new max_qid value. It attempts to delete active controllers to force a reconnect, but the new controller won't be deleted because it hasn't been added to the subsys->ctrls list yet. nvmet_alloc_ctrl() then proceeds and adds the new controller to the subsys->ctrls list. Later, when nvmet_install_queue() is called, it will see max_qid set to 128, but the memory allocated for sqs is only sized for 64 entries. This results in a KASAN out-of-bounds warning and potential memory corruptions. Fix this by protecting the queue allocations and list insertion in nvmet_alloc_ctrl() with down_read(&nvmet_config_sem). Because nvmet_subsys_attr_qid_max_store() acquires down_write(&nvmet_config_sem) to modify the attribute, this safely prevents the configfs writer from modifying max_qid during controller creation. Copy the max_qid from the subsystem to the controller's structure during the allocation; ctrl->max_qid never changes as long as the controller remains in LIVE state, so this will prevent similar race conditions.

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix integer overflow in MFT cluster validation In ntfs_init_from_boot(), the boot sector's MFT cluster numbers are validated against the volume size with: if (mlcn * sct_per_clst >= sectors || mlcn2 * sct_per_clst >= sectors) goto out; mlcn and mlcn2 are u64 fields read directly from the boot sector. sct_per_clst is bounded above by 4096 (true_sectors_per_clst() plus the is_power_of_2() check below it), but the multiplication is done in u64 and wraps when mlcn (or mlcn2) is large enough -- e.g. mlcn near 2^62 with sct_per_clst == 4 wraps to 0, which compares below any non-zero 'sectors', so the check is bypassed and the malformed record is accepted. The accepted mlcn is then used unchanged in sbi->mft.lbo = mlcn << cluster_bits; In practice the resulting reads fail at the block layer (sb_bread() returns NULL via grow_buffers()'s check_mul_overflow() guard), so today this manifests as mount failing in odd places rather than as something more dangerous, but the validation step is still wrong and there is no reason for callers to rely on the block layer to catch a value that should never have been accepted in the first place. Use check_mul_overflow() to compute the two sector positions and fail the mount if either multiplication wraps; this preserves the existing semantics (mlcn * sct_per_clst >= sectors) instead of switching to division (mlcn >= sectors / sct_per_clst), which would tighten the check at edge cases where 'sectors' is not a multiple of sct_per_clst. The check_*_overflow() style is the one ntfs3 already uses for similar on-disk arithmetic in fs/ntfs3/run.c.

In the Linux kernel, the following vulnerability has been resolved: null_blk: serialize configfs attribute stores with the lock The NULLB_DEVICE_ATTR _store takes no lock: apply_fn attributes (submit_queues, poll_queues) get dev->NAME written again after apply_fn returns, outside its lock; APPLY=NULL attributes are entirely lockless. configfs only serializes stores per-open-file, so concurrent stores on separate fds race. For apply_fn attributes, once one store's apply_fn has reconfigured the hardware, a second (losing) store can still overwrite dev->NAME afterwards. This leaves dev->submit_queues out of sync with the live queue count, which is later caught by the WARN_ON_ONCE() in null_map_queues(). For !apply_fn attributes, power_store()'s null_add_dev() validates and builds the device under "lock" but only sets CONFIGURED afterwards. A store slipping in during this window can change a field mid-setup -- for example, zone_nr_conv can be pushed above nr_zones after it has already been clamped, leading to an out-of-bounds dev->zones[] access. Take "lock" in the macro around the apply_fn call, the CONFIGURED test and the field write, and move it out of nullb_apply_submit_queues()/ nullb_apply_poll_queues() so both paths are covered once. This serializes stores with power_store's setup and with each other.

In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate ipc response length before dereferencing its fields ipc_validate_msg() computes the expected message size by reading length fields out of the response buffer supplied by the userspace ksmbd daemon (payload_sz, session_key_len, ngroups, ...). Those fields are read before the buffer is verified to be large enough to contain the struct they belong to, so a short response makes the read land past the end of the allocation. handle_response() sizes entry->response purely from the netlink attribute length (nla_len()) and only guards the leading handle read, so the daemon can install a response as small as the kmalloc-8 object seen below. When ipc_msg_send_request() then calls ipc_validate_msg() for a KSMBD_EVENT_RPC_REQUEST, the cast to struct ksmbd_rpc_command reads resp->payload_sz at offset 8 of an 8-byte allocation: [ 3697.841381] ================================================================== [ 3697.844099] BUG: KASAN: slab-out-of-bounds in ipc_msg_send_request+0x763/0x800 [ 3697.846604] Read of size 4 at addr ffff888105f95910 by task kworker/4:3/20682 [ 3697.849061] [ 3697.849801] CPU: 4 UID: 0 PID: 20682 Comm: kworker/4:3 Not tainted 7.2.0-rc3-next-20260717-virtme #117 PREEMPT(lazy) [ 3697.850077] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 3697.850303] Workqueue: ksmbd-io handle_ksmbd_work [ 3697.850592] Call Trace: [ 3697.850794] <TASK> [ 3697.850952] __dump_stack+0x21/0x60 [ 3697.851239] dump_stack_lvl+0xc2/0x100 [ 3697.851528] print_address_description+0x77/0x200 [ 3697.851816] ? ipc_msg_send_request+0x763/0x800 [ 3697.852024] print_report+0x58/0x70 [ 3697.852316] kasan_report+0x117/0x150 [ 3697.852585] ? down_write+0x146/0x1f0 [ 3697.852809] ? ipc_msg_send_request+0x763/0x800 [ 3697.853082] ipc_msg_send_request+0x763/0x800 [ 3697.853385] ? __pfx_ipc_msg_send_request+0x10/0x10 [ 3697.853604] ? kasan_unpoison+0x48/0x70 [ 3697.853936] ? __pfx___up_read+0x10/0x10 [ 3697.854221] ksmbd_rpc_ioctl+0x380/0x520 [ 3697.854542] ? __pfx_ksmbd_rpc_ioctl+0x10/0x10 [ 3697.854757] ? kasan_unpoison+0x48/0x70 [ 3697.854962] ? copy_from_kernel_nofault+0x32c/0x4e0 [ 3697.855166] ? kasan_unpoison+0x48/0x70 [ 3697.855416] fsctl_pipe_transceive+0x139/0x7a0 [ 3697.855705] ? __pfx_copy_from_kernel_nofault+0x10/0x10 [ 3697.855937] ? __pfx_fsctl_pipe_transceive+0x10/0x10 [ 3697.856388] ? __sanitizer_cov_trace_switch+0x7b/0x140 [ 3697.856620] smb2_ioctl+0x1141/0x3420 [ 3697.856994] ? __pfx_smb2_ioctl+0x10/0x10 [ 3697.857182] ? get_smb2_cmd_val+0xe3/0x1c0 [ 3697.857655] handle_ksmbd_work+0x9ad/0x15e0 [ 3697.858034] ? __pfx_handle_ksmbd_work+0x10/0x10 [ 3697.858251] ? lock_release+0xf7/0x360 [ 3697.858466] ? process_scheduled_works+0x954/0x1600 [ 3697.858698] ? process_scheduled_works+0x954/0x1600 [ 3697.858905] process_scheduled_works+0xc22/0x1600 [ 3697.859368] ? __pfx_process_scheduled_works+0x10/0x10 [ 3697.859637] ? __pfx_assign_work+0x10/0x10 [ 3697.859896] ? lock_is_held_type+0x7b/0x110 [ 3697.860146] worker_thread+0x975/0xee0 [ 3697.860524] ? __pfx_do_raw_spin_lock+0x10/0x10 [ 3697.860830] ? __kthread_parkme+0x21e/0x260 [ 3697.861105] kthread+0x3a6/0x490 [ 3697.861423] ? __pfx_worker_thread+0x10/0x10 [ 3697.861643] ? __pfx_kthread+0x10/0x10 [ 3697.861878] ret_from_fork+0x55a/0xa20 [ 3697.862194] ? __pfx_ret_from_fork+0x10/0x10 [ 3697.862480] ? __pfx_kthread+0x10/0x10 [ 3697.862714] ret_from_fork_asm+0x1a/0x30 [ 3697.862965] </TASK> [ 3697.863039] [ 3697.938882] Allocated by task 20761: [ 3697.940257] kasan_save_track+0x3e/0x80 [ 3697.941782] __kasan_kmalloc+0x72/0x90 [ 3697.943228] __kvmalloc_node_noprof+0x3e9/0x6a0 [ 3697.944948] handle_generic_event+0x59b/0x750 [ 3697.946592] genl_family_rcv_msg_doit+0x3d6/0x560 [ 3697.946977] genl_rcv_msg+0x67c/0x900 [ 3697.947224] netlink_rcv_skb+0x286/0x580 [ 3697.947488] genl_rcv+0x2d/0x80 [ 3 ---truncated---

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btmtksdio: Fix out-of-bounds DMA read in the TX path btmtksdio_tx_packet() rounds the transfer size up to the SDIO block size of 256 bytes, but hands the host controller the SKB buffer as is: err = sdio_writesb(bdev->func, MTK_REG_CTDR, skb->data, round_up(skb->len, MTK_SDIO_BLOCK_SIZE)); Only skb->len bytes hold packet data, so the controller reads up to 255 bytes of uninitialised memory and sends it to the device over the SDIO bus. Depending on how much tailroom slack the SKB allocation happens to carry, that read can also extend past the end of the buffer. Compute the padded length up front, ensure the SKB has tailroom for it, and zero-fill the padding with skb_put_zero(). skb->len then covers the padding, so sdio_writesb() no longer needs to round up. byte_tx keeps counting the header and the payload only, and the error path restores the SKB so that the caller can requeue it. Writing behind skb->tail is only safe because the driver owns the buffer, which "Bluetooth: btmtksdio: Take exclusive ownership of the SKB before TX" ensures.

In the Linux kernel, the following vulnerability has been resolved: net/sched: fq: add overflow bounds to quantum and initial quantum fq_init() computes quantum = 2 * psched_mtu() and initial_quantum = 10 * psched_mtu() with no overflow check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000; the 2 * and 10 * multiplications wrap to 0 in 32-bit arithmetic, so q->quantum == 0. Then in fq_dequeue() the credit-refill loop adds 0 to f->credit (which stays <= 0) and goto begin loops forever under the qdisc lock, creating a soft lockup. Clamp psched_mtu() to [1, 1 << 20] before multiplying so the product cannot wrap, then cap the result at 1 << 20, matching the bound already enforced on TCA_FQ_QUANTUM in fq_change(). Conditions to recreate the bug: a device whose MTU (plus hard_header_len) is large enough that 2 * psched_mtu() wraps (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.

In the Linux kernel, the following vulnerability has been resolved: net/sched: hhf: clamp quantum before hhf_change() to avoid overflow hhf_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) with no overflow check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes weight * quantum overflow the signed deficit in hhf_dequeue(), spinning forever. Clamp q->quantum before hhf_change() so both the opt and !opt paths see a sane quantum. Without this, bare "tc qdisc add ... hhf" succeeds with a clamped quantum but "tc qdisc add ... hhf limit 1000" (any option present) fails with -EINVAL because hhf_change() re-validates the unclamped default (sch_hhf.c:559). 256 matches fq_codel's floor and is a sane minimum for a DRR quantum. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.

In the Linux kernel, the following vulnerability has been resolved: net/sched: sfq: clamp quantum to avoid signed overflow soft lockup sfq_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) (unsigned). A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, so slot->allot = INT_MIN and INT_MIN + INT_MIN toggles between INT_MIN and 0 forever, spinning sfq_dequeue() under the qdisc lock. Clamp the quantum to [256, 1 << 20] so the refill loop terminates. The lower bound also covers q->quantum == 0 (psched_mtu() returning 0), which spins sfq_dequeue() identically. sfq_change() already rejects a negative quantum, so only the init path was exposed. Conditions to recreate the bug: a device whose MTU (plus hard_header_len) wraps psched_mtu() into the sign bit (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.

In the Linux kernel, the following vulnerability has been resolved: virtio-net: Ensure that TCP packets don't overflow gso_segs The user can specify any gso_size in a packet crafted with an AF_PACKET PACKET_VNET_HDR socket, even smaller than TCP_MIN_GSO_SIZE = 8. At the same time, GSO_MAX_SIZE = 8 * GSO_MAX_SEGS = 8 * 65535. When the user crafts a packet with gso_size < 8, there is a risk for partial GSO to overflow the 16-bit gso_segs field when dividing the SKB length by gso_size. Adjust gso_size of TCP packets to be at least TCP_MIN_GSO_SIZE = 8. Keep gso_size of UDP GSO packets, as gso_size=1 is valid and explicitly tested at tools/testing/selftests/net/tun.c:649.

In the Linux kernel, the following vulnerability has been resolved: usb: atm: usbatm: fix invalid ci_range initialization syzbot reported a shift-out-of-bounds in __vcc_connect(): UBSAN: shift-out-of-bounds in net/atm/common.c:382:32 shift exponent -1 is negative CPU: 0 UID: 0 PID: 5987 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/05/2026 Call Trace: <TASK> dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 ubsan_epilogue+0xa/0x30 lib/ubsan.c:233 __ubsan_handle_shift_out_of_bounds+0x36d/0x400 lib/ubsan.c:494 __vcc_connect+0x14b4/0x19c0 net/atm/common.c:382 vcc_connect+0x328/0x8f0 net/atm/common.c:498 pvc_bind+0x272/0x380 net/atm/pvc.c:52 __sys_bind+0x2e3/0x410 net/socket.c:1976 __x64_sys_bind+0x7a/0x90 net/socket.c:1979 ... ATM device ci_range fields (vpi_bits and vci_bits) represent the number of bits supported for VPI and VCI addressing on the device. net/atm/common.c directly uses these fields as bit shift counts: vpi >> dev->ci_range.vpi_bits vci >> dev->ci_range.vci_bits 1 << vcc->dev->ci_range.vpi_bits 1 << vcc->dev->ci_range.vci_bits usbatm_atm_init() sets ci_range.vpi_bits and ci_range.vci_bits to ATM_CI_MAX (-1), which is defined in <uapi/linux/atmdev.h> as a sentinel value for userspace ATM_SETCIRANGE requests, not a valid bit count. Shifting by -1 is undefined behavior and triggers UBSAN warnings. ATM UNI cell headers allow up to 8 bits for VPI (0..255) and 16 bits for VCI (0..65535). Initialize vpi_bits to 8 and vci_bits to 16, as done by solos-pci.

Out-of-bounds write in vgmstream (through r2117) lets an attacker corrupt heap memory when a crafted EA SCHl audio file is decoded, triggered inside vadpcm_read_coefs_be in src/coding/vadpcm_decoder.c via a manipulated coefficient entry/entries count. The vulnerable code path is reached from any application embedding the library - media players and game-audio converters that use vgmstream - but exploitation requires the victim to open or load the malicious file (passive user interaction); there is no network service to hit and no public exploit identified at time of analysis. The vendor rates it CVSS 4.0 5.3, while this assessment maps it to CVSS 3.1 AV:L/AC:L/PR:N/UI:R with Low confidentiality, integrity and availability impact and no demonstrated path to code execution.

Memory corruption in Qualcomm Snapdragon platforms allows an attacker who already holds a low-privileged local foothold on the device to corrupt memory by feeding oversized input into a copy routine that exceeds expected allocation limits, giving high impact to confidentiality, integrity, and availability of the affected component. The flaw is not remotely exploitable on its own: exploitation requires local access with low privileges (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, base 7.8) - for example a malicious or compromised application able to reach the vulnerable code path - and no user interaction is needed. No public exploit code has been identified at time of analysis, and no CISA KEV listing or EPSS score was provided; the referenced Qualcomm September 2026 security bulletin is the authoritative source for the specific affected chipsets and fixed versions.

Heap buffer overflow in the FAT-filesystem parsing code paths identified as _init_fats and fat_table_read - most likely the libparted FAT module used by GNU Parted and its fatresize component - allows memory corruption when a malformed FAT volume is parsed. The issue is local in scope (AV:L) and requires user interaction (UI:R): a victim must open a crafted disk/partition image or insert a removable device whose FAT table has been manipulated, and a parsing path (resize, inspection, or a mount helper such as udisks auto-mount handling) must actually read that volume. The assessed vector CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H indicates unauthenticated local attackers can achieve high confidentiality, integrity, and availability impact if the bug is reliably triggered, though whether the overflow yields code execution rather than a crash is unproven and impact is amplified only if the parser runs with elevated privileges. No CISA KEV entry and no public exploit code have been identified - no public exploit identified at time of analysis - and no EPSS score was supplied; the exact affected package, version range, and default-configuration reachability remain unconfirmed from the available data.

Heap buffer overflow in an unspecified Ubuntu utility's duplicate_legacy_root_dir function can lead to high confidentiality, integrity, and availability impact when a local attacker convinces a user or automated job to process a crafted input, such as a malicious filesystem image or legacy-format file. The assessed CVSS vector (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) indicates local access, no privileges required, and user interaction as the primary limiting factor, but the exact product, affected versions, and trigger condition are unconfirmed due to the record lacking product name, CWE, EPSS, KEV, and POC data. No public exploit identified at time of analysis.

An out-of-bounds read in GPAC 26.08-DEV (the wait_for_header_and_parse routine in src/utils/downloader.c) can disclose memory contents or crash the process when the downloader parses a crafted or empty Content-Range value in an HTTP response header. The victim must actively initiate a download from a malicious or man-in-the-middle server for the malformed header to reach the parser; the vulnerable code path is in GPAC's generic HTTP/fetch machinery rather than a media-decoding path, and the consequence is limited to information disclosure or a crash - no write primitive or code execution is demonstrated. Publicly available exploit code exists (the issue is tracked publicly on the GPAC GitHub project) but the flaw is not confirmed actively exploited (CISA KEV), and the assessed impact is low on both the availability and confidentiality axes.

Opening a specially crafted BIFS or LASeR scene file in GPAC 26.08-DEV can trigger a use-after-free in the scene-graph command handler, crashing the application. Only local exploitation is possible: the victim must load attacker-supplied media in a vulnerable pre-abi-16.24 build, there is no network-reachable trigger, and impact is limited to availability (denial of service) with no confidentiality or integrity effect. Publicly available exploit code exists (referenced PoC archive on GitHub), and the underlying flaw is remediated by the upstream fix released in abi-16.24 (commit e34f4ba); despite the public PoC this is a low-priority, low-real-risk issue given the local, user-interaction-dependent attack path.

Heap-based buffer overflow in GPAC 26.07.0's Remotery-style WebSocket remote-monitoring handler (rmt_client_handle_ws_frame in src/utils/rmt_ws.c) lets remote attackers corrupt heap memory by sending a WebSocket frame whose advertised payload_size is manipulated, since the value is trusted when computing how much extra data to read. The CVSS 4.0 score is 6.9 (Medium) with vector AV:N/AC:L/AT:N/PR:N/UI:N and the E:P exploit-maturity flag; an independent assessment rates the memory-safety consequence more severely (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H), reflecting that availability impact can be complete once the interface is reached. Publicly available exploit code exists - a Python PoC (poc_rmt_ws_malicious_frame.py) is attached to the upstream GitHub issue - but there is no confirmation of active exploitation (no CISA KEV listing). The practical limiting factor is exposure: the rmt_ws handler must be compiled in, enabled, and network-reachable, which is not the default posture for typical GPAC/MP4Box usage.

Heap use-after-free in the HDF5 library (The HDF Group, all versions before 2.3.0) is triggered when an application such as h5dump reads a dataset whose compound datatype contains floating-point members, allowing a crafted .h5 file to crash the parsing process and, depending on heap layout and allocator behaviour, potentially corrupt memory further. Exploitation requires the victim to open a malicious file locally (local vector, mandatory user interaction, no authentication needed), so it is not remotely reachable on its own. No public exploit code has been identified at time of analysis and the issue is not in CISA KEV; the vendor's own CVSS 4.0 base of 4.6 aligns with the independent assessment that the reliably demonstrated impact is a crash rather than proven code execution.

An out-of-bounds read in the userspace SMB daemon of MikroTik RouterOS before 7.24 allows unauthenticated remote attackers to read memory beyond the end of the request buffer by sending a minimal SMB1 SessionSetupAndX frame with a crafted uniPwdLen field value. The over-read occurs in the SessionSetupAndX handler before any credential validation, so no authentication or user interaction is required, though exploitation is only possible when the non-default SMB service is enabled and reachable on the network. Vendor-released patch: RouterOS 7.24; there is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis, and the independent assessment rates the impact as limited memory disclosure (VC:L) with possible service disruption (VA:L) rather than code execution or full memory disclosure.

In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: Fix missing lock required to access list of ap_matrix_mdev objects In order to traverse or add/remove ap_matrix_mdev objects in the matrix_dev->mdev_list, the matrix_dev->guests_lock mutex must be held. There are two functions that access the list without holding the mutex: vfio_ap_mdev_probe function ~~~~~~~~~~~~~~~~~~~~~~~~~~~ The vfio_ap_mdev_probe function uses the matrix_dev->mdevs_lock mutex to guard the add of a newly created ap_matrix_mdev object to the matrix_dev->mdev_list. This mutex does not protect list access; its purpose is to guard against concurrent access to fields contained in an ap_matrix_mdev object. This could lead to kernel memory corruption or use-after-free if another mdev is created or removed concurrently. The adding of an ap_matrix_mdev object to matrix_dev->mdev_list is now guarded by the matrix_dev->guests_lock which is the correct way to protect against concurrent mdev_list access. Also removed the following two lines of code because the matrix_mdev is allocated via vfio_alloc_device macro which uses kzalloc, so req_trigger and cfg_chg_trigger are already zero-initialised when the struct is allocated before the call to vfio_register_emulated_iommu_dev. This prevents a window whereby these triggers are set to NULL after the device is exposed to userspace. matrix_mdev->req_trigger = NULL; matrix_mdev->cfg_chg_trigger = NULL; vfio_ap_mdev_for_queue function ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The status_show function that supports display of the status attribute of the devices in /sys/bus/ap/devices calls the vfio_ap_mdev_for_queue function which iterates the matrix_dev->mdev_list to find the object representing the queue device whose status is to be displayed. In order to traverse this list, the matrix_dev->guests_lock mutex must be held. To fix this, the guests_lock mutex is taken prior to taking the matrix_dev->mdevs_lock mutex in the status_show function. It is taken there rather than the vfio_ap_mdev_for_queue function - where it is needed - because it must be taken prior to the mdevs_lock mutex in order to adhere to the proper locking order and prevent a lockdep splat; also because the mdevs_lock is needed there to access fields within the matrix_mdev object in that function. See the vfio-ap-locking.rst in the linux kernel tree.

In the Linux kernel, the following vulnerability has been resolved: media: tda18250: fix possible integer overflow Integer overflow may occur, when variable exp equals to zero. Result of shift 1 << (exp - 1) may then leads to undefined behavior.

In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound i2c->length in I2C bsg handlers struct qla_i2c_access carries a 16-bit length field alongside a fixed 64-byte buffer: struct qla_i2c_access { uint16_t device, offset, option, length; uint8_t buffer[0x40]; } __packed; qla2x00_write_i2c() and qla2x00_read_i2c() use the user-supplied i2c->length without any bounds check. i2c is overlaid on a 256-byte on-stack buffer and sfp is a 256-byte DMA-pool buffer, so a length up to 65535 overruns both: - write: memcpy(sfp, i2c->buffer, i2c->length) over-reads the stack and over-writes the sfp heap buffer, and qla2x00_write_sfp() then DMAs i2c->length bytes out of the 256-byte buffer. - read: qla2x00_read_sfp() DMAs i2c->length bytes into the 256-byte sfp, then memcpy(i2c->buffer, sfp, i2c->length) overflows the 64-byte buffer inside the on-stack array. A caller holding CAP_SYS_RAWIO can use this to corrupt the heap and the kernel stack. Reject requests whose length exceeds the buffer before any copy or DMA transfer in both handlers.

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to migrate all curseg types during free_segment_range In free_segment_range(), the curseg evacuation loop only iterates up to NR_CURSEG_PERSIST_TYPE (0..5), missing non-persistent in-memory curseg types such as CURSEG_COLD_DATA_PINNED and CURSEG_ALL_DATA_ATGC. Even though these in-memory curseg types are not saved in the on-disk checkpoint header, they still occupy active physical segments at runtime. If an active in-memory curseg happens to be allocated within the segment range being truncated during filesystem shrink, failing to evacuate it will cause subsequent writes to the curseg attempting out-of-bounds I/O on the truncated storage range. Fix this by expanding the curseg evacuation loop upper bound to NR_CURSEG_TYPE to ensure all active curseg types are safely migrated out of the target range.

An out-of-bounds read in the HTTP Cache-Control response header parser of the QtNetwork module lets a hostile or compromised HTTP server crash 64-bit client applications built on Qt 6.0.0-6.8.8 or 6.9.0-6.11.1 that use QNetworkAccessManager. The trigger is an excessively large Cache-Control header value returned to the requesting client; because the over-read is read-only, the outcome is limited to a denial of service (application crash) with no information disclosure and no code execution, and only the client side of the connection is affected - 32-bit builds are not affected. No public exploit code has been identified at time of analysis, and exploitation is not on-demand against an arbitrary target: the victim application must be induced to connect to an untrusted, attacker-controlled, or compromised server (reflected as AT:P in the CVSS 4.0 vector), which keeps real-world risk at a low-to-moderate level despite the presence of RCE and Information Disclosure tags in some feeds.

In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid divide by zero in rt6_multipath_rebalance rt6_multipath_rebalance() calculates the total eligible nexthop weight in one pass and programs upper bounds in a second pass. Since RTM_NEWROUTE is RTNL-free, a concurrent ignore_routes_with_linkdown update can make the first pass return zero while the second sees an eligible nexthop, causing rt6_upper_bound_set() to divide by zero. UBSAN: division-overflow in net/ipv6/route.c:4845:17 Oops: divide error: 0000 [#1] SMP KASAN NOPTI rt6_upper_bound_set() net/ipv6/route.c:4845 rt6_multipath_rebalance() fib6_add_rt2node() ip6_route_multipath_add() inet6_rtm_newroute() Skip upper-bound calculation when the first pass reports a zero total. This respects the lock-free performance considerations here and solves insecure scenarios.

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix out-of-bounds read of INDEX_ROOT in reparse/objid init ntfs_reparse_init() and ntfs_objid_init() parse the index root of the $Extend/$Reparse and $Extend/$ObjId metafiles (the INDEX_ROOT attributes named $R and $O). They read its type and rule fields through resident_data(), which does not check that the resident attribute is large enough to hold them. mi_enum_attr() accepts a resident attribute with data_off == asize and data_size == 0. For such an attribute placed last in its MFT record, resident_data() returns a pointer to the end of the record_size buffer, so reading root->type / root->rule reads past the allocation. Use resident_data_ex(attr, sizeof(struct INDEX_ROOT)) and bail out when it returns NULL, as ntfs_security_init() already does for $SDH / $SII. The attribute is only parsed while mounting a crafted image, so this needs CAP_SYS_ADMIN. BUG: KASAN: slab-out-of-bounds in ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) Read of size 4 at addr ffff88801219dc00 by task mount ntfs_reparse_init (fs/ntfs3/fsntfs.c:2306) ntfs_fill_super (fs/ntfs3/super.c:1604) get_tree_bdev_flags (fs/super.c:1703) vfs_get_tree (fs/super.c:1758) path_mount (fs/namespace.c:4131) __x64_sys_mount (fs/namespace.c:4360)

A heap-based buffer overflow in the Samsung Escargot JavaScript engine is reachable when a crafted bytecode-cache file is parsed, driven by an integer wraparound (CWE-190) in the string-table length handling inside CodeCacheReader::loadStringTable. Exploitation requires local write access to the engine's bytecode-cache directory (CVSS 5.5, AV:L/PR:L), and the impact is limited to availability - a crash or memory-corruption-induced denial of service with no confidentiality or integrity loss. No public exploit code or CISA KEV listing was identified at time of analysis, and the upstream fix (Samsung PR #1650) adds a bounds check rejecting any maxLength above STRING_MAXIMUM_LENGTH.

An out-of-bounds read in the ARP filter import handler (filter_arp_put_file.cgi) of Netcore NR255-V firmware 1.5.130703 lets an attacker who can reach the router's web management interface and supply a malformed, non-null-terminated string cause the string-handling API to read past the end of an allocated buffer, exposing adjacent process memory in the response. The flaw is rated CVSS 5.3 (CVSS:4.0/AV:N/AC:L/PR:L/UI:N/VC:L/VI:N/VA:L), indicating a network-reachable, low-privilege issue with limited confidentiality and availability impact only — there is no confirmed integrity impact, no CISA KEV listing, and no confirmed public exploit code; the only public material is a VulnCheck advisory plus a third-party GitHub technical reference whose exploit content is unverified.

An integer overflow in Google Chrome's Compositing component (fixed in 153.0.8010.47) lets a remote attacker leak cross-origin data by getting a victim to open a crafted HTML page. Exploitation requires user interaction (the victim must load the page) but no authentication or elevated privileges, and the impact is limited to confidentiality - integrity and availability are unaffected per the CVSS vector. There is no public exploit code or CISA KEV listing at time of analysis, and the CVSS base score is only 4.3, so this is a browser-patching hygiene issue rather than an emergency incident response trigger.

Google Chrome for Android versions prior to 153.0.8010.47 contain an out-of-bounds read in the WebGL rendering path that allows a remote attacker to leak memory from outside the browser sandbox by luring a victim into opening a crafted HTML page. Google labels the Chromium security severity as Critical, while the published CVSS 3.1 base score is a comparatively modest 4.7 (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N) because the flaw yields a limited confidentiality leak rather than code execution or data modification. A vendor patch is available, and no public exploit code or CISA KEV entry was identified at the time of analysis.

Authenticated attackers holding Admin privileges on HPE Networking EdgeConnect SD-WAN Gateways can send a crafted request to an API endpoint and trigger a classic buffer overflow (CWE-120), potentially achieving arbitrary command execution on the appliance's underlying operating system. ENISA EUVD lists affected builds across the 9.4.x, 9.5.x, 9.6.x and 9.7.x release branches, with the HPE advisory as the sole authoritative reference. No public exploit code and no CISA KEV entry were reported at time of analysis, and the vendor's 5.5 CVSS score omits any confidentiality impact despite the description claiming full OS-level command execution.

A buffer overflow in the web-based management interface of HPE Networking EdgeConnect SD-WAN Gateways allows an authenticated administrator to crash or destabilize the appliance, producing a denial-of-service condition. All maintenance branches 9.4.0.0 through 9.4.8.2, 9.5.0.0 through 9.5.8.1, 9.6.0.0 through 9.6.3.1, and 9.7.0.0 are affected per ENISA EUVD tracking. The CVSS base of 5.5 with PR:H reflects that high administrative privileges are required, so this is not an unauthenticated remote outage; no public exploit code or CISA KEV listing was identified at time of analysis.

A buffer overflow in a system service of the underlying operating system on HPE Networking EdgeConnect SD-WAN Gateways allows an unauthenticated attacker who already sits on an adjacent network segment to crash the affected service, temporarily disrupting SD-WAN and branch network operations. All editions of the 9.4.x (up to 9.4.8.2), 9.5.x (up to 9.5.8.1), 9.6.x (up to 9.6.3.1) and 9.7.0.0 releases are listed as affected by the vendor. The impact is degraded availability rather than confidentiality or code execution, exploitation requires high attack complexity, and no public exploit code or CISA KEV entry was identified at time of analysis.

A buffer overflow in the underlying operating system of HPE Networking EdgeConnect SD-WAN Gateways lets an unauthenticated remote attacker send specially crafted packets to an affected service and corrupt its memory. Rated CVSS 6.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L, CWE-120), successful exploitation degrades the integrity and availability of the gateway service without exposing confidential data. No CISA KEV listing and no public exploit code were identified in the supplied intelligence, and no EPSS score was provided, so exploitation is currently assessed as opportunistic rather than confirmed in the wild.

An out-of-bounds write in the Android kernel GNSS link driver lets a local process that already holds System execution privileges corrupt kernel memory and escalate to kernel-level code execution. The defect (CWE-787) is a missing bounds check in link_load_gnss_image() in link_device.c, requires no user interaction, and is addressed through Google's September 2026 Android/Pixel security bulletin. No public exploit code or confirmed active exploitation has been identified at time of analysis.

An out-of-bounds read in the Pixel-specific physmem_extmem driver (physmem_extmem_linux.c) of the Android kernel lets a local process with low privileges read kernel memory that was never initialized, exposing potentially sensitive data. No user interaction or elevated execution privileges are required, and the impact is limited to confidentiality (CVSS 5.5, AV:L/PR:L/C:H). The issue is addressed in the September 2026 Android/Pixel security bulletin; no public exploit code or CISA KEV listing was identified at the time of analysis.

An out-of-bounds write in the Android kernel, caused by a missing bounds check, allows an attacker who already holds System-level execution privileges on a device to corrupt kernel memory and escalate to full kernel/root privileges. The flaw is reachable only with local access (AV:L, PR:H) and requires no user interaction, and the associated CVSS score of 6.7 reflects high integrity, confidentiality and availability impact rather than ease of reach. No public exploit code or CISA KEV active-exploitation listing was provided in the available intelligence, so this is currently assessed as a patch-priority local privilege-escalation bug rather than a known exploited threat.

A missing bounds check in multiple locations of Android kernel code allows a local attacker who already holds System execution privileges to trigger an out-of-bounds write and escalate to higher, kernel-level privileges on affected devices. Google Android builds that ship the impacted kernel code are affected, with fixes published through the September 2026 Pixel/Android security bulletin. No public exploit code or active exploitation has been identified at time of analysis, and the CVSS 6.7 score reflects the demanding high-privilege prerequisite rather than any remote reachability.

Out-of-bounds write in the Android kernel lets a local attacker who already holds System-level execution privileges corrupt memory and escalate to full kernel/root code execution without any user interaction. Devices running Android builds that have not yet adopted the September 2026 (2026-09-01) security patch level are affected, with Google rating the flaw High at CVSS 6.7. No public exploit code and no CISA KEV entry were identified at time of analysis, and no EPSS score was supplied with this data.

An out-of-bounds read in the Android kernel driver routine gf_algo_get_cached_dump_data (gf_algo.c) lets a locally positioned attacker with limited privileges read past the end of a buffer and leak kernel memory contents, with no user interaction required. Pixel builds that ship the vulnerable gf_ driver are affected, and the September 2026 Android/Pixel security bulletin provides the fix. Neither public exploit code nor a CISA KEV entry was present in the supplied intelligence, and no EPSS score was provided, so active exploitation is unconfirmed and the practical threat at time of analysis is a local, post-compromise or malicious-app information leak.

Memory corruption in the Android Trusted Execution Environment (TEE) allows a local attacker who already holds System execution privileges to escalate privileges within the secure world by supplying improperly validated input to an affected secure-world interface. The flaw is local-only (AV:L), requires high pre-existing privileges (PR:H), and needs no user interaction (UI:N), yielding high confidentiality, integrity, and availability impact if the corrupted trusted application is reached; Google rates it 6.7 (Medium). Risk is tempered by the significant foothold required, the local-only attack surface, and the low EPSS score (0.11%, 2nd percentile); no public exploit code has been identified and the flaw is not listed in CISA KEV, with fixes delivered in the Pixel security bulletin dated 2026-09-01.

Let me synthesize. CVE-2026-56923: Android kernel TIPC virtio driver (tipc_virtio_dev.c) handle_unmap_req race condition memory corruption, local EoP. CVSS 3.1: AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H → 6.4. Note PR:H which is odd for a local privilege escalation "with no additional execution privileges needed" — the description says no additional execution privileges needed. Hmm, the CVSS says PR:H. There's a conflict: description says local EoP with no additional execution privileges needed (implying PR:N or PR:L?), while CVSS vector says PR:H. This is a data conflict worth noting in confidence_notes and risk_assessment. Actually Android's kernel CVEs for local EoP typically are AV:L/AC:H/PR:H/UI:N in their bulletins... Actually Android uses PR:H sometimes? Hmm. Let me note the conflict: description claims "no additional execution privileges needed" but vector shows PR:H (high privileges required), which typically means the attacker already needs elevated privileges — contradictory for an EoP. State explicitly. Product name: "Android Kernel" — 2 words. Or "TIPC Virtio Driver". Primary product per CPE: google:android. I'd say "Android Kernel". Tags: Privilege Escalation, Buffer Overflow, Google, Race Condition. Buffer Overflow mislabeled? The CWE is race condition/memory corruption. Hmm — "Buffer Overflow" tag is arguably a mislabeled tag since CWE-362 race condition and description says memory corruption not buffer overflow. But memory corruption could involve buffer overflow. I'd be moderately confident... The instructions say only emit flag when clearly wrong and verifiable. Memory corruption due to race condition — buffer overflow is a specific subclass. It's arguably mislabeling. I could flag it with low/medium confidence. Hmm. I think I'll flag it as mislabeled_tag with medium confidence since the CVE is a race condition leading to memory corruption, no buffer overflow specified. Actually careful — race conditions can cause buffer overflows (TOCTOU). Risky.

An out-of-bounds read in ReadDataElement (common.c) within the Android platform allows a locally installed application to disclose sensitive memory contents without any additional execution privileges or user interaction. The flaw is a missing/incorrect bounds check on an attacker-influenced length or index value, rated CVSS 5.5 (AV:L/AC:L/PR:L/UI:N, C:H/I:N/A:N), so the practical impact is confidentiality loss rather than code execution. Affected builds are Android platform components referenced by the September 2026 Pixel/Android security bulletin; no public exploit code or CISA KEV listing was identified at time of analysis, and the EPSS signal is absent from the supplied data.

Memory corruption in the Android kernel's GMC mailbox message handler (gmc_mb_msg_handler in gmc_mba.c) allows a local attacker who already holds System-level execution privileges to leverage a confused-deputy condition and escalate privileges on the device. The flaw is tracked as CWE-441 and rated CVSS 6.7 (AV:L/AC:L/PR:H/UI:N), meaning it is not remotely reachable and requires a high-privilege foothold rather than being an entry point; user interaction is not needed once that footing exists. Google Devices credited the report and fixed it in the September 2026 Pixel/Android security bulletin; no public exploit code or CISA KEV entry was identified at time of analysis.

An out-of-bounds write in the Android kernel's remap.c code allows a local attacker holding System-level execution privileges to corrupt kernel memory and escalate to full kernel (root) privileges. The flaw stems from an incorrect bounds check (CWE-787) that fails to validate an offset or length before a write, and no user interaction is required once the attacker has the prerequisite System privileges. At the time of analysis there is no public exploit code and the issue is not listed in CISA KEV, but the September 2026 Pixel security bulletin confirms a vendor fix is available.

Local privilege escalation in the Google Android kernel stems from an out-of-bounds write caused by improper input validation in multiple code locations. An attacker who already holds System-level execution privileges on the device can craft malformed input to corrupt memory and elevate to kernel privileges on affected Android builds. No user interaction is required, and no public exploit code or CISA KEV entry was identified at time of analysis, though the vendor-published September 2026 Pixel bulletin confirms a fix is available.

An out-of-bounds write in the Android kernel's printf implementation allows an attacker who already holds System-level privileges on the device to corrupt kernel memory and escalate further, typically to kernel/root context, by supplying improperly validated input to the affected formatting routine. Exploitation is local only and requires high privileges (CVSS 3.1 6.7, AV:L/PR:H/UI:N), so a malicious app running as System would be needed rather than a remote attacker. No public exploit code or confirmed active exploitation was identified at time of analysis, and the issue is fixed in Google's September 2026 Pixel/Android security bulletin.

An out-of-bounds read in the AES-GCM-256 crypto implementation of the Android kernel (function do_sss_aes_gcm_256_op in crypto-aes.c) allows disclosure of memory contents to code that is already running at System privilege on an affected device. The flaw is a missing bounds check on an input length or index (CWE-120 class buffer handling error), rated 4.4 (Medium) with the vector CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N, meaning exploitation is local and requires the attacker to already hold System (PR:H) execution privileges; no user interaction is needed once that position is held. There is no indication of confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis, and because the entry point sits behind a high privilege boundary the practical risk is a post-compromise or chained privilege-escalation information leak rather than an independent remote threat.

Integer overflow in the FreeRDP client's Apple/CoreAudio audio-input (audin) backend, present in all versions before 3.31.0, allows a malicious or compromised RDP server to corrupt memory on the connecting client. The server sends an MSG_SNDIN_OPEN message carrying a crafted FramesPerPacket value that wraps the size arithmetic used by AudioQueueAllocateBuffer, producing an undersized allocation that is then written past its bounds during audio capture. Impact is bounded to the client (CVSS 5.3, all impacts Low, UI:P — the victim must initiate a connection to the hostile server); patch status is 'available from vendor' with a fix in 3.31.0, and no public exploit or CISA KEV entry was identified at time of analysis.

Opening a crafted .rdp connection file in the FreeRDP xfreerdp X11 client (versions 3.11.0 through 3.30.0) can trigger out-of-bounds heap reads and writes because the client fails to validate MonitorIds array values in xf_detect_monitors. This local, user-interaction-gated flaw requires a victim to open the malicious file and does not affect the RDP server side; publicly available exploit code exists, but there is no confirmation of active exploitation (not in CISA KEV). The vendor has released a patch in FreeRDP 3.31.0, and the CVSS 6.9 rating reflects limited confidentiality and integrity impact with a high availability impact.

Heap buffer overflow in the NGINX HTTP/3 module (ngx_http_v3_module) can crash NGINX worker processes or corrupt a limited amount of heap data when NGINX Plus or NGINX Open Source serves QUIC traffic while linked against OpenSSL 3.5.0 or earlier under certain configurations. The overflow occurs while processing a TLS handshake and is non-deterministic — triggering it is largely outside the attacker's control — so the realistic outcome is opportunistic denial of service (worker restart) plus limited data corruption rather than reliable remote code execution. There is no control plane exposure (data plane only), no public exploit identified at time of analysis, and no CISA KEV listing; EPSS data was not provided.

GNOME Shell fails to validate the declared dimensions of icons returned by a remote search provider over D-Bus against the actual icon data buffer, producing an out-of-bounds read when an oversized size is supplied. A malicious or compromised search provider registered in a user's session can crash the shell — terminating the desktop session — and may leak fragments of adjacent shell memory. Rated CVSS 6.1 (AV:L/UI:R/C:L/A:H) by Red Hat; no public exploit code or CISA KEV entry was identified at time of analysis, so exploitation currently requires a locally present hostile search provider rather than remote access.

Rendering a crafted Lottie vector animation with Samsung's open-source rLottie library can overflow a fixed-size stack buffer during run-length-encoding of render spans, corrupting memory in the host application. The flaw affects rLottie builds at revision 480a2ad0c5d2e45458c545b8213279e9e8b71e39 and is rated only 4.4 (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L) because an attacker must induce the victim application to render a malicious animation; there is no public exploit identified at time of analysis and the CVE is not listed in CISA KEV. An upstream fix exists in Samsung/rlottie pull request 607, which increases the span array capacity and adds explicit bounds checks.

Memory corruption in GPAC's scenegraph node management routine `gf_node_list_insert_child` (in `scenegraph/base_scenegraph.c`) can be triggered by a remote attacker delivering a crafted MPEG-4/BIFS scene file, causing a process crash (DoS). A publicly available proof-of-concept exploit (`poc_18_nstatx.zip`) is distributed via GitHub, lowering the exploitation bar. All GPAC releases up to commit f1219cde are affected; version abi-16.23 resolves the issue. No confirmed active exploitation campaign (not in CISA KEV) has been identified at time of analysis.

Stack exhaustion via unbounded recursion in GPAC's scenegraph node activation routine allows a local attacker to crash the application or corrupt memory when a malicious or malformed multimedia scene file is opened. Affected versions up to commit f1219cde lack a recursion depth guard in gf_node_activate_ex and gf_node_deactivate_ex, enabling crafted cyclic or deeply nested VRML/X3D/XMT scene graphs to exhaust the call stack. A publicly available proof-of-concept (poc_17_nstatx.zip) exists; however, no active exploitation has been confirmed and impact is limited to low integrity and availability consequences on the local system.

Heap out-of-bounds access in GPAC's URL concatenation utility (`utils/url.c`) allows a local low-privileged attacker to trigger memory corruption when the `gf_url_concatenate_ex` function processes a crafted URL that results in an empty temporary buffer. The trailing-whitespace trim loop computes `tmp[strlen(tmp)-1]` without first checking that `tmp` is non-empty, accessing heap memory at index -1. Exploitation requires local system access and user interaction; no public exploit exists and the vulnerability is not listed in CISA KEV. The fix is available in GPAC release abi-16.23.

Heap-based buffer overflow in GPAC's MPEG Video Reframer filter exposes users of versions up to commit f1219cde to memory corruption when processing a malformed MPEG video file. The vulnerable function mpgviddmx_process() in filters/reframe_mpgvid.c previously relied on gf_assert() to validate MPEG start codes without first confirming the buffer contains at least 3 bytes, enabling heap corruption on crafted input. A proof-of-concept exploit has been publicly disclosed via GitHub; no CISA KEV listing or confirmed active exploitation exists at time of analysis.

CVE-2026-75883 is an Ubuntu security update with no technical details publicly disclosed at time of analysis. The description contains only the phrase 'security update,' providing no information about the vulnerability class, affected component, or attacker capabilities. No CVSS vector, CWE, or supplementary intelligence is available to characterize impact or exploitation conditions.

Memory corruption in GNU Binutils 2.47 is triggerable locally by supplying a crafted ELF file to any Binutils tool that invokes `_bfd_elf_strtab_delref` in `bfd/elf-strtab.c`. A low-privileged local attacker can corrupt heap memory in the BFD library's ELF string table handler, potentially causing process crash, limited information disclosure, or minor data manipulation. A public proof-of-concept exists per the CVSS 4.0 E:P modifier and CVE description; no vendor patch has been released as the upstream project had not yet responded to the bug report at time of disclosure.

Out-of-bounds write in the Zephyr RTOS ITE it51xxx I2C target driver allows a malicious or compromised I2C master to corrupt embedded controller firmware memory by sending a write transaction exceeding 256 bytes while the controller operates in buffer mode. The FIFO interrupt handler target_i2c_isr_fifo() accumulated bytes into a fixed-size buffer without a pre-write bounds check, enabling overflow into the adjacent target_out_buffer and following static device data in the interrupt handler context. No software privilege on the victim controller is required; the attacker needs physical or electrical access to the I2C bus with both CONFIG_I2C_TARGET and CONFIG_I2C_TARGET_BUFFER_MODE enabled. No public exploit exists and this vulnerability is not listed in CISA KEV at time of analysis.

A stack-based buffer overflow exists in GPAC 26.07.0 within the scene-graph DOM event handler gf_sg_dom_event_bubble (src/scenegraph/dom_events.c), reachable through the MP4Box tooling when it parses a crafted scene/BT/XMT media file. Exploitation is local only — the attacker must get a file processed by an affected build — and the disclosed impact is loss of availability rather than code execution or data disclosure. Publicly available exploit code exists (a PoC archive is linked from the advisory), but EPSS is only 0.17% (7th percentile), there is no CISA KEV listing, and the SSVC decision is exploitation=poc, automatable=no, technical impact=partial, so this is a low-priority, local, denial-of-service-class memory-safety bug rather than an urgent remote threat.

An out-of-bounds write (buffer overflow) in the PASE AIX-runtime layer of IBM i 7.3, 7.4, 7.5, and 7.6 lets an authenticated local user crash their own PASE process, producing a self-limited denial of service. The independently assessed vector (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L) requires a valid IBM i account able to execute code in PASE, and per the vendor the impact is confined to terminating the attacker's own process rather than affecting other users, sessions, or the underlying operating system; the vendor's NVD entry scores it 5.2 under a scope-changed (S:C, I:L) interpretation. EPSS is 0.12% (2nd percentile), there is no CISA KEV listing, and no public exploit code has been identified at time of analysis, so real-world risk is low and this should not be triaged as a critical memory-corruption event despite the buffer-overflow framing.

A buffer overflow in a PASE (Portable Application Solutions Environment) process on IBM i 7.3, 7.4, 7.5, and 7.6 allows an authenticated local user to crash the affected process. Per IBM's own description, the impact is limited: the attacker can terminate their own process rather than disrupt other users or system-wide services, which is reflected in the low CVSS 3.3 and Availability-only impact. There is no public exploit code and no CISA KEV listing at time of analysis, and the flaw is classified as CWE-125 (out-of-bounds read).

An out-of-bounds write in Apple's operating system memory handling lets a process already confined to the platform sandbox break out of those restrictions, gaining partial read and write access to data it should not reach. Affected platforms are iOS and iPadOS before 26.7/27, macOS Sequoia before 15.8, macOS Tahoe before 26.7, macOS Golden Gate before 27, visionOS before 27 and watchOS before 27. Apple has released fixes for every affected platform, and CISA's SSVC assessment records no exploitation, no automation and only partial technical impact.

Mounting a crafted disk image on unpatched macOS releases triggers an out-of-bounds write in the code that parses disk image content, causing unexpected system termination (crash) on macOS Sequoia, Sonoma and Tahoe. The flaw is rated CVSS 6.5 (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H) - a user-interaction-dependent denial-of-service with no confidentiality or integrity impact, and CISA's SSVC assessment marks exploitation as 'none' and automatable as 'no'. EPSS is 0.19% (9th percentile), no public exploit code or CISA KEV listing was identified at time of analysis, and Apple has shipped fixed builds in macOS Sequoia 15.7.8, macOS Sonoma 14.8.8 and macOS Tahoe 26.6.

An out-of-bounds read in Apple's font parsing code lets a maliciously crafted font file leak process memory on unpatched builds of iOS, iPadOS, macOS, tvOS, visionOS and watchOS, with all affected platforms fixed in the version 27 releases. Triggering it requires the victim to render attacker-supplied content containing the crafted font — an email, document, web page or message preview — but no credentials or elevated privileges are needed once that interaction happens, and the resulting confidentiality impact is rated high with no integrity or availability effect. No public exploit code or active exploitation has been identified, and EPSS sits at a low 0.20% (10th percentile), so this is best handled as a scheduled platform update rather than an emergency response.

An out-of-bounds read in the font-parsing path of Apple's operating systems lets a remote attacker disclose the contents of process memory when a victim processes a maliciously crafted font. All Apple platforms are affected prior to the version 27 releases — iOS and iPadOS, macOS Golden Gate, tvOS, visionOS and watchOS — and Apple has shipped fixes for each. There is no CISA KEV listing and no public exploit code identified, and the EPSS score of 0.17% (7th percentile) indicates a low probability of near-term exploitation; because the sole impact is memory disclosure and exploitation requires the victim to open or render attacker-supplied content, this is a moderate-priority patch rather than an emergency.

An integer-overflow flaw (CWE-190) in Apple macOS lets an attacker who already occupies a privileged on-path network position crash or otherwise deny service to the affected system. The vulnerability is fixed in macOS Golden Gate 27, macOS Tahoe 26.7 and macOS Sequoia 15.8, so every earlier build of those three branches is exposed. There is no CISA KEV listing and no identified public exploit code, and EPSS places exploitation likelihood at roughly 0.17% (6th percentile), making this a routine patch-cycle item rather than an emergency for most fleets.

An out-of-bounds write in Apple's image handling code lets a maliciously crafted image crash the parsing process on affected iPhones, iPads, Macs, Apple TVs, Vision Pro and Apple Watches. Apple fixed the flaw through improved bounds checking in iOS/iPadOS 26.7 and 27, macOS Sequoia 15.8, macOS Tahoe 26.7, macOS Golden Gate 27, tvOS 27, visionOS 27 and watchOS 27. Exploitation requires the victim to open or preview the crafted image (UI:R), the observed impact is process termination only — no code execution, data theft or tampering is described — and there is currently no public exploit code or CISA KEV listing; EPSS is a low 0.17% (7th percentile).

A buffer overflow in multiple Apple operating systems — iOS 18.7.10, iPadOS 18.7.10, iOS 27, iPadOS 27, macOS Golden Gate 27, macOS Sequoia 15.7.8, and macOS Sonoma 14.8.8 and earlier — allows a locally executing app to crash the affected system or process, producing a denial of service. The flaw stems from insufficient bounds checking (CWE-120) and is rated CVSS 5.5 (AV:L/AC:L/PR:L/UI:N, availability-only impact), meaning an attacker must already have the ability to run code as a low-privileged app on the device. Apple has released patches and there is no CISA KEV listing, no public exploit code identified, and EPSS is low at 0.21% (12th percentile), so real-world exploitation pressure is currently minimal.

An out-of-bounds write in Apple's operating system kernel (CWE-787) allows a locally installed app to corrupt kernel memory or force an unexpected system termination, affecting iOS/iPadOS, macOS, tvOS, visionOS, and watchOS. Apple fixed the flaw with improved bounds checking in iOS 26.7 and 27, iPadOS 26.7 and 27, macOS Sequoia 15.8, macOS Tahoe 26.7, macOS Golden Gate 27, tvOS 27, visionOS 27, and watchOS 27. Exploitation requires a local app (CVSS PR:L) with no user interaction, so real-world risk is currently low - EPSS is only 0.21% (11th percentile), the issue is not listed in CISA KEV, and no public exploit code has been identified.

Mounting a maliciously crafted disk image on unpatched Apple devices triggers an out-of-bounds write in image-parsing code, leading to memory corruption and unexpected system termination (denial of service). Affected platforms include iOS/iPadOS before 26.7 and 27, and macOS Sequoia before 15.8, macOS Tahoe before 26.7, and macOS Golden Gate before 27. Apple has shipped fixes in iOS 26.7/27, iPadOS 26.7/27, and the corresponding macOS releases; no public exploit code or active exploitation has been identified, and EPSS is negligible at 0.17% (7th percentile), indicating a low-likelihood, availability-only defect.