Buffer Overflow

Memory corruption in the network-facing interface of HPE Networking Instant On firmware (version 3.4.1.0 and earlier) allows an unauthenticated remote attacker to disrupt the affected service and retrieve a limited amount of information from the component. The flaw scores CVSS 3.1 4.8 (Medium) with vector AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:L, so the limiting factor is high attack complexity - reliable triggering depends on specific memory state or precisely crafted input rather than a simple repeatable request - and the realistic impact is service outage plus limited disclosure, with no integrity impact and no confirmed path to code execution. No public exploit code or confirmed active exploitation has been identified at time of analysis, and exploitation additionally requires network reachability to the affected interface.

Memory corruption reachable through an unvalidated format string in the management API of HPE Networking Instant On access points allows an attacker who already holds high administrative privileges to provoke a denial-of-service condition or potentially achieve remote code execution on devices running firmware 3.4.1.0 and earlier. The flaw is scored CVSS 3.1 6.6 (AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H), reflecting that the attacker must be authenticated with high privileges and that reliable exploitation hinges on crafting format-string input that reliably corrupts memory, which often requires memory-layout knowledge or repeated attempts. No public exploit code or confirmed active exploitation was identified at time of analysis, so the dominant risk driver is the high-privilege prerequisite - an attacker must first obtain or compromise an admin account, or chain another vulnerability to reach the vulnerable function.

The Windows Pageant client inside the pageant Rust crate (pageant/src/wmmessage.rs) trusts a peer-controlled u32 response length read from the 8192-byte Pageant shared-memory mapping, so a local process that impersonates the Pageant window can drive MemoryMap::read to allocate up to roughly 4 GiB and copy past the end of the mapped view. In practice this reliably crashes a russh-based SSH client that queries the agent via AgentClient::connect_pageant, and can conditionally expose adjacent committed memory. The issue is fixed in pageant 0.2.3 (russh v0.63.2); exploitation is local-only (CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 6.2), with no CISA KEV entry and no public exploit identified at time of analysis.

A heap-based out-of-bounds write in Eclipse ThreadX GUIX's gx_binres_theme_load() lets a local attacker corrupt memory by supplying a binary theme resource in which the requested theme id is at or beyond the theme count the resource declares. The loader sizes and allocates a zero-byte buffer for that out-of-range id, then walks past the end of the theme table and writes a GX_THEME structure and its tables into the empty allocation, producing out-of-bounds heap corruption. Exploitation requires local placement or substitution of the malicious resource plus application/user interaction to load it (AV:L, PR:N, UI:R), so risk is moderate rather than high; no public exploit has been identified at time of analysis.

Crafted IPCP configuration options sent by a PPP peer can stall a NetX Duo worker thread and drive an out-of-bounds read in Eclipse ThreadX NetX Duo builds that enable the PPP/IPCP add-on. Only devices that terminate PPP links (serial, cellular modem, PPPoE, or L2TP) and accept negotiation traffic from an attacker-controlled or untrusted peer are exposed, and the assessed vector (CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H) reflects adjacency rather than remote reachability. Exploitation is unauthenticated and needs a specifically crafted IPCP option with an oversized declared length, but no public exploit code has been identified and the issue is not listed in CISA KEV at time of analysis.

Out-of-bounds reads in Eclipse NetX Duo's MSRP (Multiple Stream Reservation Protocol) attribute-list parser allow an attacker positioned on the same layer-2 network segment to crash a device by supplying a malformed attribute list whose length field is never validated. The flaw affects NetX Duo builds that have the MSRP / TSN-AVB stream-reservation feature compiled in and actively processing MSRP traffic; because exploitation requires adjacent-network access and yields only a denial of service - no confidentiality or integrity impact, and no code execution is claimed - this is a bounded availability issue rather than a remotely exploitable high-severity defect. There is no CISA KEV listing and no public exploit code identified at time of analysis, so exploitation is assessed as unconfirmed.

An out-of-bounds read in the Eclipse NetX Duo TFTP client lets an attacker-controlled or man-in-the-middle TFTP server return a short ERROR packet that causes the client to read up to 64 bytes past the received datagram. The vulnerable receive paths are in the TFTP client add-on and an unauthenticated remote attacker can trigger the condition when a device initiates a TFTP read or open against the attacker's server, potentially disclosing adjacent packet-pool memory if the application logs or displays nx_tftp_client_error_string, and potentially causing a crash. No public exploit identified at time of analysis, and the provided advisory points to a code-level bounds-check fix; risk is moderate rather than critical because exploitation requires the client-initiated, attacker-as-server model and yields no write primitive.

An out-of-bounds heap read in the DHCP client addon of Eclipse ThreadX NetX Duo (nxd_dhcp_client.c) allows an attacker on the same local link to disclose adjacent heap memory whenever a device performs a DHCP acquisition. The attacker only needs to be a DHCP server, or any LAN host that wins the race to answer the client's broadcast DISCOVER first, and to reply with a single OFFER containing a long run of skippable TLV options; a malformed option layout causes the parser's offset counter to lag the actual read pointer, producing a read roughly a kilobyte and beyond past the end of the message (a one-byte read 164 bytes past a 1648-byte heap region in the reported AddressSanitizer trace). The issue occurs unauthenticated (CVSS PR:N), from an adjacent network (AV:A), on every boot while the interface is unconfigured, with bounded impact limited to low confidentiality and low availability (CVSS 5.3); no public exploit code or confirmed active exploitation was identified at time of analysis.

Out-of-bounds heap read and a control-flow-integrity gap in the Eclipse ThreadX loadable-module loader (module manager) allow an attacker-supplied module image to trigger out-of-bounds memory disclosure when the device loads it through `_txm_module_manager_memory_load` or `_txm_module_manager_in_place_load`. The affected code fully trusts every size and offset field in `TXM_MODULE_PREAMBLE` - the loader APIs accept only a base pointer and no image length, and the preamble `checksum` is never verified - so `code_size` can drive the code-copy loop past the end of the source image; the copy destination is overflow-guarded, so no controlled out-of-bounds write was found. Exploitation is local and conditional: no authentication or privileges are required (PR:N), but attack complexity is high, user/operator action is needed to trigger the load, and only systems that actually load third-party or externally supplied modules are exposed; no public exploit was identified at time of analysis.

Out-of-bounds heap reads in CTranslate2's binary model loader affect all releases before 4.8.1, allowing an attacker who supplies a crafted model file to crash the loading process or disclose adjacent heap memory contents. The flaw is in the model deserialization path (src/models/model.cc), where string fields are read without validating their declared length or null termination; exploitation is local and requires the victim to load an untrusted .bin model through the library's loader. The vendor has released a fix in 4.8.1, and at time of analysis there is confirmed actively exploited status absent (no CISA KEV listing) and no public exploit identified at time of analysis; severity scores cluster around medium (CVSS 4.0 base 6.9; independent assessment CVSS 3.1 AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H), reflecting a genuine memory-safety flaw but a low-to-moderate real-world priority concentrated in workflows that ingest third-party models.

Memory corruption in PyPy's pyexpat module can be triggered by a crafted XML document processed through an external-entity sub-parser, because the child parser keeps a raw C back-pointer to a parent parser struct that PyPy's tracing garbage collector may free while the child is still in use, causing bundled libexpat to dereference freed memory on parsed tokens. Affected builds are PyPy releases prior to 3.11.16 and 3.12.14; the flaw is remotely reachable and unauthenticated (CVSS vectors carry PR:N), but exploitation depends on a specific application coding pattern - creating ExternalEntityParserCreate sub-parsers without retaining a reference to the parent parser - and on that code path processing attacker-supplied XML, which is the AT:P attack requirement in the CVSS 4.0 vector. That prerequisite is why the CVSS 4.0 score is 6.3 Medium with only integrity-low impact recorded, and no public exploit code or confirmed active exploitation was identified at time of analysis; vendor-released patches exist.

Denial of service in Sliver C2 framework 1.7.7 and earlier allows an attacker who controls a compromised implant session to crash the entire teamserver by returning a malformed or zero-length Download response, disrupting all connected operators. Publicly available exploit code exists, but the provided data does not indicate confirmed active exploitation (CISA KEV). The CVSS 4.0 score is 6.8 and the independently assessed CVSS 3.1 vector is AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H, so this is a bounded availability impact requiring an established implant session and an operator-initiated download.

Denial of service in the Wireshark CSN.1 protocol dissector (versions 4.6.0 through 4.6.8 and 4.4.0 through 4.4.18) stems from a heap-based buffer overflow (CWE-122) that crashes the application when it parses malformed CSN.1-encoded data. Exploitation is local and requires user interaction: the target must open an attacker-supplied capture file, and the assessed vector CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:H indicates high attack complexity with a non-deterministic trigger and availability-only impact, with no confidentiality or integrity loss and no confirmed remote path. There is no public exploit identified at time of analysis and the issue is not listed in CISA KEV; at CVSS 4.7 the practical outcome is a recoverable crash rather than code execution, making this a low-priority availability bug.

Denial of service in Wireshark 4.6.0 through 4.6.8 and 4.4.0 through 4.4.18 allows an attacker to crash the application by supplying a crafted packet capture or frame that reaches the MBIM (Mobile Broadband Interface Model) protocol dissector. The CVSS 3.1 vector (AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H, 5.5) shows the attack is local with no privileges required but requires user interaction - typically opening a malicious capture file - and the only impact is availability loss from a recoverable crash with no confidentiality or integrity effect. There is no public exploit identified at time of analysis and no confirmed actively exploited (CISA KEV) status; consistent with the independent assessment, this is a low-priority, availability-only defect despite its medium 5.5 rating, and consumers of untrusted captures should still patch or restrict the MBIM dissector.

Heap-based buffer overflow in Wireshark's sharkd JSON-RPC backend (CVE-2026-95388) allows attacker-controlled packet-capture data to crash the local analysis process in Wireshark 4.6.0 through 4.6.8 and 4.4.0 through 4.4.18. The issue is local and requires user interaction, because an analyst must load a malicious capture into sharkd, and it yields only denial of service (CVSS 5.5, AV:L/PR:N/UI:R, A:H). No public exploit identified at time of analysis, and the practical risk is limited to deployments that actually invoke the sharkd utility.

Crashing denial-of-service in Wireshark 4.6.0 through 4.6.8 and 4.4.0 through 4.4.18 occurs when the RF4CE protocol dissector processes a malformed packet, triggering a heap-based buffer overflow (CWE-122) that terminates the application. The attack is not remotely triggerable: a local user must be induced to open a crafted capture file (or start a live capture containing RF4CE-classified traffic), and no authentication is required (PR:N) while user interaction is mandatory (UI:R), so impact is confined to process availability with no confidentiality or integrity loss. There is no public exploit identified at time of analysis and no CISA KEV listing; the vendor has published an advisory (wnpa-sec-2026-104) that should be consulted for the fixed release.

Wireshark versions 4.6.0 through 4.6.8 and 4.4.0 through 4.4.18 can crash when a user opens a crafted capture file in the Toshiba ('compact router snoop') format, producing a denial-of-service condition limited to the affected process. The underlying issue is a buffer over-read (CWE-126) in the Toshiba wiretap parser; the supplied CVSS vector rates it as local, high-complexity, user-interaction-required, and availability-only, and the independent assessment calls it a genuine but low-priority issue. No public exploit was identified at time of analysis.

A heap-based buffer overflow in the IEEE 802.11 dissector of Wireshark versions 4.6.0 through 4.6.8 and 4.4.0 through 4.4.18 allows local, unauthenticated attackers to cause a denial of service (application crash) by convincing a user to open a crafted packet capture file or by processing malicious live 802.11 traffic. The vulnerability requires user interaction and has only availability impact, with no confidentiality or integrity loss, and is considered low priority despite its Medium CVSS score of 5.5. No public exploit code or active exploitation has been identified at time of analysis; the IEEE 802.11 dissector is enabled by default, so no special configuration is needed beyond processing the malicious data.

Opening a crafted Catapult DCT2000 capture file in Wireshark 4.6.0 through 4.6.8 or 4.4.0 through 4.4.18 triggers a stack-based buffer overflow in the DCT2000 protocol dissector, terminating the application. The issue is local and client-side (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H, base 5.5): the analyst must actively load the malicious file or a capture whose packets are routed through the DCT2000 dissector, and no authentication is required per the vector, but user interaction is. Impact is limited to an availability loss - a crash of the Wireshark process - with no code execution, data disclosure, or integrity impact indicated. No public exploit code was identified at time of analysis, and the flaw is not confirmed actively exploited (not in CISA KEV); the vendor has published advisory wnpa-sec-2026-110 and an associated GitLab work item.

An out-of-bounds write in the printf builtin of the dash shell allows a local user to corrupt one or two bytes past a four-byte reservation when a crafted Unicode \u or \U escape expanding to a five- or six-byte token is processed, including via 'dash -c' with the escape passed as a positional argument to printf or 'echo %b'. The flaw affects dash as shipped in Red Hat Enterprise Linux 6 (CPE cpe:2.3:a:red_hat:red_hat_enterprise_linux_6) and is rated CVSS 4.0 (AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N). No public exploit code was identified at time of analysis, and the bounded write stays within the caller's own shell process, so it provides no inherent privilege escalation.

An out-of-bounds read in Zephyr's MCUmgr SMP-over-console transport (subsys/mgmt/mcumgr/transport/src/serial_util.c) lets a single 7-byte, unauthenticated console line underflow a net_buf length field and hand the SMP layer a bogus ~65 KB payload window over a buffer whose data area defaults to 384 bytes. The flaw affects builds that enable CONFIG_MCUMGR_TRANSPORT_UART (smp_uart.c) or CONFIG_MCUMGR_TRANSPORT_SHELL (smp_shell.c), both of which select MCUMGR_TRANSPORT_SERIAL_HAS_SMP_OVER_CONSOLE; the test-only CONFIG_MCUMGR_TRANSPORT_DUMMY loopback carries the same pattern but has no external input path and is not exploitable. Because exploitation needs only write access to the management console - on many boards an exposed USB CDC-ACM port rather than a bare UART header - the practical impact is a faulted MCUmgr thread (denial of service) plus possible limited memory disclosure via the default-enabled os echo handler; no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV).

Opening a specially crafted PCX image in FastStone Image Viewer 8.3 or earlier triggers an out-of-bounds read in the PCX decoder, causing a crash or limited memory disclosure. The vulnerability requires user interaction and affects only the client-side application; an attacker can exploit it remotely by delivering a malicious file. No public exploit identified at time of analysis, and the vendor has not released a patch.

Opening a maliciously crafted TGA image in FastStone Image Viewer 8.3 or earlier triggers an out-of-bounds read in the TGA Image Handler implemented in FSViewer.exe, allowing a remote attacker to disclose process memory or crash the application. The CVSS 4.0 vector rates this 5.3 (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:L) and carries E:P, indicating proof-of-concept exploit maturity; there is no CISA KEV entry, so confirmed active exploitation is not established. The vendor was contacted about the disclosure but did not respond, so no fixed version is available and the practical risk is a low-priority, client-side memory-safety issue that depends on the victim opening the crafted file (UI:P).

Out-of-bounds write in FastStone Image Viewer through 8.3 lets an attacker corrupt memory - and potentially achieve code execution - when a victim opens or previews a crafted 1bpp RLE image, with impact rated Low across confidentiality, integrity, and availability (CVSS v3.1 AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L). The vulnerable component is the viewer's 1bpp RLE decoder, reachable remotely only through user-initiated file opening, so exploitation requires social engineering or a drive-by download against Windows desktop users rather than any server-side reach; the CVSS v4.0 vector carries an exploit-maturity metric of Proof-of-Concept (E:P), meaning publicly available exploit code exists per that metric, although the independent assessment found no linked working exploit and the issue is not listed in CISA KEV. The vendor was contacted early but did not respond and no patch is available, so priority is LOW-to-MEDIUM with risk mitigated primarily by user-interaction requirements, client-side-only triggering, and consumer desktop deployment.

Out-of-bounds write in FastStone Image Viewer up to version 8.3 allows remote attackers to corrupt memory when a user opens or previews a crafted TGA image file. The vulnerability requires user interaction (UI:P/UI:R) and is rated CVSS 4.0 5.3 (moderate severity). Publicly available exploit code exists (indicated by E:P in the CVSS vector), but no evidence of active exploitation in the wild; the vendor was contacted but did not respond, and no patch is available.

An out-of-bounds read in the Zephyr RTOS CoAP link-format helper match_path_uri() (subsys/net/lib/coap/coap_link_format.c) allows an unauthenticated remote attacker to drive the URI comparison loop one or more bytes past the end of a Uri-Query href= option value by sending a GET /.well-known/core?href=/<prefix> request whose value is a strict prefix of a longer registered resource path. Only devices running the Zephyr CoAP server subsystem with CONFIG_COAP_SERVER_WELL_KNOWN_CORE enabled (the default) and at least one resource declaring struct coap_core_metadata attributes reach the vulnerable code path. The over-read is bounded - in practice a single byte, limited by the compared path length - reads only uninitialized stack tail rather than receive-buffer or attacker-controlled data, cannot influence the response, and yields undefined behaviour rather than information disclosure or a matching error; no public exploit code was identified at time of analysis, and the assessed severity is Low (CVSS 3.7).

A supervisor-mode out-of-bounds write exists in the Zephyr RTOS 802.15.4 L2 transmit path: ieee802154_send() copies packet data into a fixed 125-byte frame buffer without validating the packet length on the unfragmented code path. On builds with CONFIG_NET_L2_IEEE802154_FRAGMENT (enabled by default with CONFIG_NET_6LO), local code that opens a NET_AF_PACKET socket (NET_SOCK_RAW, which skips the 6LoWPAN encoder, or NET_SOCK_DGRAM, which returns early on the address-family check) bound to an 802.15.4 interface can send a payload larger than IEEE802154_MTU and corrupt memory adjacent to the transmit buffer pool, causing a crash or further compromise of kernel state. The flaw is not reachable from the radio because ieee802154_6lo_encode_pkt() length-checks IPv6 packets and forces fragmentation; in a CONFIG_USERSPACE build an unprivileged thread can reach it through the zsock_socket()/zsock_sendto() syscalls, though the overrun is bounded to roughly ll_hdr_len + 3 bytes with the default fixed-size net_buf configuration. No public exploit code was identified at time of analysis and the vendor patch is available (commit 3d4c6177d2dbd77d12d9b14cd75a00cdbd826227).

Power8-optimized strncasecmp in the GNU C Library (glibc) 2.24 and later can read one byte past the caller-supplied length limit, faulting only when the compared strings match up to the final byte of a memory page and the adjacent page is unmapped or non-readable, which crashes the calling process. Per the assessed vector (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L), the flaw is reachable by unauthenticated remote attackers only in applications that pass attacker-controlled strings into strncasecmp, and impact is confined to a low-availability denial of service of that process - no code execution, data disclosure, or modification. Exploitation additionally requires the specific IBM POWER8 CPU family and precise page-boundary alignment, making triggering non-deterministic; no public exploit has been identified at time of analysis and there is no evidence of confirmed active exploitation (CISA KEV). Overall this is a low-severity availability-only bug that is not a priority for most environments.

Malicious or compromised X servers can crash X clients linked against libX11 before 1.8.14 by supplying crafted byte-oriented codeset/locale data that triggers an out-of-bounds read in the client's codeset parser. The flaw is a client-side denial of service with only incidental memory disclosure, not code execution, and it works in the reverse of the usual trust direction: the server attacks the client, so exposure requires a victim application to open an X11 connection to an X server the attacker controls or has compromised (such as a hostile remote or forwarded display). The local attack vector and the requirement for an untrusted display keep realistic risk low; no public exploit code or confirmed active exploitation was identified at time of analysis, and vendor patches are available (upstream fix merged for the 1.8.14 release).

Crashing of X11 client applications can be triggered by a malicious X server exploiting an out-of-bounds read in libX11's X Input Method (XIM) trigger-key registration parser in versions before 1.8.14. This is a medium-severity denial-of-service issue (CVSS 5.5) that requires the victim to connect to an attacker-controlled X server, with user interaction (UI:R) and no authentication required (PR:N), but impact is limited to availability (client crash). No public exploit identified at time of analysis, and it is not confirmed actively exploited (CISA KEV).

Remote, unauthenticated attackers who control an X server can crash X clients linked against libX11 before 1.8.14 by returning crafted XIM (X Input Method) attribute data, because the parser performs an out-of-bounds read (CWE-125). This is an availability-only denial-of-service (CVSS 6.5, AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H) limited by an inverted trust relationship: the victim's client must attach to the attacker's display, so exploitation requires the user to connect to a malicious, compromised, or spoofed X server. No public exploit code has been identified at time of analysis, and the issue is not listed in CISA KEV.

A stack-based buffer overflow in the Cesanta Mongoose MQTT broker tutorial (tutorials/mqtt/mqtt-server/main.c) allows remote, unauthenticated attackers to crash the broker process by sending a manipulated MQTT message to the example's `fn` handler. Only deployments that build and expose this specific tutorial server at version 7.21 or earlier are exposed - the flaw lives in example code shipped with the repository rather than the core embedded networking library, so applications that embed Mongoose without compiling this sample are not affected. Publicly available exploit code exists, and the assessed impact is limited to denial of service, with no code execution or data disclosure indicated.

Remote denial of service in aligungr UERANSIM up to 3.3.0 allows an unauthenticated network attacker who can reach the nr-gnb signaling interface to trigger memory corruption by sending a crafted dedicatedNASMessage in an RRC ULInformationTransfer message. The assessed impact is limited to availability loss (crash) rather than code execution, confidentiality, or integrity compromise, and the affected software is an open-source 5G simulator typically deployed in research or test networks. Publicly available exploit code exists, and the vendor was reportedly contacted but did not respond.

Out-of-bounds write in Trusted Domain Project OpenDKIM through 2.11.0 allows remote, unauthenticated attackers to corrupt memory by sending a crafted DKIM-Signature header whose h= signed-headers tag is manipulated before it reaches dkim_canon_selecthdrs during canonicalization. The practical impact is expected to be a milter crash or mail-flow denial of service, with confirmed memory corruption rather than proven code execution, and the independent assessment maps it to CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L while the supplied CVSS 4.0 vector is AV:N/AC:L/AT:N/PR:N/UI:N. Publicly available exploit code exists for this issue, and no vendor-released patch was identified at time of analysis; the vendor was contacted and reportedly did not respond.

Stack-based buffer overflow in the Edimax BR-6428nC wireless router (firmware version 1.16) allows an authenticated remote attacker to corrupt memory by sending crafted interface1 or interface2 parameters to the /goform/formWizSurvey endpoint, potentially achieving code execution or causing a denial of service. Publicly available exploit code exists, and the severity signals conflict sharply: the CVE publisher assigned a CVSS 4.0 score of 2.1 (low), while our independent assessment rates it 8.8 (high) under CVSS 3.1 due to high confidentiality, integrity and availability impact. No confirmed active exploitation (CISA KEV) has been reported at time of analysis.

Heap out-of-bounds reads in Ghidra 11.2 through 12.1.4 allow an attacker who supplies a crafted binary to make the decompiler read past the end of a string buffer while decoding multi-byte UTF-8, UTF-16, or UTF-32 characters, resulting in a decompiler crash or the leakage of adjacent heap bytes into the decompiled output. The issue is local rather than network-facing: it requires the victim to load and decompile the malicious file (CVSS v4.0 AV:L/PR:N/UI:P, base 4.8 MEDIUM; independent assessment CVSS 3.1 AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:L), and the impact is capped at low confidentiality and low availability with no integrity or code-execution effect. There is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis, though the precondition is trivially met in malware-analysis workflows where hostile binaries are opened by design; a vendor patch is available as an upstream commit.

A stack (or heap) out-of-bounds write in kitty terminal versions 0.40.0 up to but not including 0.49.0 allows any program that can emit escape sequences to the terminal to corrupt a fixed-size four-codepoint buffer while rendering an OSC 66 text-sizing sequence, crashing the kitty process and taking down every window, tab, and child process with it. The flaw is in screen_handle_multicell_command(), which appends each codepoint of a grapheme cluster with lc.chars[lc.count++] = ch without a capacity check in the natural-width branch of the text sizing protocol; a payload carrying a grapheme cluster longer than four codepoints writes one 32-bit value past the buffer for each additional codepoint. Exploitation is local and requires the user to view attacker-influenced terminal output (PR:N, UI:R); the impact is confined to availability - no confidentiality or integrity effect and no evidence of code execution. Vendor-released patch: 0.49.0; no public exploit identified at time of analysis.

In the Linux kernel, the following vulnerability has been resolved: ext4: fix transaction overflow during writeback Commit 95ad8ee45cdb ("ext4: correct the reserved credits for extent conversion") was correct to note that we need to reserve enough credits for all extents possibly underlying a large folio. However it was too eager to reduce the number of reserved credits. Extent conversion may not only need to touch several leaf extent blocks, it may also need to split extents - for example a single large unwritten extent may need to be split into many small written ones in case of sparse folio dirtying. This can thus result not only in extent leaf modifications but also in a need to allocate new extent tree nodes. As a result the reserved transaction credits were not sufficient in some corner cases. Use ext4_meta_trans_blocks() for correct upper bound credit estimate.

An out-of-bounds write in the Linux kernel's mt76 driver for MediaTek MT7921 Wi-Fi chipsets (wifi: mt76: mt7921 CLC record validation) allows a local attacker with existing privileges to corrupt kernel memory by supplying a malformed CLC firmware image whose region count or per-record length is attacker-controlled. The bug is a missing-bounds-check issue (CWE-787) during CLC region parsing on firmware load: the region-table pointer can be forced to precede the firmware buffer, the record loop can fail to advance, or an index can run past the end of phy->clc. The assessed impact is availability-only (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, 5.5) with EPSS of 0.16% (4th percentile) and no public exploit identified at time of analysis; it is not listed in CISA KEV, and a vendor patch is available.

In the Linux kernel, the following vulnerability has been resolved: ppp_async: drop the errored frame instead of resetting its headroom ppp_receive_nonmp_frame() prepends a two-byte direction tag before running the pass/active BPF filters: *(__be16 *)skb_push(skb, 2) = htons(PPP_FILTER_INBOUND_TAG); Nothing on the receive path guarantees those two bytes of headroom. The frame-error path in ppp_async's process_input_packet() resets a reused skb's headroom to zero while claiming to restore it to a freshly allocated state - but a fresh skb from dev_alloc_skb() carries NET_SKB_PAD: err: if (skb) { /* make skb appear as freshly allocated */ skb_trim(skb, 0); skb_reserve(skb, - skb_headroom(skb)); } ap->rpkt still points at that skb, so the next frame is reassembled into it with no headroom at all. A peer that sends a bad-FCS frame followed by one beginning ff 03 then leaves a single byte of headroom by the time the filter tag is pushed, which lands one byte below skb->head: skbuff: skb_under_panic: len:49 put:2 head:ffff888003c10000 data:ffff888003c0ffff tail:0x30 end:0x640 dev:<NULL> kernel BUG at net/core/skbuff.c:214! RIP: 0010:skb_panic+0x13e/0x230 Call Trace: skb_push+0xbd/0x100 ppp_receive_nonmp_frame+0x48a/0x1d10 ppp_input+0x4e9/0x2f80 ppp_async_process+0x2a/0xe0 tasklet_action_common+0x20f/0x8a0 handle_softirqs+0x18e/0x590 Kernel panic - not syncing: Fatal exception in interrupt Zeroing the headroom violates the NET_SKB_PAD guarantee that dev_alloc_skb() gives the rest of the receive path. Besides the filter panic above, when CCP compression is enabled ppp_decompress_frame() hands skb->data - 2 to ->decompress()/->incomp(), which then reads out of bounds before skb->head for the same reason. Rather than restore the headroom, drop the errored frame - as ppp_synctty already does on its error path - and clear ap->rpkt so the next frame is reassembled into a fresh skb with proper headroom. This is simpler and fixes both the filter under-panic and the CCP out-of-bounds read. The original V1 of this patch made room in ppp_receive_nonmp_frame() with skb_cow_head(); Eric pointed out that fixing the root cause in the transport is the right approach. Found by fuzzing the PPP receive path with a mutating peer on a pty; it is an interesting (remote) DoS: root configures PPP, the peer supplies two crashing frames. The reproducer (repro-ppp-skb.c, unchanged from v1) panics in about a second, and returns cleanly with this applied.

In the Linux kernel, the following vulnerability has been resolved: accel/qaic: Address potential out-of-bounds read in resp_worker() Although 'commit 2feec5ae5df7 ("accel/qaic: Handle DBC deactivation if the owner went away")' fixes the scenario it was intended for by walking the message and only decoding QAIC_TRANS_DEACTIVATE_FROM_DEV, if present, it skipped over the bounds checking code that is included in decode_message(). This could lead to issues such as reading past the slab allocation's end, infinite loops or kernel panics. For those issues to happen, a malformed wire message is needed to be sent from the device. Instead of duplicating the bounds checking code already present in decode_message(), use the function inside resp_worker().

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix percpu map update indexing with sparse CPU IDs Per-CPU array, hash, and cgroup storage map updates without BPF_F_CPU or BPF_F_ALL_CPUS use a value buffer whose per-CPU slots are packed in possible-CPU order. The buffer is sized as: round_up(value_size, 8) * num_possible_cpus() The update paths iterate over possible CPUs, but use the logical CPU ID to calculate the source offset: value + size * cpu This only works when possible CPU IDs are contiguous starting at zero. For example, with a possible CPU mask of 0,2-3, the buffer contains three slots corresponding to CPUs 0, 2, and 3. CPU2 is therefore expected to use slot 1 and CPU3 slot 2. Instead, the current code uses slots 2 and 3 respectively, causing incorrect per-CPU values and an out-of-bounds read from the update buffer for CPU3. The corresponding lookup paths already use a dense offset while iterating over possible CPUs. Do the same for the array, hash, and cgroup storage update paths, advancing the source offset once for each possible CPU. BPF_F_ALL_CPUS continues to use the same value for every CPU.

A local denial-of-service condition in the Linux kernel's legacy NTFS driver allows a user able to mount a crafted NTFS filesystem image to crash the kernel by supplying a boot sector with sectors_per_cluster set to 0 or another non-power-of-two value. The flaw is reached through parse_ntfs_boot_sector(), which computes ffs(sectors_per_cluster) - 1 and then performs an out-of-bounds shift (shift exponent 4294967295), tripping a UBSAN shift-out-of-bounds report in fs/ntfs/super.c; only kernel availability is impacted, with no code execution or data disclosure (CVSS 5.5, AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Vendor patches are available (fixed in Linux 7.2.7 and 7.3-rc2 via commits 7524c3145a3bac92bebbc47a29c007f1d874c9b3 and 323751a604e7533fa473874d999371592a614207), and there is no public exploit identified at time of analysis; EPSS is 0.14% (3rd percentile), consistent with a low-priority local bug.

In the Linux kernel, the following vulnerability has been resolved: smb/client: validate new EOF for insert range smb3_insert_range() does not check if the new file size (i_size + len) is valid. This allows FALLOC_FL_INSERT_RANGE to bypass RLIMIT_FSIZE, exceed s_maxbytes, or produce a size outside the loff_t range. Use check_add_overflow() to calculate the new EOF. Validate it with inode_newsize_ok() before modifying the file. Reproducer, using a file on a CIFS mount: bash -c ' FILE=/mnt/cifs/repro trap "" SIGXFSZ ulimit -f 3072 # RLIMIT_FSIZE = 3 MiB # A regular write is stopped at 3 MiB. dd if=/dev/zero of="$FILE" bs=1M count=4 status=none stat -c "size after write: %s" "$FILE" # Insert 2 MiB into a 2 MiB file. truncate -s 2M "$FILE" fallocate -i -o 0 -l 2M "$FILE" stat -c "size after insert: %s" "$FILE" ' Before this change, the regular write stops at the 3 MiB limit, but insert range grows the file to 4 MiB: dd: error writing '/mnt/cifs/repro': File too large size after write: 3145728 size after insert: 4194304 After this change, insert range also fails at the limit and leaves the 2 MiB file unchanged: dd: error writing '/mnt/cifs/repro': File too large size after write: 3145728 fallocate: fallocate failed: File too large size after insert: 2097152

In the Linux kernel, the following vulnerability has been resolved: sctp: fix soft lockup from unpadded ASCONF-ACK parameter iteration sctp_verify_asconf() walks ASCONF-ACK parameters with sctp_walk_params(), which advances by SCTP_PAD4(length), while the consumer sctp_get_asconf_response() iterates the same parameters advancing by the raw length, without padding. A single odd-length parameter desynchronises the two walks and makes the consumer interpret attacker-controlled bytes at a misaligned offset. When those bytes yield a length of zero, the while loop over asconf_ack_len makes no progress, spinning forever in softirq context, and the watchdog reports a soft lockup. All reads stay within the received skb, so the lockup is a pure remote denial of service. A remote peer can trigger it with a crafted ASCONF-ACK on an ADD-IP enabled association with an outstanding ASCONF (RFC 5061 section 4.1.2 requires the chunk to be authenticated, but the predefined empty key id 0 allows the peer to compute the same association HMAC from publicly exchanged parameters, so the gate does not help). The SCTP_PARAM_ERR_CAUSE case of sctp_verify_asconf() also performs no length check, letting a parameter without a complete error header reach the consumer, which reads errhdr.cause past the end of the parameter, an out-of-bounds read. Reject SCTP_PARAM_ERR_CAUSE parameters shorter than sizeof(struct sctp_addip_param) + sizeof(struct sctp_errhdr) at the verifier, and advance the consumer iterator with the same padding rule as the verifier to keep the two walks in lockstep. The verifier change guarantees a complete error header in every ERR_CAUSE parameter the consumer can see, so the consumer's asconf_ack_len check is dropped and it returns err_param->cause directly. The consumer padding fix is still required because odd lengths remain valid for SCTP_PARAM_ERR_CAUSE per RFC 5061. The issue was found by ZeroHive, a vulnerability hunting agent at Tencent Yunding Lab.

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel: validate version TLV value lengths btintel_parse_version_tlv() verifies that a complete TLV is present in the response, but it does not ensure that the value is long enough for the specific TLV type. A short value can therefore cause an out-of-bounds read through get_unaligned_le16(), get_unaligned_le32(), or memcpy(). Reject values shorter than the minimum required by each known TLV type. Also reject responses that do not contain the Command Complete Status field.

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix out-of-bounds write in l2cap_ecred_connect l2cap_chan_connect() tries to ensure there are no more than L2CAP_ECRED_CONN_SCID_MAX pending ECRED channels, so they fit in the same L2CAP_ECRED_CONN_REQ that l2cap_ecred_connect() constructs. However, the check only counts deferred channels. If 6 L2CAP sockets are connected at the same time in order DDDDND (D=deferred, N=non-deferred), the last can bump the total to max+1. It results to one __le16 written out of bounds of the scid array, and an invalid ECRED_CONN_REQ being sent. Fix by leaving room for the non-deferred pending ECRED channels in the counting in l2cap_chan_connect(), so the limit can't be exceeded. Move counting under same critical section where the channel is added. Although race conditions involving this appear unreachable, it's easier to see. Also add WARN_ON_ONCE check in l2cap_ecred_defer_connect() to make this less brittle.

In the Linux kernel, the following vulnerability has been resolved: net: ethernet: oa_tc6: Improve the error recovery When oversubscribed traffic causes lot of buffer overflow errors, probably due to loss of data chunks, driver fails to find a data chunk with end_valid bit set, before it runs out of sk buffer space. As a result, assert is seen during skb_put. Now, check is made if skb buffer has enough tailroom for the incoming data before accepting. If there is no room, current frame is abandoned and it will start looking for a data chunk with start_valid bit, that is a new frame. SK buffer allocation error is considered as recoverable error. rx_buf_overflow flag is too specific and no longer the only condition this flag is used for. Therefore it is renamed as wait_until_start_valid. This is more appropriate as this flag is used to look for the next data chunk with SV bit set, after failures like buffer overflow, buffer allocation failure, skb pointer validity besides buffer overflow error. Not writing to status0 if it reads 0.

In the Linux kernel, the following vulnerability has been resolved: bonding: alb: fix uninitialized transport header access in alb_determine_nd() alb_determine_nd() uses icmp6_hdr(skb) to inspect ICMPv6 headers. However, in xmit paths (e.g. packets sent via AF_PACKET / raw sockets or forwarded packets), skb->transport_header is not guaranteed to be initialized. While pskb_network_may_pull() ensures the packet data is linear starting from the network header, it does not set or adjust the transport header offset. Dereferencing icmp6_hdr(skb) can therefore access out-of-bounds memory. Fetch the icmp6hdr directly after ipv6hdr following pskb_network_may_pull(), and reload ipv6hdr in case pskb_may_pull() reallocated skb->head. Also remove the unused bond argument from alb_determine_nd().

In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Avoid out-of-bounds cpumask_of_node() call in _base_assign_reply_queues() dev_to_node() can return NUMA_NO_NODE (-1) on systems without NUMA topology information for the PCI device, such as single-socket boards that don't expose device-to-node affinity. Passing -1 directly into cpumask_of_node() indexes node_to_cpumask_map[-1], an out-of-bounds array read caught by UBSAN: UBSAN: array-index-out-of-bounds in arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask *[1024]' Fall back to cpu_online_mask when no NUMA node is available, rather than assuming dev_to_node() always returns a valid node index.

Reversed argument ordering in the Linux kernel IPVS connection-synchronization sender (sync protocol version 1) causes hton_seq() to write to the wrong buffer, leaving 24 bytes of a kmalloc-backed sync message uninitialized while clobbering live connection sequence state with values read back from that buffer. The flaw, tracked as CVE-2026-98078, affects Linux kernels since the sync code was introduced at 2.6.39 and is reachable only on hosts acting as IPVS/LVS directors that have the sync daemon explicitly enabled in master/sender mode on protocol version 1 - a non-default, specialized load-balancer cluster configuration. The CVSS vector (AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L) and the 4.4 base score reflect local access with low privileges and limited confidentiality, integrity, and availability impact; EPSS is only 0.20% (9th percentile) and there is no public exploit identified at time of analysis, making this a low-priority defensive-patch issue rather than an urgent threat.

Out-of-bounds read in the Linux kernel's Intel AVS ASoC audio driver can crash the kernel when a local user with low privileges causes an oversized module config ID from a DSP topology binary to index the init_configs array. The flaw is limited to local, low-privilege access on systems with Intel AVS audio hardware and the relevant driver loaded; it is not remotely reachable and, per the assessed vector, has no confidentiality or integrity impact. EPSS is low (0.17%, 5th percentile), no public exploit code has been identified at time of analysis, and vendor fixes are available in Linux 6.18.53, 7.2.7, and 7.3-rc3 or corresponding stable backports.

In the Linux kernel, the following vulnerability has been resolved: net: usb: cx82310_eth: drop URB after 0xffff reboot sentinel to prevent partial_data heap overflow The 0xffff length sentinel detects a router reboot and schedules re-enabling of ethernet mode, but then falls through to the rest of the loop body. The next check is } else if (len > CX82310_MTU) { which is the else of the just-matched if -- it never fires for len == 0xffff. The MTU bound that normally caps the incomplete-packet save path is silently bypassed. With 0xffff > skb->len always true (rx_urb_size is 4096), the incomplete-packet branch saves dev->partial_len = skb->len bytes into dev->partial_data. partial_data is kmalloc(hard_mtu) = kmalloc(CX82310_MTU + 2) = 1516 bytes, but skb->len after the 2-byte header pull can be up to 4094. A device that sends a 4096-byte URB starting with [0xff 0xff] therefore copies 4094 device-provided bytes into a buffer allocated for 1516 bytes, exceeding its requested size by 2578 bytes. The next URB then reads dev->partial_len (4094) back from the same 1516-byte buffer and dev->partial_rem (65535 - 4094 = 61441) from the new URB's ~4KB skb, both well past their allocations, and delivers the spliced result as a 64KB "frame" to the network stack. Bail out of rx_fixup after scheduling the re-enable work; the remainder of a reboot-marker URB is not meaningful packet data. This restores the invariant that partial_len < CX82310_MTU + 2 on the save path, since every other route there has already passed the MTU check.

In the Linux kernel, the following vulnerability has been resolved: virtio_console: do not free control-out buffers on remove __send_control_msg() publishes &portdev->cpkt as the control-out virtqueue cookie. remove_vqs() walks every virtqueue and passes leftover cookies to free_buf(), which treats them as struct port_buffer and reads sgpages. If a control message is still on c_ovq when the device is unbound, free_buf() reads past the ports_device object. KASAN reported slab-out-of-bounds in free_buf(): free_buf remove_vqs virtcons_remove unbind_store The object was the ports_device allocated in virtcons_probe(). Drain c_ovq without freeing. The packet lives in portdev and is released with it.

In the Linux kernel, the following vulnerability has been resolved: vhost/vdpa: reject VRING_NUM larger than device max vhost_vring_set_num() accepts any non-zero power-of-two queue size that fits in 16 bits. vhost-vdpa then passes that value to set_vq_num() without comparing it with get_vq_num_max(). A process with access to /dev/vhost-vdpa-* can therefore configure a queue larger than the device advertises. With vdpa_sim, the worker can walk descriptors beyond the mapped descriptor ring. KASAN reports a 16-byte out-of-bounds read, corresponding to one vring_desc, in the vringh IOTLB path: BUG: KASAN: out-of-bounds in _copy_from_iter Read of size 16 copy_from_iotlb copydesc_iotlb vringh_getdesc_iotlb vdpasim_net_work Cache get_vq_num_max() immediately after reset. Some backends derive it from writable queue-size state, so querying it after SET_NUM may return the current size instead of the device capability. Invalidate the cached value before reset so a failed reset leaves SET_NUM disabled. For VHOST_SET_VRING_NUM, copy the complete vring state once and use the same index and size for validation, vq->num, and set_vq_num(). This ensures that validation and use operate on the same copied values.

In the Linux kernel, the following vulnerability has been resolved: net: ipv6: Fix UDP length overflow with PMTU discover and big MTU This commit bounds cork->base.fragsize to IP6_MAX_MTU for UDP sockets to avoid a possible overflow of UDP length that triggers a WARN in udp_set_len_short when setsockopt IPV6_MTU_DISCOVER is set to IPV6_PMTUDISC_DO or IPV6_PMTUDISC_PROBE, and a large packet is sent over a netdev with an unusually large MTU. Steps to reproduce (included in the new selftest): 1. Set device MTU bigger than IP6_MAX_MTU. cork->base.fragsize will be set to that MTU in ip6_setup_cork. 2. Set IPV6_MTU_DISCOVER to IPV6_PMTUDISC_PROBE or IPV6_PMTUDISC_DO. It lets maxnonfragsize be set to device MTU (cork->fragsize) in __ip6_append_data, rather than to IP6_MAX_MTU. 3. Send 65528 bytes of payload (+8 bytes of UDP header, +40 bytes of IPv6 header). Device MTU allows it (it's only one byte bigger than IP6_MAX_MTU, 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. To avoid breaking sending UDP jumbograms over raw IPv6 sockets, limit the change to UDP sockets only. The original overflow bug with IPv6 and IPV6_PMTUDISC_DO seems to predate git history (verified reproduction on 2.6.21), was fixed later, and then reappeared in commit 427faee167bc ("net: ipv6: introduce ip6_dst_mtu_maybe_forward"), which is chosen as the Fixes tag here. The overflow with IPV6_PMTUDISC_PROBE reproduces since its introduction in commit 628a5c561890 ("[INET]: Add IP(V6)_PMTUDISC_RPOBE").

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel_pcie: validate packet_len before skb_put_data btintel_pcie_submit_rx_work() reads packet_len from rfh_hdr without checking if it exceeds the RX buffer size. An oversized packet_len can lead to an out-of-bounds read in skb_put_data(). Validate packet_len to ensure it is non-zero and does not exceed BTINTEL_PCIE_BUFFER_SIZE - sizeof(*rfh_hdr), logging an error when invalid. This issue was reported by Claude Mythos. It can be simulated either by using customized firmware configured to return an invalid packet_len or by modifying rfh_hdr->packet_len in the driver before calling btintel_pcie_submit_rx_work().

In the Linux kernel, the following vulnerability has been resolved: perf/core: Allow list_del during perf_event_overflow() A PMU might use perf_sched_cb_inc() and perf_sched_cb_dec() interface to get the PMU call back function pmu::sched_task invoked at schedule in and schedule out. This is achieved by walking along the list anchored by sched_cb_list. The following scenario might lead to a list corruption. perf_pmu_sched_task() for_each_list_entry(..., &sched_cb_list) +--> __perf_pmu_sched_task() +--> event->pmu->sched_task()) +--> PMU_push_sample() +--> perf_event_overflow() +--> __perf_event_overflow() +--> pmu->stop() +--> perf_sched_cb_dec() remove entry from sched_cb_list while list node in use. This happens when ioctl(fd, PERF_EVENT_IOC_REFRESH, xxx) has been invoked and perf_event::event_limit hits zero. Prevent the list corruption and convert for_each_list_entry() to for_each_list_entry_safe().

In the Linux kernel, the following vulnerability has been resolved: tracing: Fix memory corruption from the histogram stacktrace modifier parse_field() sets HIST_FIELD_FL_STACKTRACE from the ".stacktrace" modifier before it looks the field name up, and nothing afterwards checks that the name resolved to a field which holds a stacktrace. create_hist_field() picks HIST_FIELD_FN_STACK on the strength of the field pointer alone, which reads a __data_loc word from the record and follows its low 16 bits as an offset into the same record. event_hist_trigger() takes the first word there as an entry count and copies that many longs into a 31 entry array: n_entries = *stack; memcpy(entries, ++stack, n_entries * sizeof(unsigned long)); Neither end of that copy is bounded, and the count is whatever the event holds at the offset, so any field will do: # cd /sys/kernel/tracing/events/sched/sched_process_fork # echo 'hist:keys=parent_pid.stacktrace' > trigger # (true) BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:rb_insert_color+0x18/0x130 timerqueue_linked_add+0x7e/0xd0 enqueue_hrtimer+0x39/0xb0 __hrtimer_run_queues+0x10f/0x1f0 </IRQ> RIP: 0010:memcpy+0xc/0x30 event_hist_trigger+0x165/0x690 The timer interrupt landed on the rbtree the copy had already run over. No debug options are needed for this; KASAN reports the same write as an out-of-bounds read of 13835058055416381440 bytes. Documentation/trace/histogram.rst already states the rule, "must be a long[] type", so enforce it once the name has been resolved. Names which resolve to no field at all, "hitcount.stacktrace" and the common_* pseudo-fields, are refused for the same reason: they hold no stacktrace to read.

In the Linux kernel, the following vulnerability has been resolved: tracing: Fix memory corruption from a "STACKTRACE" histogram key "cpu", "CPU", "stacktrace" and "STACKTRACE" are generic fields, defined with an offset and a size of zero so that the filter code can match them by name. parse_field() maps them onto their common_* equivalents for backward compatibility, but unlike the common_* names it hands the placeholder back to the caller instead of NULL. create_hist_field() takes a non-NULL field as a promise that the record carries a stacktrace and picks HIST_FIELD_FN_STACK, so the __data_loc word is read from offset 0, that is from common_type, and its low 16 bits are followed as an offset into the record. What is found there becomes the length of an unbounded memcpy. Pick an event whose id is small enough that the offset stays inside its own record and the length is a kernel text address: # cd /sys/kernel/tracing # echo 'hist:keys=STACKTRACE' > events/ftrace/print/trigger # echo hello > trace_marker Oops: general protection fault, probably for non-canonical address RIP: 0010:rb_next+0x23/0x60 </IRQ> RIP: 0010:memcpy+0xc/0x30 event_hist_trigger+0x2e7/0x12c0 Kernel panic - not syncing: Fatal exception in interrupt Leave the field NULL, which is what the comment above the branch says the code does and what common_stacktrace already does. FILTER_CPU and FILTER_COMM are left alone, their create_hist_field() branches never look at the field.

In the Linux kernel, the following vulnerability has been resolved: tracing: Keep the entry count when the histogram stats allocation fails print_entries() uses n_entries both as the number of sort entries and as its own return value, so the -ENOMEM it stores when the stats allocation fails overwrites the count that the cleanup still needs: n_entries = tracing_map_sort_entries(map, ...); if (n_entries < 0) return n_entries; ... if (!stats) { n_entries = -ENOMEM; goto out; } ... out: tracing_map_destroy_sort_entries(sort_entries, n_entries); tracing_map_destroy_sort_entries() takes an unsigned int and loops up to it, so -ENOMEM arrives as 4294967284. It walks an array of at most map->max_elts pointers and calls destroy_sort_entry(), which dereferences and frees, on whatever lies past the end. Reading the hist file of a trigger with a .percent value, with that allocation forced to fail: BUG: KASAN: vmalloc-out-of-bounds in tracing_map_destroy_sort_entries+0xa0/0xb0 Read of size 8 at addr ffffc90000045000 by task init/1 tracing_map_destroy_sort_entries+0xa0/0xb0 hist_show+0x6f7/0x1df0 seq_read_iter+0x2b8/0x1190 vfs_read+0x176/0xa40 The buggy address belongs to a 4-page vmalloc region starting at ffffc90000041000 allocated at tracing_map_sort_entries+0x5c/0xd50 A few pages further the fault is fatal. The registers at the oops confirm the bound: the loop's end pointer less the array start, over the pointer size, is 4294967284. Return the error in a separate variable and leave n_entries holding the count, the way tracing_map_sort_entries() does on its own error path. The stats block is only entered for a value carrying .percent or .graph, which __create_val_field() has rejected since v6.3, so this cannot be reached in mainline as it stands. It becomes reachable again with "tracing: hist: let values keep the percent and graph modifiers", so it should be applied first.

In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Validate firmware log buffer metadata The tracing log headers parsed by fw_log_print_buffer() reside in DMA-shared BOs that the NPU firmware can write to. fw_log_from_bo() validated log->header_size and log->size, but fw_log_print_buffer() re-read those same fields from shared memory afterwards, allowing a TOCTOU where firmware changes them between the check and the use, and making the host dereference out-of-bounds addresses while printing logs. Snapshot the validated values once with READ_ONCE() and pass them down explicitly in a new struct ivpu_fw_log_desc instead of re-reading them from the shared struct.

In the Linux kernel, the following vulnerability has been resolved: bootconfig: Fix integer overflow in initrd size check Sashiko reported that in get_boot_config_from_initrd(), a crafted initrd with a huge bootconfig size (such as 0xFFFFFFFF) can cause the pointer arithmetic: data = ((void *)hdr) - size; to wrap around on 32-bit systems (or when pointer subtraction overflows). Because data wraps around, the subsequent bounds check: if ((unsigned long)data < initrd_start) evaluates to false, bypassing the check. The kernel then calls xbc_calc_checksum(data, size), which attempts to read 4GB of memory, hitting unmapped pages and triggering a fatal kernel page fault during early boot. Furthermore, on 64-bit systems with an initrd > 4.29 GB, an unbounded 32-bit size can similarly bypass the initrd_start check. Fix this by: 1. Ensuring the initrd is at least large enough to contain the bootconfig footer and verifying hdr is within the initrd bounds. 2. Checking that size does not exceed XBC_DATA_MAX and does not exceed the available space between initrd_start and hdr before performing pointer subtraction.

In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: analogix_dp: fix unchecked bound endpoint name length rockchip_dp_drm_encoder_enable() uses sprintf() to format a device tree path into a 32-byte stack buffer. Device tree paths are not limited to this size, so a sufficiently long path can overflow the buffer. Use snprintf() with the destination size to truncate the generated name and keep the writes within bounds.

In the Linux kernel, the following vulnerability has been resolved: net: dsa: tag_brcm: legacy FCS: request needed tailroom The legacy FCS tagger calculates the CRC over skb->len bytes starting at skb->data. When a nonlinear skb reaches the tagger, this reads past the linear head into unrelated slab memory. The tagger appends an Ethernet FCS but does not declare that tailroom. As a result, DSA leaves NETIF_F_SG and NETIF_F_FRAGLIST enabled on the user port, and nonlinear skbs can reach the CRC calculation. Declare the required tailroom. DSA will then clear those features and the networking core will linearize skbs before the tagger runs. A KASAN-enabled dsa_loop test using this tagger reports: BUG: KASAN: slab-out-of-bounds in crc32_le Read of size 1 at addr ffff8880397086c0 by task exp/135 Call Trace: crc32_le (lib/crc/crc32-main.c:38) brcm_leg_fcs_tag_xmit (net/dsa/tag_brcm.c:343) dsa_user_xmit (net/dsa/user.c:942) dev_hard_start_xmit (net/core/dev.c:3937) __dev_queue_xmit (net/core/dev.c:4926) packet_sendmsg (net/packet/af_packet.c:3110) __sys_sendto (net/socket.c:2281) The buggy address belongs to the object at ffff888039708400 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 0 bytes to the right of allocated 704-byte region [ffff888039708400, ffff8880397086c0)

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix one-byte OOB read in smb2_parse_native_symlink() When parsing a share-root relative native symlink, memcpy copies smb_target+1 (skipping the leading separator) but uses strlen(smb_target)+1 as the length, reading one byte past the allocated buffer. This fixes the following KASAN splat when accessing an SMB symlink with a target of '\a\b': BUG: KASAN: slab-out-of-bounds in smb2_parse_native_symlink+0x4f5/0xca0 Read of size 5 at addr ffff88800878fe21 by task netfsfuzz-execu/1 CPU: 1 UID: 0 PID: 1 Comm: netfsfuzz-execu Tainted: G N 7.2.0-11943-g2709dd5ae32f-dirty #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996) Call Trace: <TASK> dump_stack_lvl+0x7b/0xa0 print_report+0xd0/0x630 kasan_report+0xe5/0x120 kasan_check_range+0x105/0x1b0 __asan_memcpy+0x23/0x60 smb2_parse_native_symlink+0x4f5/0xca0 parse_reparse_point+0x68a/0x1530 reparse_info_to_fattr+0x752/0xa20 cifs_get_fattr+0x873/0x15b0 cifs_get_inode_info+0xc0/0x310 cifs_lookup+0x308/0xa70 __lookup_slow+0x122/0x2b0 lookup_slow+0x50/0x70 path_lookupat+0x525/0xaf0 filename_lookup+0x1f2/0x550 vfs_statx+0xd1/0x1a0 vfs_fstatat+0x65/0xc0 __do_sys_newfstatat+0x9a/0x120 do_syscall_64+0xdd/0x4a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved: smb: client: fail DACL rewrite when the new DACL exceeds 64K replace_sids_and_copy_aces() and set_chmod_dacl() accumulate the size of the DACL they build in a u16. That accumulator can wrap. validate_dacl() caps num_aces at (dacl_size - sizeof(struct smb_acl)) / 20, i.e. 3276 for a maximally sized DACL, while each rewritten ACE can grow to sizeof(struct smb_ace) (76 bytes) once its SID is replaced with one carrying SID_MAX_SUB_AUTHORITIES sub-authorities. The worst case is therefore sizeof(struct smb_acl) + 3276 * 76 = 248984 bytes, far beyond what a u16 can hold. A wraparound is reached with 863 ACEs. After the wraparound, ndacl_ptr->size becomes meaningless and the offset will point anywhere in the ACE array. As a result, we will see corruption of the DACL, which then gets sent to the server. This is not an out-of-bounds write as the allocation now covers the worst-case expansion, so writes will always go into the buffer. Adjust the code to use a u32 internally and return -EOVERFLOW in the overflow case. The operation must be refused, because a DACL can only hold 2^16-1 bytes on the wire and larger DACLs cannot be represented. set_chmod_dacl() carries the same pattern and is fixed the same way. It only wraps once the source DACL comes within roughly 380 bytes of the 64K ceiling, but the failure mode is identical.

In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Bound VP index against VP_CTRL IOCB bitmap size The VP control IOCB selects its target virtual port by setting one bit in vp_idx_map, a fixed 16-byte (128-bit) array in both vp_ctrl_entry_24xx and vp_ctrl_entry_24xx_ext. qla25xx_ctrlvp_iocb() computes map = (vp_index - 1) / 8 and writes vce->vp_idx_map[map] without checking that map stays within the array. max_npiv_vports is taken from firmware and only sanitized to a MIN_MULTI_ID_FABRIC-aligned boundary, so it can legitimately be 191 or 255, and qla24xx_control_vp() only rejects vp_index >= max_npiv_vports. A vp_index above 128 therefore yields map >= 16 and an out-of-bounds write of up to 16 bytes past vp_idx_map, corrupting the trailing IOCB fields (or the adjacent request-ring slot on the 64-byte layout). Reject a vp_index that cannot be represented in the IOCB bitmap in qla24xx_control_vp(), and add a defensive ARRAY_SIZE() guard in qla25xx_ctrlvp_iocb() before the write. Adapters that report the usual 63 or 127 NPIV vports are unaffected.

In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Validate BSG request_len before reading vendor_cmd[] The FC BSG transport allocates job->request via memdup_user() using the exact user-supplied request_len. For FC_BSG_HST_VENDOR, fc_bsg_host_dispatch() only guarantees request_len covers msgcode and vendor_id; it does not account for the vendor_cmd[] flexible array. qla2xxx then reads the command selector vendor_cmd[0] and, in several sub-handlers, vendor_cmd[1]/[2] or structures overlaid on the vendor command area without verifying request_len. A caller holding CAP_SYS_RAWIO can submit a short request whose vendor_id matches the host, triggering out-of-bounds heap reads (KASAN-detectable, and able to mis-select a command or panic). Add a central guard in qla2x00_process_vendor_specific() so the selector is always in bounds, restrict the early vendor_cmd[0] read in qla24xx_bsg_request() to sufficiently long vendor messages, and add request_len checks to the sub-handlers that read further: qla24xx_proc_fcp_prio_cfg_cmd(), qla2x00_process_loopback(), qla84xx_reset(), qla84xx_updatefw(), qla2x00_read_optrom(), qla2x00_update_optrom(), qlafx00_mgmt_cmd() and qla28xx_validate_flash_image().

Risk cannot be meaningfully assessed from the provided data. CVE-2026-94282 is reported solely by the vendor source 'ubuntu', indicating that a package distributed through Ubuntu channels is affected, but no description, CVSS score, CVSS vector, CWE identifier, or affected-version metadata accompanies the record, so the nature of the flaw, the attack surface, and the deployment contexts at risk are all unknown. Exploitation status: no public exploit identified at time of analysis. Authentication requirements are not confirmed from available data, and no CISA KEV listing or EPSS score was provided to indicate real-world exploitation or likelihood. Until the corresponding Ubuntu Security Notice and upstream advisory are retrieved, this record should be treated as an unresolved tracking identifier rather than a characterized vulnerability.

Memory corruption and denial-of-service in Espruino's JavaScript lexer can be triggered by crafted raw or binary string input, causing a NULL pointer dereference in jslGetRawString() (src/jslex.c) when the lexer passes a NULL iterator target to jsvLockAgain(). Only RELEASE/NO_ASSERT builds are affected-assertion-enabled debug builds abort safely-and the CVSS vector (AV:L/PR:N) indicates unauthenticated local attackers who can supply script input via REPL, serial/USB console, or script loading can terminate the interpreter. EPSS is 0.14% (3rd percentile), no public exploit code has been identified, and an upstream fix commit (0db0663) is available.

Memory corruption in the Botslab G980H dash camera firmware allows an authenticated attacker on the same local network segment to submit crafted command data that writes past the bounds of an allocated buffer, potentially corrupting authentication state or terminating the affected process so the device restarts. The result is a temporary denial of service - the device becomes briefly unavailable while it reboots - with no demonstrated path to code execution, privilege escalation, or data disclosure (CVSS 4.0 base 6.9; availability-only impact, adjacent vector, low privileges required, no user interaction). No public exploit code has been identified at time of analysis, and CISA has not listed this CVE in the KEV catalog; the issue is reported by ICS-CERT in advisory ICSA-26-267-01.

An out-of-bounds heap read in Espressif ESP-IDF's BlueDroid A2DP sink path (btc_a2dp_sink_handle_inc_media()) affects versions 5.5.5, 6.0.1, and 6.1 on builds where Classic Bluetooth (BR/EDR) and A2DP sink support are explicitly enabled. A paired BR/EDR audio source within Bluetooth radio range can send a malformed A2DP media packet whose layout omits the timestamp field, causing the sink to read a UINT32 past the valid buffer and leak limited adjacent heap contents (CVSS 4.3, AV:A/AC:L/PR:N/UI:N/C:L/I:N/A:N). There is no CISA KEV listing and no public exploit identified at time of analysis, and the reporter explicitly states that arbitrary memory disclosure and code execution are not established, despite third-party tags implying RCE.

Opening a crafted MOBI e-book in SumatraPDF versions before 3.6 can crash the application because the MOBI header decoder trusts an attacker-controlled header length and reads past a short heap buffer; the bug is limited to the MOBI parser and requires local file delivery plus the user actively opening the document. It is a memory-safety issue (CWE-125) fixed in 3.6, with no confirmed active exploitation, no public exploit identified at time of analysis, and low real-world priority per available signals despite a 6.8 CVSS 4.0 base score. In CVSS terms the vector is AV:L/PR:N/UI:P, so the attacker is unauthenticated but must get the victim to open a malicious file locally, and the assessed impact is only a client crash (no confidentiality, integrity, or scope impact).

Denial of service in libXi before 1.8.4 allows a malicious or compromised X server to crash an attached X client by returning crafted input-device class data that triggers an out-of-bounds read inside XListInputDevices(). This is a client-side, inverted-trust flaw (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H, base 6.5): exploitation requires the victim application to connect to an attacker-controlled display and call the device-enumeration path, and the assessed effect is limited to an availability impact - no confidentiality or integrity loss - despite the CWE-125 classification and the 'Information Disclosure' tag. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the flaw is not reachable when clients talk only to trusted local X servers.

A malicious X server can crash X clients that use libXi before 1.8.4 by returning a crafted reply to the XListInputDevices() call, triggering an out-of-bounds read (CWE-125). The flaw is purely availability-impacting (CVSS 3.1 base 6.5: AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H) and requires the victim to connect to the attacker-controlled X server - for example via X11 forwarding to an untrusted host - and invoke XListInputDevices(). No public exploit code has been identified at time of analysis, and there is no indication of active exploitation (CISA KEV).

Out-of-bounds read in libXi before 1.8.4 allows a malicious X server to crash an attached X client by sending a crafted reply to an XI2 XIQueryDevice request. This is a denial-of-service issue affecting systems where the X client communicates with an untrusted or compromised X server, such as via SSH X11 forwarding to a hostile host or a man-in-the-middle on the X protocol stream. The CVSS vector indicates unauthenticated remote exploitation requiring user interaction (UI:R), with no impact to confidentiality or integrity and only availability impact; no public exploit code has been identified, and the vendor has released a patch fixing the flaw in version 1.8.4.

In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: reject duplicate wiphy cipher suite entries Duplicate entries in wiphy->cipher_suites do not describe any additional capability, but cfg80211 currently accepts them and leaves individual consumers to deal with them. One such consumer is the WEXT compatibility code, which appends a WEP key length for each WEP cipher entry it sees. Repeated WEP entries can therefore overflow the fixed iw_range::encoding_size array returned by SIOCGIWRANGE. Reject duplicate cipher suite entries in wiphy_register() instead. This keeps the cipher suite invariant in one place and makes malformed wiphy descriptions fail early with -EINVAL, rather than relying on a single cfg80211 user to handle duplicates correctly.

In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: avoid out-of-bounds access in monitor In NAN, we don't know on what band the frame will be sent. Therefore we set info->band to NUM_NL80211_BANDS. However, this leads to out-of-bound access in ieee80211_add_tx_radiotap_header when we try to access the sbands array. Fix it by not accessing the array if the band is NUM_NL80211_BANDS. This means that we will not report rate info for legacy rate in NAN. But nobody really cares about it.

In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix condition check in acpi_ps_parse_loop() Fix condition check for AML_ELSE_OP in acpi_ps_parse_loop() to prevent out-of-bounds access.

In the Linux kernel, the following vulnerability has been resolved: ACPICA: Add package limit checks in parser functions Add package limit checks in parser functions to prevent out-of-bounds access.

In the Linux kernel, the following vulnerability has been resolved: ACPICA: Enhance OEM ID and Table ID validation in acpi_ex_load_table_op() Enhance OEM ID and Table ID validation in acpi_ex_load_table_op() to prevent buffer overflows.

In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: flower: reject cross-chip redirect dsa_port_from_netdev() may return a valid port from a different switch chip. Programming another chip's port index into the local hardware causes redirection to the wrong port, or an out-of-bounds access if the index exceeds the local chip's port count. Apply a minimal fix that adds a check to catch this case and adjusts the extack message. When cls->common.skip_sw is not set, the operation could instead redirect to the upstream port and let the software or upstream switch(es) handle the forward, but that is not addressed here.

In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: bound pp_dpm_set_pp_table() memcpy The powerplay path allocates hardcode_pp_table once with kmemdup(..., soft_pp_table_size). memcpy(..., size) used the sysfs store count (up to PAGE_SIZE) with no upper bound, causing heap overflow. Reject writes where size exceeds soft_pp_table_size.

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix buffer overflow during vBIOS update Clamp the buffer postion to write by setting the bin attribute to the maximum buffer size so that VFS layer will block the out-of-bounds accessing.

In the Linux kernel, the following vulnerability has been resolved: cxl/region: Validate partition index before array access construct_region() reads cxled->part and uses it to index cxlds->part[] without checking for a negative value. If the partition was never resolved, part remains at its initial value of -1, causing an out-of-bounds array access. Add a guard to return -EBUSY when part is negative. The check was dropped during a merge.

In the Linux kernel, the following vulnerability has been resolved: bpf: NUL-terminate replaced sysctl value When writing to sysctls, proc_sys_call_handler() guarantees that the buffer passed to proc handlers is NUL-terminated. If bpf_sysctl_set_new_value() replaces the pending sysctl value, it can hand a replacement buffer directly to proc handlers. However, the helper currently copies only buf_len bytes into that buffer without appending a NUL terminator, leaving downstream parsers vulnerable to out-of-bounds access. Fix this by appending a '\0' after the replaced value to restore the expected sysctl semantics. Since the helper already rejects buf_len greater than PAGE_SIZE - 1, there is always room for the extra byte. Reproduced in a QEMU x86_64 guest booted with KASAN while exercising the sysctl replacement path with a cgroup/sysctl BPF program. The reproducer targets `/proc/sys/net/core/flow_limit_cpu_bitmap`, fills the original user write buffer with non-zero bytes, and overrides the sysctl value so the replacement buffer lacks a terminating NUL. Under that setup, the pre-fix kernel reported: BUG: KASAN: slab-out-of-bounds in strnchrnul+0x72/0x90 Read of size 1 at addr ffff88800de57000 by task repro_patch3/66 CPU: 0 UID: 0 PID: 66 Comm: repro_patch3 Not tainted 7.1.0-rc3-00269-g8370ca1f87cc #6 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x68/0xa0 print_report+0xcb/0x5e0 ? __virt_addr_valid+0x21d/0x3f0 ? strnchrnul+0x72/0x90 ? strnchrnul+0x72/0x90 kasan_report+0xca/0x100 ? strnchrnul+0x72/0x90 strnchrnul+0x72/0x90 bitmap_parse+0x37/0x2e0 flow_limit_cpu_sysctl+0xc6/0x840 ? __pfx_flow_limit_cpu_sysctl+0x10/0x10 ? __kvmalloc_node_noprof+0x5ba/0x870 proc_sys_call_handler+0x31d/0x480 ? __pfx_proc_sys_call_handler+0x10/0x10 ? selinux_file_permission+0x39f/0x500 ? lock_is_held_type+0x9e/0x120 vfs_write+0x98e/0x1000 ... </TASK> The buggy address is located 0 bytes to the right of allocated 4096-byte region [ffff88800de56000, ffff88800de57000) With this fix applied, rerunning the same sysctl-targeted path yields no corresponding KASAN reports.

In the Linux kernel, the following vulnerability has been resolved: exfat: fix handling of damaged volume in exfat_create_upcase_table() When the size of the upcase table is set to zero in the dentry for any reason(e.g. corrupted media or misbehaving device), an integer overflow causes the module to loop indefinitely. If the size of the upcase table is read zero, do not attempt to load the table. Instead, fallback to loading the default upcase table. If the size of the upcase table is zero or no upcase table is found, raise exfat_fs_error() to mark the volume read-only.

libXi before 1.8.4 contains an out-of-bounds read in the XI2 device-class parsing helpers size_classes() and copy_classes(), which a malicious or compromised X server can trigger to crash a connecting X client. The issue inverts the usual X11 trust model: the server attacks the client, so exposure is limited to users who connect an affected client to an untrusted display - a remote/forwarded X session or a hostile server - and requires user interaction to establish that connection (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H, 6.5). Impact is confined to client-side denial of service with no code execution, data disclosure, or integrity loss; there is no public exploit identified at time of analysis and no CISA KEV listing, and a vendor fix is available (libXi 1.8.4, upstream commit f499944a).

In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate rx/tx MLME callback frame lengths before access cfg80211_rx_mlme_mgmt() and cfg80211_tx_mlme_mgmt() call tracepoints before rejecting frames shorter than the frame-control field. After that, they only require len >= 2 before dispatching into subtype handlers that assume their fixed fields are present. The frames that trip this are not shorter than 2 bytes; they are short relative to their subtype. mwifiex is a concrete in-tree example on the length side: mwifiex_process_mgmt_packet() only requires a 4-address ieee80211_hdr plus the 2-byte firmware length prefix before handing the frame to cfg80211_rx_mlme_mgmt(). After stripping the length prefix and removing addr4, pkt_len can be exactly 24: a bare 3-address management header with no reason-code body. The existing WARN_ON(len < 2) does not fire on such a frame, and cfg80211_process_deauth() then reads u.deauth.reason_code as a two-byte access starting at offset 24, immediately past the 24-byte buffer. Add a frame-control length gate, then validate each subtype's minimum frame size in an if/else-if chain that mirrors the dispatch logic. Trace only after the frame is known to be well-formed. Side effects of this change: - The WARN_ON(len < 2) is dropped. It only guarded the frame_control read, never the subtype fixed fields, and it does not fire on the frames that actually trigger the out-of-bounds read (which are >= 2). The len >= 2 check is kept as the guard before dereferencing frame_control, but without the warning: these are exported callbacks and a malformed frame from a driver should be dropped silently rather than backtraced. - cfg80211_tx_mlme_mgmt() previously routed every non-deauth subtype through disassociation handling; it now silently ignores unrecognised subtypes.