The internet is broken right now.

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel_pcie: validate device-supplied DMA indices In btintel_pcie_msix_rx_handle(), the driver processes RX completion descriptors (urbd1) written by the PCIe device into DMA-coherent memory. urbd1->frbd_tag (a 16-bit field fully controlled by the device firmware via DMA) is used directly as an array index into rxq->bufs[] without any bounds check. rxq->bufs[] has only BTINTEL_PCIE_RX_DESCS_COUNT (64) entries, while frbd_tag can be any value 0-65535. A malicious or malfunctioning device can write an out-of-range frbd_tag, causing the driver to dereference an out-of-bounds data_buf pointer. Additionally, cr_hia is read from a DMA-shared index array also writable by the device; if the device sets cr_hia >= rxq->count, the while-loop never terminates because cr_tia is wrapped via modulo rxq->count and can never equal an out-of-range cr_hia. Add bounds validation for cr_hia and frbd_tag in the RX path, and cr_hia in the TX path. Log invalid values with bt_dev_err before returning.

Memory safety OS & kernel

In the Linux kernel, the following vulnerability has been resolved: ata: libata-scsi: bound the ATA passthru sense descriptor writes When an ATA PASS-THROUGH command to an ATAPI device fails, the sense buffer holds the device's REQUEST SENSE reply, and ata_scsi_set_passthru_sense_fields() trusts its additional length byte, sb[7], when adding the ATA Status Return descriptor. A faulty or malicious device can use that to make the kernel read and write past the 96-byte buffer in three ways: - scsi_sense_desc_find() is passed sb[7] + 8 as the buffer length, so its clamp against sb[7] does nothing and the walk runs off the end. - A type-9 descriptor found near the end is filled in unchecked. - A new descriptor at sb[8 + len] needs len + 22 bytes, not len + 14, so len 75..82 writes up to 8 bytes past the end. Reproduced with KASAN under qemu, with the emulated ATAPI REQUEST SENSE reply patched: BUG: KASAN: slab-out-of-bounds in scsi_sense_desc_find+0x1a5/0x210 BUG: KASAN: slab-out-of-bounds in ata_scsi_qc_complete+0x1a15/0x1a50 Both are gone with this patch, and a valid descriptor is still filled in.

Memory safety OS & kernel

A flaw was found in parted. A heap-based buffer overflow can occur when processing a specially crafted FAT32 filesystem due to an integer calculation error during buffer allocation. A local attacker could exploit this by enticing a user or automated service to open a malicious filesystem image, resulting in an application crash leading to a Denial of Service (DoS) or potential memory corruption.

Memory safety

In the Linux kernel, the following vulnerability has been resolved: s390/boot: Avoid IPL parameter append past command line A command line may occupy all but the terminating byte of COMMAND_LINE_SIZE. In that case append_ipl_block_parm() passes a zero size to the IPL parameter conversion helpers and points the destination one byte past early_command_line. The helpers subtract one from the unsigned size and write the converted parameter outside the command line buffer. Convert the IPL parameter in the command line parsing buffer first. A parameter beginning with '=' can then replace the existing command line regardless of its length, while other parameters are appended only when space remains.

Memory safety OS & kernel

libriscv is a RISC-V sandbox and emulator. Prior to 1.18, a crafted ELF binary can cause out-of-bounds reads in the host emulator. `Memory<W>::binary_loader` checks `PT_LOAD` program-header bounds, but `Memory<W>::serialize_execute_segment` trusts section-header `sh_offset` and `sh_size` when locating `.text` without verifying the file range against `m_binary.size()`; `Memory<W>::lookup()` has a similar section-table problem. Malformed `.text` or `.symtab` offsets can therefore bypass the program-header checks and point outside the binary buffer, crashing rvlinux. With suitable memory layout or integer overflow, out-of-buffer host heap memory may instead be mapped into the guest by `create_execute_segment()`, potentially exposing host memory. The reported reproducer demonstrates a host SIGSEGV, while memory disclosure through grooming is described as possible rather than demonstrated. This issue is fixed in version 1.18.

Memory safety

An out-of-bounds write issue was addressed with improved bounds checking. This issue is fixed in iOS 26.7.2 and iPadOS 26.7.2, iOS 27.2 and iPadOS 27.2, visionOS 27.2, watchOS 27.2. A buffer overflow may result in memory corruption and unexpected app termination.

Memory safety OS & kernel Apple Ipados

Heap-based buffer overflow in the JJY refclock driver in NTPsec ntpd before 1.2.6 allows an attacker who controls the Telephone JJY time source to corrupt memory or crash ntpd via more than six time replies.

Memory safety OS & kernel

In the Linux kernel, the following vulnerability has been resolved: wifi: wfx: validate MIB read length before copying to caller wfx_hif_read_mib() copies reply->length bytes from the firmware response into the caller-provided buffer without checking that reply->length does not exceed val_len. A firmware response with a length field larger than expected overruns the caller buffer and reads past the end of the reply allocation. Replace the dead -ENOMEM check with an active validation that reply->length fits within val_len before the memcpy.

Memory safety OS & kernel

In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: minstrel_ht: validate fixed rate index The fixed_rate_idx debugfs file is a plain u32 attribute, so any value can be written to it. minstrel_ht_update_stats() then copies the value into mi->max_tp_rate[] and mi->max_prob_rate, and minstrel_ht_set_rate() uses MI_RATE_GROUP()/MI_RATE_IDX() to index minstrel_mcs_groups[] (42 entries) and mi->groups[].rates[] (10 entries) with it. Writing e.g. 65535 selects group 4095 and rate index 15, far outside both arrays. The out-of-bounds entries are dereferenced and updated as struct minstrel_rate_stats (retry counts, etc.), so the invalid index corrupts adjacent kernel memory. With CONFIG_UBSAN_BOUNDS the access is reported as an array-index-out-of-bounds in minstrel_ht_set_rate(). Only a valid group/rate pair, or U32_MAX to disable fixed rate processing, can be used safely, so reject any other value when the debugfs file is written. The file is only reachable through a root-only debugfs mount, so this is not a privilege boundary. The out-of-bounds access is still a bug that must not be reachable through a writable debugfs attribute.

Memory safety OS & kernel

In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad_sigma_delta: fix use-after-free on unbind ad_sd_buffer_postenable() allocates sigma_delta->samples_buf with devm_krealloc() at runtime, so its devres entry sits after all probe-time entries of the driver. devm resources are released in reverse allocation order, which means unbind frees samples_buf before iio_device_unregister() disables the buffers and detaches the trigger pollfunc. The data ready IRQ is still enabled at that point, so ad_sd_trigger_handler() can still run and memcpy() incoming samples into the freed samples_buf. Fix this by preallocating the buffer in devm_ad_sd_setup_buffer_and_trigger(), before the triggered buffer and the IRQ are set up, so it is freed only after iio_device_unregister() has drained the trigger handler via free_irq(). Size it for the worst case of all sequencer slots being active; ad_sd_validate_scan_mask() already caps the number of active channels at num_slots. This issue was found by an in-house static analysis tool.

Memory safety OS & kernel

In the Linux kernel, the following vulnerability has been resolved: iio: pressure: bmp280: fix out-of-bounds access in sampling frequency lookup The sampling frequency tables store each frequency as an integer part and a fractional part in micro units. num_sampling_freq_avail is initialized to the number of flattened integer elements because read_avail() returns the table as a flat array. bmp280_write_sampling_frequency(), however, indexes the same table as a two-dimensional array and uses num_sampling_freq_avail as the number of rows. Convert the flattened element count back to the number of rows before iterating over the table.

Memory safety OS & kernel

The STM32WBA IEEE 802.15.4 driver in drivers/ieee802154/ieee802154_stm32wba.c computed the packet length of a received frame as pkt_len = rx_frame->length - IEEE802154_FCS_LENGTH without first checking that the radio-reported length could hold an FCS. pkt_len is a uint8_t, so a reported length of 0 or 1 wrapped to 254 or 255. The only bound on the resulting value was __ASSERT_NO_MSG(pkt_len <= CONFIG_NET_BUF_DATA_SIZE), which compiles to nothing in the default production configuration (CONFIG_ASSERT=n). The length originates in the ST link-layer receive-done metadata (p_metadata->length, stored by stm32wba_802154_receive_done()), and ultimately in the PHY header of a frame received over the air, so it is influenced by any attacker within radio range of the device. Reaching the underflow requires the vendor link layer to surface a frame shorter than the FCS with no error; the driver performed no validation of its own on that value. When the underflow occurs, stm32wba_802154_rx_thread() calls net_pkt_write(pkt, rx_frame->psdu, pkt_len) with a length of about 254 bytes against a receive buffer that holds at most one PHY packet (IEEE802154_MAX_PHY_PACKET_SIZE, 127 bytes). This reads roughly 128 bytes past the end of the radio receive buffer and copies that adjacent memory into a network packet that is submitted to the networking stack, giving an out-of-bounds read with a potential disclosure of adjacent RAM plus needless oversized packet allocation in the RX thread. The fix rejects a frame whose reported length is smaller than IEEE802154_FCS_LENGTH before the subtraction, and replaces the compiled-out assertion with a runtime length check that drops oversized frames — matching the runtime check already present in drivers/ieee802154/ieee802154_nrf5.c.

Memory safety Device

Godot Engine through 4.7.2 has an out-of-bounds read in the optimized translation loader (core/string/optimized_translation.cpp, OptimizedTranslation::get_message). Offsets read from the hash table of a crafted .translation resource are used as indices into the bucket table without bounds validation; only a single sentinel value is rejected. A crafted file can point an index far past the allocated buffer. Depending on the values, the result is a crash, or a string lookup (tr()) returns raw bytes from elsewhere in the process heap as the translated string, disclosing process memory. The defect is reached when the product or an exported game loads and performs lookups in a crafted translation file. NOTE: the Supplier's position is that the research has identified "no security issues" because the required attacker access is outside of the current Godot Engine threat model.

Memory safety Library

Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, the affected implementation used forge.tls.createConnection(), c.session.serverCertificate, RSA key exchange to process the relevant input or security decision. node-forge's TLS client checked the wrong property when deciding whether a server certificate was missing. A malicious TLS server or on-path peer could omit the Certificate message and reach code that dereferenced the absent certificate, causing an uncaught exception and terminating the connection or process. This issue is fixed in version 1.4.1.

Memory safety Server Digitalbazaar Forge

In Modem, there is a possible system crash due to a missing bounds check. This could lead to remote escalation of privilege, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is needed for exploitation. Patch ID: MOLY01911177; Issue ID: MSV-10122.

Memory safety Device

A use after free issue was addressed with improved memory management. This issue is fixed in iOS 26.7 and iPadOS 26.7, iOS 27 and iPadOS 27, macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7.2. An app may be able to execute arbitrary code with kernel privileges.

Memory safety OS & kernel Apple Ipados

The Bluetooth Classic A2DP host stores a codec Information Element (IE) in struct bt_a2dp_codec_ie, a one-byte len field plus a fixed 8-byte codec_ie[] array. When an AVDTP peer sent a codec IE longer than 8 bytes, a2dp_process_config_ind() in subsys/bluetooth/host/classic/a2dp.c copied only the first 8 bytes but assigned the full, attacker-chosen length to len, and then persisted that inconsistent structure into the application's struct bt_a2dp_stream via stream->codec_config. bt_a2dp_get_config_cb() and bt_a2dp_set_config_cb() had the same truncate-the-copy-but-keep-the-length pattern. Every later consumer trusts len. In particular the responder for an incoming AVDTP GET_CONFIGURATION, a2dp_get_config_ind(), executes net_buf_add_mem(rsp_buf, &ep->stream->codec_config.codec_ie[0], ep->stream->codec_config.len), so a paired BR/EDR peer that first sends a SET_CONFIGURATION carrying an oversized codec IE and then requests the configuration back causes the stack to read up to roughly 245 bytes past the end of the 8-byte array and transmit them in the response. codec_config is the last member of struct bt_a2dp_stream, so the read runs into memory adjacent to the application's stream object. The same inconsistency is also handed to the config_req(), reconfig_req() and get_config_rsp() application callbacks, where a natural memcpy() of len bytes performs a further out-of-bounds read. Reaching the on-air disclosure requires CONFIG_BT_CLASSIC with CONFIG_BT_A2DP, an AVDTP peer that has completed pairing (the AVDTP L2CAP channel requires BT_SECURITY_L2), and a local endpoint registered for a non-SBC codec — BT_A2DP_MPEG1/BT_A2DP_MPEG2/BT_A2DP_ATRAC/BT_A2DP_VENDOR via BT_A2DP_EP_INIT() — because the SBC branch already pins the IE length to 4 bytes. The bt_a2dp_get_config_cb() response path has no such gate and hands the lying length to any application. There is no out-of-bounds write: the net_buf tailroom check bounds the destination, so the impact is limited to disclosure of a bounded region of adjacent RAM to the peer. The fix replaces the hardcoded BT_A2DP_MAX_IE_LENGTH with the configurable CONFIG_BT_A2DP_CODEC_MAX_IE_LEN (default 8, range 4–253), sizes codec_ie[] from it, and rejects any received IE that exceeds it instead of silently truncating, so len can no longer exceed the number of valid bytes.

Memory safety Device

In the Linux kernel, the following vulnerability has been resolved: net: ipv4: Fix UDP length overflow with PMTU discover and big MTU This commit bounds cork->base.fragsize to IP_MAX_MTU to avoid a possible overflow of UDP length that triggers a WARN in udp_set_len_short when setsockopt IP_MTU_DISCOVER is set to IP_PMTUDISC_PROBE, and a large packet is sent over a netdev with an unusually large MTU. Steps to reproduce: 1. Set device MTU bigger than IP_MAX_MTU + 20. cork->base.fragsize will be set to that MTU in ip_setup_cork. 2. Set IP_MTU_DISCOVER to IP_PMTUDISC_PROBE. It lets maxnonfragsize be set to device MTU (cork->fragsize) in __ip_append_data, rather than to IP_MAX_MTU. 3. Send 65528 bytes of payload (+8 bytes of UDP header, +20 bytes of IPv4 header). Device MTU allows it (it's only one byte bigger than IP_MAX_MTU + IPv4 header, and the device MTU is bigger than that). 4. The UDP length in the built packet is 65536, which overflows the 16-bit length field and triggers the WARN in udp_set_len_short. Note: IP_PMTUDISC_DO with IPv4 is safe, because ip_dst_mtu_maybe_forward always clamps at IP_MAX_MTU, unlike ip6_dst_mtu_maybe_forward. The Fixes tag points at the first commit where I could reproduce the overflow with IPv4 and IP_PMTUDISC_PROBE.

Memory safety OS & kernel

A flaw was found in dnsmasq. The DHCPv6 client hostname parser can read one byte past the end of a crafted FQDN option because it checks the next label length before confirming the pointer is still inside the option. An attacker on the local network can trigger this with a single DHCPv6 packet. The extra byte is not returned to the client or logged, and no crash has been demonstrated.

Memory safety Network gear

A heap buffer overflow caused by a XIPassiveUngrabDevice request with an out-of-range modifier value in X.Org X Server before 21.1.15 and XWayland before 24.1.14 could be used by authenticated X clients to crash or potentially execute code in X server context.

Memory safety

A buffer overflow in RandR ChangeProviderProperty requests in X.Org X Server before 2.1.25 and XWayland before 24.4.14 could be used by authenticated X clients to crash or execute code within the X server context.

Memory safety

A heap buffer overflow caused by mismatched size usage in CopyArea CPU-to-FBO path in X.Org X Server before 21.1.15 and XWayland before 24.1.14 could be used by authenticated X clients to crash or potentially execute code in the X server context.

Memory safety

An integer truncation issue in XkbResizeKeyType() that could lead to a heap buffer overflow by authenticated X clients in X.org X server before 21.1.25 and XWayland before 24.1.14 could be exploited for crashes or potential code execution in the X server.

Memory safety

A buffer overflow when handling pointer barriers in the XFIXES extension in X.Org X server before 21.1.25 and XWayland before 24.1.14 could be used by authenticated X clients to crash or potentially execute code in X server context.

Memory safety

A heap buffer overflow caused by mismatching size calculations between XkbAllocNames and ChangeKeycodeRange in X.org X server before 2.1.25 and XWayland before 24.1.14 could be used by authenticated X clients to crash or potentially execute code in X server context.

Memory safety

A buffer overflow was addressed with improved bounds checking. This issue is fixed in iOS 26.7.2 and iPadOS 26.7.2, iOS 27 and iPadOS 27, macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7.2, visionOS 27. Processing a maliciously crafted image may lead to heap corruption.

Memory safety OS & kernel Apple Ipados

Memory corruption in SVG in Google Chrome prior to 155.0.8059.84 allowed a remote attacker to read memory via a crafted HTML page. (Chromium security severity: High)

Memory safety Browser & mail Google Chrome

Memory corruption in Core in Google Chrome prior to 155.0.8059.84 allowed a remote attacker to read memory via a crafted HTML page. (Chromium security severity: High)

Memory safety Browser & mail Google Chrome

The vulnerability is a heap out-of-bounds read in the EVS HAL's `getStreamList()` method. An attacker can craft a `CameraDesc.metadata` byte array, which is parsed without validation, leading to an out-of-bounds read at an attacker-controlled offset within the HAL process's heap. The read data is then exfiltrated back to the attacker, potentially leaking sensitive information like pointers and buffer handles.

Memory safety Device Google Android

A use-after-free issue was addressed with improved memory management. This issue is fixed in iOS 26.7.2 and iPadOS 26.7.2, iOS 27.2 and iPadOS 27.2, macOS Golden Gate 27.2, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2, tvOS 27.2, visionOS 27.2, watchOS 27.2. An app may be able to cause unexpected system termination or corrupt kernel memory.

Memory safety OS & kernel Apple Ipados

A use-after-free issue was addressed with improved memory management. This issue is fixed in iOS 27.2 and iPadOS 27.2, macOS Golden Gate 27.2, tvOS 27.2, visionOS 27.2, watchOS 27.2. An app may be able to cause unexpected system termination or write kernel memory.

Memory safety OS & kernel Apple Ipados

IBM MQ could allow an authenticated attacker to cause a limited denial of service and obtain very limited information about process memory layout due to an out-of-bounds read when processing a specially crafted client request.

Memory safety IBM Mq Operator

In the Linux kernel, the following vulnerability has been resolved: audit: fix exe mark UAF in kill_rules() kill_rules() removes mixed AUDIT_DIR and AUDIT_EXE rules when an audit tree is pruned. It drops entry->rule.exe before removing the rule from the RCU-visible filter lists. After a rule has been installed with AUDIT_ADD_RULE, which requires CAP_AUDIT_CONTROL, removing the watched directory can race with another task that is still evaluating the rule. In that case, fsnotify can free the executable mark before the reader reaches audit_mark_compare(), causing a use-after-free. KASAN reports: BUG: KASAN: slab-use-after-free in audit_mark_compare+0x8d/0xa0 Unlink the published rules from the RCU-visible lists and retain them on tree->rules for cleanup. If any rule has an executable mark, wait for a single RCU grace period before removing the marks and scheduling the entries for freeing. Otherwise, call_rcu() already provides the required deferred freeing without a synchronous wait.

Memory safety OS & kernel

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix bounds check for skb-backed dynptrs The skb_pointer_if_linear() function checks whether a memory region of length len starting at offset off into the skb is in the linear area, and returns a pointer to the region if so. The check currently subtracts between skb_headlen and offset of the check, and since skb_headlen is unsigned the subtraction can underflow. This causes the bounds check to spuriously pass and generate an arbitrary pointer of the form *(skb->data + off). The only user of this helper is currently skb-backed BPF dynptr code. Returning the wrong pointer leads to the dynptr erroneously being backed with invalid memory. Ensure the subtraction cannot underflow, and fail the check if it would. Use u64 arithmetic to also prevent overflow when calculating (skb_headlen(skb) - off) since off is unsigned.

Memory safety OS & kernel

An issue in mp4v2 2.0.0 allows an attacker to execute arbitrary code via the MP4RtpAtom::ReadHntiType() in src/atom_rtp.cpp. A specially crafted MP4 file can cause an undersized rtp atom to produce a near-2^64 allocation size through an unchecked offset subtraction

Memory safety

RT-Thread through 5.3.0 contains a memory corruption vulnerability in the legacy USB CDC virtual COM port driver that aliases rx_ringbuffer as a Serial V2 rt_serial_rx_fifo in _function_enable(). A connected USB host configuring the CDC device triggers writes past the ring buffer into struct vcom members and an invalid rt_free() on close, causing denial of service.

Memory safety OS & kernel

SurrealDB before 3.3.0 contains a use-after-free vulnerability in surrealdb-core KV backends that pass borrowed transaction state into affinitypool::spawn_local closures relying on future Drop for safety. Rust embedders that leak a dispatched future (e.g. via mem::forget) and drop the transaction cause pool workers to read and write freed memory, risking crashes or memory corruption.

Memory safety Server

A buffer overflow was addressed with improved size validation. This issue is fixed in iOS 26.7.2 and iPadOS 26.7.2, iOS 27.2 and iPadOS 27.2, macOS Golden Gate 27.2, macOS Tahoe 26.7.2, tvOS 27.2, visionOS 27.2, watchOS 27.2. Processing a maliciously crafted audio file may lead to memory corruption.

Memory safety OS & kernel Apple Ipados

A flaw was found in the iscsiuio component of open-iscsi. The DHCPv6 option parser calls strlen() on raw network data without ensuring a NUL terminator is present, causing it to read past the buffer into heap memory. This can result in a daemon crash, a 1-byte heap overwrite, or corruption of the iSCSI initiator name. An attacker on the same network segment can trigger this by sending a crafted DHCPv6 Advertise message.

Memory safety Library

In the Linux kernel, the following vulnerability has been resolved: rtc: ac100: Fix clock provider use-after-free on probe failure ac100_rtc_register_clks() registers the RTC-32k clock with clk_hw_register_fixed_rate() and the clock provider with of_clk_add_hw_provider(). Neither is device managed, and both are released only from ac100_rtc_remove(). The driver core does not call remove() when probe() fails: really_probe() reaches probe_failed below the device_remove() call and goes straight to releasing the device's managed resources. ac100_rtc_probe() ends with return devm_rtc_register_device(chip->rtc); so if that fails after the clocks have been registered, the provider is left on the global of_clk_providers list holding chip->clk_data, which was allocated with devm_kzalloc() and is freed while probe() unwinds. A later lookup on this device tree node then reads freed memory in of_clk_hw_onecell_get(). Consumers that do exactly that exist in tree: the wifi power sequence nodes on sun8i-a83t-bananapi-m3 and sun8i-a83t-cubietruck-plus take <&ac100_rtc 1>, and the sun9i-a80 boards route osc32k through <&ac100_rtc 0>. The window is narrow, as devm_rtc_register_device() can only fail with -ENOMEM here, but the provider is left dangling whenever it does. The RTC-32k clock is leaked on the same path. Since clk_core_lookup() searches a global list that is not scoped per device, __clk_register() rejects the duplicate name with -EEXIST, so the leak also makes a later probe of the same device fail. The error path that returns -EINVAL when the ADDA 4M parent clock cannot be found leaks the RTC-32k clock in the same way. No provider has been registered at that point, so that one is a leak rather than a use-after-free. Register both with devm_clk_hw_register_fixed_rate() and devm_of_clk_add_hw_provider() so that they are released whenever the device goes away, on a failed probe as well as on unbind. Devres releases in reverse order of acquisition, so the provider is removed before chip->clk_data is freed, and the clkout children are now unregistered before their parent rather than after it. ac100_rtc_unregister_clks() and the remove callback then have nothing left to do and are removed.

Memory safety OS & kernel

In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k_htc: bound TX aggregation to MAX_TX_BUF_SIZE __hif_usb_tx() dequeues up to MAX_TX_AGGR_NUM (20) frames into a single tx_buf of MAX_TX_BUF_SIZE (32768) bytes, limiting the batch by record count but never by cumulative byte length. With large frames (MTU 2304), 20 aggregated frames of 2292 bytes each exceed the allocation (20 * 2296 = 45920 bytes), so the memcpy() in the loop writes up to 13152 bytes past tx_buf->buf before usb_submit_urb(). Peek the queue head and stop before copying any record that would cross MAX_TX_BUF_SIZE, then dispatch the current batch. Leftover skbs remain queued and are drained on the next URB completion. The byte bound changes the loop's exit semantics: it can now exit before i == tx_skb_cnt - 1. Stock only finalized tx_buf->len on that last index (len += offset), so an early break would submit a URB holding only the last record's length while every dequeued skb is freed on completion, silently dropping frames. Make tx_buf->len a running total and advance tx_buf->offset per record instead; the stride round_up(nskb->len + 4, 4) is identical to the stock stride when the loop runs to completion. Tested on hardware with an MTU 2304 flood: the loop stops at record 15 (len = 32144, offset = 32144, within 32768), no oversized URB is submitted, and MTU 1500 pings pass 20/20.

Memory safety OS & kernel

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Fix inquiry cache use-after-free The sync command worker holds hdev->req_lock, but inquiry-cache updates and flushes use hdev->lock. Both hci_acl_create_conn_sync() and hci_stop_discovery_sync() look up entries and read their fields without taking hdev->lock. After either lookup returns, a concurrent HCIINQUIRY ioctl can acquire hdev->lock and flush the cache, freeing the entry. The worker then reads the freed entry while preparing a create-connection or remote-name-cancel command. The list traversal also races with cache updates and removal. KASAN reported these accesses: BUG: KASAN: slab-use-after-free in hci_acl_create_conn_sync+0x5f1/0x650 Workqueue: hci0 hci_cmd_sync_work Call Trace: hci_acl_create_conn_sync+0x5f1/0x650 hci_cmd_sync_work+0x13c/0x290 Allocated by task 90: hci_inquiry_cache_update+0x3e6/0x7d0 hci_inquiry_result_evt+0x3cb/0x560 Freed by task 93: hci_inquiry_cache_flush+0x111/0x2b0 hci_inquiry+0x2f2/0x780 hci_sock_ioctl+0x269/0x5f0 BUG: KASAN: slab-use-after-free in hci_stop_discovery_sync+0x3b1/0x3c0 Workqueue: hci0 hci_cmd_sync_work Call Trace: hci_stop_discovery_sync+0x3b1/0x3c0 hci_cmd_sync_work+0x173/0x300 Allocated by task 86: hci_inquiry_cache_update+0x483/0x940 hci_inquiry_result_evt+0x3cb/0x560 Freed by task 91: hci_inquiry_cache_flush+0x13e/0x2f0 hci_inquiry+0x2f2/0x780 hci_sock_ioctl+0x269/0x5f0 Hold hdev->lock across each lookup and all reads from its result. Copy the remote address before unlocking so discovery cancellation does not retain a cache entry pointer. Release the lock before sending synchronous HCI commands, since their completion handlers may need the same lock.

Memory safety OS & kernel

In the Linux kernel, the following vulnerability has been resolved: iio: proximity: aw96103: validate firmware data length The firmware parser reads a length from the binary header and then uses it to walk six-byte register/value entries. A truncated firmware image can make the parser read beyond the copied firmware buffer. A value smaller than the four-byte count field also underflows, producing a very large length. Read the little-endian field with get_unaligned_le32(), as previously proposed by David Lechner. Validate the header size, reject an underflowed length, ensure the resulting payload is contained in the firmware image, and require it to contain whole register/value entries.

Memory safety Device

In the Linux kernel, the following vulnerability has been resolved: drm/virtio: fix memory leak of fence event on execbuffer failure virtio_gpu_execbuffer_ioctl() reserves a DRM event with drm_event_reserve_init() when VIRTGPU_EXECBUF_RING_IDX selects a ring that userspace has enabled polling for. virtio_gpu_init_submit() does this before the BO handles, the command buffer, the syncobj arrays and the in-fence are processed, so every later error path runs with the event already pending, including plain argument validation failures such as an invalid bo_handle or an in-syncobj that carries no fence. On those paths, virtio_gpu_cleanup_submit() drops the out-fence without cancelling the event. The fence is freed without ever having been emitted, taking the only driver-side pointer to the event with it. Closing the DRM file does not help. drm_events_release() unlinks pending events but deliberately leaves the freeing to the driver's later drm_send_event(), which never runs for an orphaned event, so the allocation is leaked permanently. Found when fuzzing the virtio driver with Syzkaller: BUG: memory leak unreferenced object 0xffff88802c176e80 (size 96): comm "syz.1.367", pid 10561, jiffies 4294960122 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ c8 6e 17 2c 80 88 ff ff 00 00 00 00 00 00 00 00 .n.,............ backtrace (crc e1973c6b): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4597 [inline] slab_alloc_node mm/slub.c:4917 [inline] __kmalloc_cache_noprof+0x49d/0x6f0 mm/slub.c:5485 _kmalloc_noprof include/linux/slab.h:988 [inline] _kzalloc_noprof include/linux/slab.h:1309 [inline] virtio_gpu_fence_event_create drivers/gpu/drm/virtio/virtgpu_submit.c:282 [inline] virtio_gpu_init_submit drivers/gpu/drm/virtio/virtgpu_submit.c:398 [inline] virtio_gpu_execbuffer_ioctl+0xbbf/0x1aa0 drivers/gpu/drm/virtio/virtgpu_submit.c:505 drm_ioctl_kernel+0x1f4/0x3e0 drivers/gpu/drm/drm_ioctl.c:817 drm_ioctl+0x5f4/0xc70 drivers/gpu/drm/drm_ioctl.c:914 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix by cancelling and freeing the DRM event on the execbuffer error path before dropping the fence. Clear the fence's event pointer after cancellation so it does not retain a dangling pointer.

Memory safety OS & kernel

In the Linux kernel, the following vulnerability has been resolved: packet: use ubuf_info completion for TX_RING packets tpacket_snd sends skbs with frags pointing into its ring slots. Slots are released when skb->destructor is called. A call to skb_orphan calls skb->destructor before the skb is freed. This can cause the slot to be reused while still linked into the skb. Switch to standard zerocopy completion (ubuf_info) so the slot is only released once all references to the payload are freed or copied. Restore skb->destructor to standard sock_wfree. The ubuf_info completion callback can be called with a NULL skb, but only from net_zcopy_put and related API, used by zerocopy implementations that hold their own reference on the uarg, such as MSG_ZEROCOPY. This uarg is only ever completed from skb_zcopy_clear, so skb is always set. To prevent userspace from aliasing in-flight state on shared ring slots, allocate tpacket_uarg per packet, rather than per slot. This adds a small allocation to the transmit path. Use standard kmalloc to allow backporting to stable kernels. The uarg holds an sk_wmem_alloc reference, rather than an sk_refcnt reference. packet_free_tx_ring waits on sk_wmem_alloc before freeing the ring pages. Always allocate vec->deferred for tx_ring so page-backed rings also wait on sk_wmem_alloc when skb_copy_ubufs drops page refs before calling tpacket_ubuf_complete. Drop the tx_ring.pg_vec test that tpacket_destruct_skb performed before accessing the slot. The sk_wmem_alloc reference now guarantees that the slot is valid. The test is also not sufficient by itself, as it reads pg_vec without pg_vec_lock, so it can race with packet_set_ring. As a result a slot is released when its payload is copied, which can be before transmission (e.g., in skb_orphan_frags_rx). If copied before skb_tx_timestamp() is called, no slot timestamp is recorded, similar to when skb_orphan() was called early in the datapath before this patch. Revert the now unused previous skb_zcopy_.._nouarg infra. Depends on commit 992cc9f94ca9 ("net/packet: defer vmalloc TX_RING free until skbs finish").

Memory safety OS & kernel

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel_pcie: fix tx_handle bounds off-by-one Valid indices into txq->urbd0s/tfds/bufs are 0..txq->count-1, so tfd_index == txq->count is already out of range. Change the guard in btintel_pcie_msix_tx_handle() from '> txq->count' to '>= txq->count'. This issue was reported by Claude Mythos.

Memory safety OS & kernel

Use after free in Windows Cloud Files Mini Filter Driver allows an authorized attacker to elevate privileges locally.

Memory safety OS & kernel Microsoft Windows 10 1809

Use after free in Windows Web Account Manager allows an authorized attacker to elevate privileges locally.

Memory safety OS & kernel Microsoft Windows 10 1809

Heap-based buffer overflow in WebDAV allows an authorized attacker to elevate privileges locally.

Memory safety Microsoft Windows 10 1607

Heap-based buffer overflow in Servicing Stack Updates allows an authorized attacker to elevate privileges locally.

Memory safety OS & kernel Microsoft Windows 10 1607