Payment fraud is possible against any WooCommerce store running the ePayco Payment Gateway plugin before version 8.4.7, because the plugin accepts payment confirmation callbacks without verifying the gateway signature. Unauthenticated remote attackers can POST a crafted IPN/webhook payload to the store's payment callback endpoint, causing the plugin to transition order status to 'paid' and triggering fulfillment workflows - without any actual funds being transferred. No public exploit has been identified at time of analysis, and the CVSS score of 5.3 significantly understates real-world merchant financial exposure.
Cross-tenant insecure direct object reference in Openpanel before 2.3.0 allows authenticated users to read or reset other tenants' dashboard layouts by supplying arbitrary dashboardId values in tRPC API calls. The report.getLayouts and report.resetLayout tRPC procedures accept a caller-supplied dashboardId without verifying it belongs to the authenticated user's own projectId, enabling horizontal privilege escalation across tenant boundaries. No public exploit code has been identified, and no active exploitation is confirmed, but the flaw is trivially exploitable by any authenticated user on a shared Openpanel instance.
mTLS certificate reuse in Checkmk before 2.5.0p10 enables a relay or push agent to authenticate against agent receiver endpoints using a peer component's certificate, provided both share the same UUID. The agent receiver endpoints fail to verify that a presented client certificate was issued by their own root CA, breaking the intended role-based trust boundary between relay and push agent components. No public exploit has been identified, and exploitation requires an attacker to already control one of the affected agent components (PR:L), limiting realistic risk despite the network-reachable vector.
undici's cache interceptor incorrectly permits responses to unsafe HTTP methods - POST, PUT, DELETE, and PATCH - to be stored and later replayed, because the skip-list that gates caching is built by subtracting configured methods from the safe-method set rather than by positively excluding all non-safe methods, leaving unsafe methods unguarded. A remote origin that returns a heuristically cacheable status code or an explicit Cache-Control directive in response to a state-changing request causes undici to store that response; all subsequent client requests to the same path using the same method are then served from the stale cache entry without ever reaching the origin. Affected versions span undici 7.0.0 through 7.29.0 and 8.0.0 through 8.10.1; no public exploit has been identified at time of analysis.
Apache SkyWalking's PagerDuty alarm hook in versions 9.6.0 through 10.x transmits the PagerDuty integration routing key inside an unencrypted HTTP POST body before any redirect response from PagerDuty's HTTPS-only endpoint is received. Because the initial TCP socket write occurs in plaintext prior to the 301/302 redirect, a passive eavesdropper or MITM attacker positioned between the SkyWalking host and PagerDuty's API can capture the routing key verbatim from network traffic. No public exploit code has been identified and no active exploitation is confirmed; the practical impact is unauthorized PagerDuty event submission using the stolen credential, enabling false incident creation or alert fatigue rather than system compromise.
Server-side request forgery in Trigger.dev before 4.5.2 allows authenticated organization members to register webhook alert channel URLs targeting internal network services, loopback addresses, or cloud provider metadata endpoints such as the AWS IMDSv1 service. When an alert is delivered, the Trigger.dev server issues an outbound POST request to the attacker-controlled URL without any URL validation or SSRF filtering, exposing internal infrastructure to probing and potentially yielding cloud IAM credentials. The vendor released v4.5.2 as a security hardening release that introduces URL sanitization via a `sanitizeHttpUrl` utility; no public exploit code or CISA KEV listing has been identified at time of analysis.
Missing authorization checks in Crocoblock's JetPopup WordPress plugin (versions through 2.0.20.2) allow unauthenticated remote attackers to access functionality or data that should be restricted to authorized users. The flaw, classified as CWE-862 (Missing Authorization), enables exploitation of incorrectly configured access control levels, resulting in low-impact information disclosure with no integrity or availability consequence. No public exploit has been identified at time of analysis, and EPSS and KEV data were not provided.
Unverified access-point ownership in the AWS EFS CSI Driver before v3.4.1 enables an authenticated Kubernetes user holding PersistentVolume creation privileges to trigger recursive deletion of directory trees on EFS filesystems they are not authorized to access. The volume deletion component accepts a crafted volumeHandle that cross-pairs an access point from one EFS filesystem with a different target filesystem, and the driver never validates that the access point belongs to the stated filesystem before executing the deletion. No public exploit has been identified at time of analysis, but the technique is mechanically straightforward for any attacker who already holds the required cluster-scoped RBAC rights.
Stored cross-site scripting in Grav Admin plugin (getgrav/grav-plugin-admin2) versions <= 2.0.19 allows a low-privileged attacker to inject HTML/JavaScript payloads via a crafted username that bypasses server-side validation, executing in an administrator's browser session when specific UI surfaces render the stored username. The root cause is the `tHtml()` internationalisation function in `src/lib/stores/i18n.svelte.ts`, which inserts unescaped user-supplied parameters into locale template strings before markdown parsing - a classic stored XSS pattern. Fixed in version 2.0.21; no public exploit code or CISA KEV listing is known at time of analysis.
Stored XSS in Grav Admin before 2.0.20 allows arbitrary JavaScript to execute within authenticated admin browser sessions by embedding malicious javascript: URI schemes inside plugin or theme changelogs. The root cause is that MarkdownEditor and MarkdownModal Svelte components pass marked.parse() output directly into the DOM via Svelte's {@html} directive without sanitization, meaning any attacker who can publish or distribute a crafted Grav package can trigger JavaScript execution when an admin views that package's changelog. No public exploit code or CISA KEV listing exists at time of analysis, and the CVSS 4.0 score of 5.1 (Medium) reflects the constrained impact on subsequent systems only.
Order confirmation in Roskus Prospero Flow CRM before 5.15.11 can be triggered by an unauthenticated attacker on behalf of any authenticated user through a classic CSRF exploit. The root cause is a state-changing action exposed via HTTP GET at /order/confirm/{order_number}, which Laravel's VerifyCsrfToken middleware does not protect - middleware enforcement is limited to POST, PUT, PATCH, and DELETE. Because session cookies are configured with SameSite=Lax, a single crafted link navigated by the victim automatically includes their session cookie, silently transitioning the target order from pending to confirmed. Sequential integer order numbers further allow an attacker to enumerate and mass-confirm all outstanding orders in a single automated sweep. No public exploit or KEV listing is identified at time of analysis; vendor patch is available in 5.15.11.
Stored cross-site scripting in Grav Shortcode Core before 6.2.5 allows authenticated users with page-edit permissions to inject arbitrary HTML and JavaScript via the [lorem] tag parameter and [details] summary parameter, both of which are written to rendered pages without output escaping. Any visitor who loads an affected page - including site administrators - will have the injected script execute in their browser, enabling session hijacking, credential theft, or further privilege escalation against admin accounts. Vendor-released patch version 6.2.5 resolves both injection points; no public exploit or CISA KEV listing has been identified at time of analysis.
Stored cross-site scripting in Grav CMS versions 2.0.0 through 2.0.17 allows authenticated page editors to plant persistent XSS payloads via the modular page subsystem, which bypasses the CMS's save-time XSS sanitization entirely. By embedding malicious Twig template code into a modular page, an attacker with page-edit privileges can cause arbitrary JavaScript to execute in the browsers of any visitor to the parent page - including site administrators. If an administrator is targeted, the attacker can escalate to full site compromise through session hijacking or forced admin-side actions. No public exploit code has been identified at time of analysis, and the CVE is not listed in CISA KEV.
Stored cross-site scripting in phpMyFAQ before 4.1.8 allows authenticated FAQ editors to plant persistent JavaScript payloads that execute in every visitor's browser. The root cause is FaqHelper::convertOldInternalLinks() calling html_entity_decode() on content that was previously sanitized via entity encoding - effectively undoing the protection and re-introducing executable HTML. The impact extends beyond the attacker's own session to all users who subsequently view the poisoned FAQ pages, confirmed by the scope-change metrics in the CVSS 4.0 vector. No public exploit or KEV listing exists at time of analysis.
Blind SQL injection in Emlog CMS Pro's `User_Model::getUserDataByLogin()` function allows a remote attacker who controls the application's AUTH_KEY to enumerate database contents via the authentication cookie validation path. The `$account` value read from the HMAC-signed cookie is interpolated directly into SQL with no sanitization; the HMAC guard, which requires AUTH_KEY to forge, is the sole access barrier before the vulnerable query executes. All Emlog Pro releases before 2.6.16 are affected; the vendor released a confirmed patch at the pro-2.6.16 tag. No public exploit code or active exploitation has been identified at time of analysis.
IBM i versions 7.3 through 7.6 expose encryption key material to high-privileged local users due to hardcoded cryptographic constants used in the key-obfuscation layer. An attacker with elevated local privileges can leverage knowledge of these constants to reverse the obfuscation and recover plaintext encryption keys, gaining access to data that was assumed to be cryptographically protected. No public exploit has been identified at time of analysis, and IBM has released a patch via its support portal.
Reflected XSS in DreamMaker (Interinfo) allows authenticated remote attackers to inject and execute arbitrary JavaScript in a victim's browser by luring them to a specially crafted URL. The vulnerability affects all tracked versions per the wildcard CPE string and was reported by TWCERT; the CVSS 4.0 vector confirms a network-reachable, low-complexity attack that nonetheless requires both attacker authentication and victim interaction. No public exploit code or active exploitation (CISA KEV) has been identified at time of analysis.
Local information disclosure in IBM Db2 Mirror for i 7.4, 7.5, and 7.6 stems from a predictable Unix domain socket path placed in a world-writable directory, enabling a TOCTOU race condition (CWE-367). A local, low-privileged attacker can pre-create or replace the socket at the predictable path before the Db2 Mirror service claims it, intercepting communications that flow through that socket and obtaining sensitive information. No active exploitation has been confirmed, and no public exploit code has been identified at time of analysis.
Parameter injection in IBM i 7.3 through 7.6 allows a local authenticated attacker to inject malicious parameters into Control Language (CL) commands by exploiting improper neutralization of special elements (CWE-78). The flaw requires local access with low-level privileges and produces limited confidentiality and integrity impacts without availability consequence, consistent with the CVSS 4.4 Medium rating. IBM has released a patch via their support portal, and no public exploit code or active exploitation has been identified at time of analysis.
Broken access control in the web management interface (wwwugw.cgi) of MBS-Solutions X-Serie Gateway firmware V6_00_05 allows a remote attacker holding only the low-privileged Standard role to change the password of arbitrary accounts, including administrative ones. Successful exploitation yields account takeover and, by resetting an administrator's credentials, effective full control of the gateway. No public exploit identified at time of analysis and EPSS probability is low (0.24%, 15th percentile); the flaw is not listed in CISA KEV, so real-world exploitation is not confirmed.
Incorrect authorization in IBM i 7.4, 7.5, and 7.6 permits remote authenticated users with low privileges to modify certain system messages beyond their intended permission scope. The flaw is rooted in CWE-863 (Incorrect Authorization), where the platform performs an authorization check but does so inadequately, allowing privilege overstep without authentication bypass. No public exploit or active exploitation has been identified at time of analysis; IBM has released a patch via its support portal.
Missing authorization in Menulux Portal allows authenticated low-privileged users to access functionality not constrained by access control lists, resulting in unauthorized information disclosure. Affecting all versions before the timestamp-build 20260903211448, the flaw is rooted in CWE-862 (Missing Authorization) and was reported by TR-CERT, Turkey's national cybersecurity authority. No public exploit or KEV listing exists; the CVSS score of 4.3 (Medium) reflects limited confidentiality impact with no integrity or availability consequences.
Unbounded synchronous DNS amplification in Robots::Validate for Perl (versions 0.3.2 through 0.3.10) allows a network attacker who controls the reverse DNS zone for their IP address to force arbitrarily many forward DNS lookups per validation call, exhausting server threads and causing application-level denial of service. The _check_dns FCRDNS loop issues one forward query per PTR record returned for the connecting IP, with no cap; Net::DNS's default TCP fallback for truncated UDP answers removes the 512-byte payload as a natural limit. No public exploit has been identified and EPSS is 0.17% (7th percentile), but the attack primitive requires only a cloud VM with PTR editing rights and knowledge of the target's bot-rule configuration.
Missing authorization in Gastromenum Ticket and QR Menu System (all versions before 2026.08.31) allows authenticated low-privileged users to access functionality and data that ACLs should restrict, leaking confidential information. The flaw was disclosed by Turkish USOM (iletisim@usom.gov.tr) and tracked under TR-26-1012. No public exploit code or active exploitation has been identified; the vendor released a fix in the 2026.08.31 build.
Stored cross-site scripting in Stormshield Network Security's web administration panel allows an authenticated administrator who injects malicious script into group comments within the webservices interface to execute arbitrary JavaScript in the browser session of any other administrator who subsequently views that group entry. The CVSS 4.3 score reflects the constrained preconditions: adjacent network access, high privileges, and required user interaction by a second victim. No public exploit code and no CISA KEV listing have been identified at time of analysis.
HTTP response splitting and downstream desynchronization in undici's retry interceptor allows an attacker-controlled upstream server to cause downstream HTTP/1.1 clients to misinterpret response boundaries. Affected releases are undici before 6.28.1, 7.0.0 through 7.29.0, and 8.0.0 through 8.10.1. When a proxying application relays the malformed response without normalizing framing, excess bytes appended by the retry interceptor can be parsed by a downstream HTTP/1.1 peer as the start of a subsequent response, enabling response injection or session desynchronization attacks.
Improper access control in an SQL stored procedure within IBM Db2 Mirror for i 7.4, 7.5, and 7.6 permits an authenticated low-privileged attacker to permanently delete historical flight-recorder archives, destroying diagnostic audit data critical for replication troubleshooting and post-incident review. The root cause is CWE-285 (Improper Authorization) - the procedure executes a destructive operation without verifying that the invoking principal holds the necessary authority. No public exploit has been identified at time of analysis, and IBM has released a patch via support advisory node/7285904.
Race condition in freegpt-webui's Jailbreak Mode allows remote attackers to trigger low-level availability disruption by exploiting improper synchronization in the `getJailbreak` function of `server/config.py`. The affected project is end-of-life and unmaintained, with no versioned releases due to its rolling-release model. Public exploit code exists via a referenced GitHub gist, though exploitation demands high attack complexity and produces only minor service disruption - no confidentiality or integrity impact is possible.
Out-of-bounds GPU memory access in Imagination Technologies Graphics DDK allows kernel-level code executing inside a Guest VM to read from, and potentially write to, GPU memory regions outside its allocated virtualized address space via a TOCTOU race condition in GPU firmware validation. Affected versions span multiple DDK release trains including 1.18 RTM2, 23.2 RTM2, 24.2 RTM2, 25.1-25.3 RTM, and 26.1 RTM1 as enumerated in EUVD-2026-70858. No public exploit code has been identified at time of analysis, and the 0.11% EPSS score places this in the first percentile for exploitation probability, indicating no observed active exploitation.
In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: bound the connect_sn TLV walk to the skb Commit 27256cdb290e ("nfc: llcp: bound SNL TLV parsing to the skb and add length checks") fixed the unbounded TLV walk in nfc_llcp_recv_snl(), and commit d8bd2dedbde5 ("nfc: llcp: fix OOB read and u8 offset wrap in TLV parsers") subsequently bounded nfc_llcp_parse_gb_tlv() and nfc_llcp_parse_connection_tlv(). One sibling parser sharing the same pattern remains unbounded: nfc_llcp_connect_sn(). nfc_llcp_connect_sn() walks a TLV list, reading a two-byte header (type, length) followed by length bytes of value, without checking that the two header bytes or the declared length stay within the buffer. It returns a pointer to a service name of up to 255 bytes that may point past the end of the skb; it is subsequently consumed by memcmp() in nfc_llcp_sock_from_sn(). In addition tlv_array_len was computed as "skb->len - LLCP_HEADER_SIZE" in size_t, so a CONNECT/CC frame shorter than the LLCP header underflows to a huge length and the walk runs far past the buffer. nfc_llcp_connect_sn() is reachable from nfc_llcp_recv_connect() and nfc_llcp_recv_cc(), i.e. from received CONNECT and CC PDUs. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP, and the nfc_llcp_rx_skb() dispatcher applies no minimum-length guard. Walk the TLV list by pointer, bounded by skb_tail_pointer(skb), and validate each declared length before use, matching the approach already used for nfc_llcp_recv_snl(). Starting the walk at &skb->data[LLCP_HEADER_SIZE] against the tail pointer also removes the size_t underflow for short frames. Found by 0sec automated security-research tooling (https://0sec.ai).
In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: fix OOB read and u8 offset wrap in TLV parsers nfc_llcp_parse_gb_tlv() and nfc_llcp_parse_connection_tlv() contain three related bugs in their TLV parsing loops: 1. 'offset' is declared u8 but tlv_array_len is u16. When TLV data advances offset past 255 it silently wraps to zero, causing infinite loops or double-processing of buffer data. 2. Before reading tlv[0] (type) and tlv[1] (length) there is no check that offset+2 <= tlv_array_len. A truncated TLV causes an OOB read of one byte past the buffer end. 3. After reading the length field, the value bytes are accessed without checking offset+2+length <= tlv_array_len. A crafted length=0xFF on a short buffer causes up to 255 bytes of OOB read past the buffer end. Both functions are reachable without authentication via nfc_llcp_set_remote_gb() which feeds remote LLCP general bytes directly into nfc_llcp_parse_gb_tlv() with no additional validation. Fix all three issues by widening offset from u8 to u16 and adding bounds checks for both the TLV header and value field before each access.
In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: reject PDUs shorter than the LLCP header Every LLCP PDU begins with a two-byte header (DSAP/SSAP + PTYPE), but the receive path never checked that a frame is at least LLCP_HEADER_SIZE bytes before parsing it. nfc_llcp_rx_skb() reads the header via nfc_llcp_ptype()/nfc_llcp_dsap()/ nfc_llcp_ssap(), which dereference pdu->data[0] and pdu->data[1], and a CONNECT or CC PDU then computes tlv_array_len = skb->len - LLCP_HEADER_SIZE; as a size_t and hands it to the TLV walk. When the frame is shorter than the header the subtraction wraps to a huge value and the walk runs far past the buffer, an out-of-bounds read. A nearby NFC device can reach this without authentication; LLCP link activation happens automatically after NFC-DEP. Guard the common receive choke point __nfc_llcp_recv(), shared by both the target (nfc_llcp_data_received()) and initiator (nfc_llcp_recv()) paths, so a short skb is dropped before the rx_work worker parses it. Use pskb_may_pull() rather than a skb->len test so the two header bytes are guaranteed to sit in the skb linear area even for a non-linear skb, matching how the sibling NCI and HCI receive paths validate their headers. Reproduced with a KFENCE out-of-bounds read via /dev/virtual_nci on linux-next. Found by 0sec automated security-research tooling (https://0sec.ai).
In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: bound SGL data length before allocating command buffers nvmet_tcp_map_data() reads the host-controlled 32-bit sgl->length and, for the in-capsule offset descriptor (type 0x01), checks it against port->inline_data_size before use. Any other SGL descriptor type -- including the non-inline transport SGL data-block descriptor (type (NVME_TRANSPORT_SGL_DATA_DESC << 4) | NVME_SGL_FMT_TRANSPORT_A, the type a real host uses for out-of-capsule writes) skips that check entirely and falls straight through to: cmd->req.sg = sgl_alloc(len, GFP_KERNEL, &cmd->req.sg_cnt); with len taken directly from the wire, unbounded up to 4 GiB. nvmet_req_init() only parses the command and never inspects sgl->length, and nvmet_check_transfer_len() -- the only other place transfer_len is validated -- runs later, from req->execute(), after the allocation has already happened. For a write command the target responds with an R2T and parks the command waiting for the host to send the data; if the host (or an unauthenticated peer that simply never follows up) never does, the sgl_alloc() buffer stays resident for the life of the command. NVMe/TCP has no mandatory authentication in the default configuration, so any peer able to reach the target portal and complete a Fabrics connect can drive this with a single crafted command, repeatable across queues and connections for amplification. This is unbounded kernel memory allocation triggered by a remote, effectively unauthenticated peer. Validate len against the same NVMET_TCP_MAXH2CDATA ceiling this file already uses to bound per-PDU H2C data, for every SGL descriptor type, before doing any allocation. This closes the gap for the non-inline descriptor while leaving the existing, tighter inline_data_size check in place for the in-capsule case. Runtime-verified on a v6.19 KASAN stand: with this bound in place, a crafted write command carrying an oversized non-inline SGL length is rejected before sgl_alloc() runs, where the same request previously drove an unbounded ~256 MiB kernel allocation (up to 4 GiB) that stayed resident pending an R2T the host never satisfies.
In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: zero the AUTH_RECEIVE response buffer nvmet_execute_auth_receive() allocates the response buffer with kmalloc() sized by the host-supplied AUTH_RECEIVE allocation length, but the DH-HMAC-CHAP builders write only a fixed-size message into it. The full allocation length is then copied to the wire by nvmet_copy_to_sgl(), so a remote initiator receives the bytes past the built message -- up to nearly a page of uninitialized slab -- during the pre-authentication handshake. Allocate the buffer with kzalloc() so the unwritten tail is zeroed before it is sent; conforming responses are unaffected.
In the Linux kernel, the following vulnerability has been resolved: ipv6: seg6: clear IPv4 control block on IPIP decapsulation End.DX4 and End.DT4 decapsulate an IPv4 packet through decap_and_validate() and send it directly to IPv4 routing. The inner packet therefore bypasses ip_rcv_core(), which normally clears IPCB before IPv4 interprets skb->cb. The skb instead retains IP6CB data from the outer packet. IP6CB and IPCB use the same skb->cb storage, so IP6CB(skb)->lastopt overlaps IPCB(skb)->opt.optlen and srr, while IP6CB(skb)->nhoff overlaps rr and ts. The sender can make the stale optlen byte nonzero with a valid outer extension-header chain. The reproducers put an eight-byte Destination Options header immediately after the 40-byte IPv6 header and before the Segment Routing Header. ipv6_destopt_rcv() records the sender-controlled Destination Options offset in both lastopt and nhoff, setting them to 40. On the reproduced little-endian x86-64 kernel, IPv4 therefore sees optlen = 40 and rr = 40. Both tcp_v4_save_options() and __ip_options_echo() skip option copying when optlen is zero. Here optlen is 40, so the TCP SYN path allocates room for 40 bytes of option data and calls __ip_options_echo(). The stale rr value makes that function read inner packet byte 41 as the Record Route option length. The reproducers set that sender-controlled byte to 255, so __ip_options_echo() copies 255 bytes into the 40-byte option-data area. Separate End.DX4 and End.DT4 reproducers on the unpatched v7.2-rc5 kernel both produced: BUG: KASAN: slab-out-of-bounds in __ip_options_echo() Write of size 255 The relevant End.DX4 call path is: __ip_options_echo tcp_v4_route_req tcp_conn_request tcp_v4_conn_request tcp_rcv_state_process tcp_v4_do_rcv tcp_v4_rcv ip_protocol_deliver_rcu ip_local_deliver_finish ip_local_deliver input_action_end_dx4_finish input_action_end_dx4 The relevant End.DT4 call path is: __ip_options_echo tcp_v4_route_req tcp_conn_request tcp_v4_conn_request tcp_rcv_state_process tcp_v4_do_rcv tcp_v4_rcv ip_protocol_deliver_rcu ip_local_deliver_finish ip_local_deliver input_action_end_dt4 tcp_v4_save_options() is inlined into the tcp_v4_route_req() path, so it does not appear as a separate frame. When decap_and_validate() handles IPPROTO_IPIP, save the ingress interface from IP6CB, clear IPCB, and restore the saved value. Doing this in the common decapsulation path covers End.DX4, End.DT4, and End.DT46's IPv4 arm. Use IP6CB(skb)->iif rather than skb->skb_iif. These actions run after l3mdev processing, which can replace skb_iif with the L3 master; IP6CB iif still records the receiving interface set at IPv6 ingress.
In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject invalid block index in GC ioctl Syzbot reported list corruption caused by a double list_add_tail() call on bh->b_assoc_buffers within nilfs_lookup_dirty_data_buffers(). Analysis revealed that the root cause was the insertion of a page/folio with a page index of ULONG_MAX into the page cache via the GC ioctl. filemap_get_folios_tag(), called by nilfs_lookup_dirty_data_buffers(), repeatedly detects a dirty folio with a page index of ULONG_MAX due to index wrap-around, leading to duplicate processing of dirty buffers. As a preparatory step, the GC ioctl loads the page/folio of the block to be moved during GC and inserts it into the page cache based on information in the nilfs_vdesc structure passed as an argument. Normally, this does not cause issues because the user-space GC library configures the nilfs_vdesc structure properly. However, since there is no range check on the parameters determining the page index, a request with artificially crafted parameters -- such as those generated by Syzbot -- can result in a page/folio being inserted with a page index of ULONG_MAX, triggering the above problem. This resolves the issue by checking the ranges of 'vd_offset' and 'vd_vblocknr' in the nilfs_vdesc structure that determine the page index, thereby preventing the invalid page/folio insertions.
In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: fix UAF during close ZDI reported and analyzed a race condition during close for espintcp sockets: espintcp_close() frees emsg->skb via kfree_skb() without holding any socket lock. Concurrently, the xfrm_trans_reinject work queue invokes esp_output_tcp_finish() -> espintcp_push_skb() -> espintcp_push_msgs() -> skb_send_sock_locked(), which reads the same skb as a data source. Fix this by adding a synchronize_rcu() call after resetting sk_prot, since esp_output_tcp_finish() runs under RCU and won't use a socket with sk_prot == &tcp_prot. Simply taking the socket lock in espintcp_close() could lead to leaks, if esp_output_tcp_finish() re-adds an skb in the slot we just freed. After this, the existing barrier() is no longer needed.
In the Linux kernel, the following vulnerability has been resolved: xfrm: drop ESP-in-TCP packets with no ingress device ESP-in-TCP receives records through the TCP strparser. handle_esp() restores skb->dev from the saved skb_iif before passing the packet into the XFRM input path. Queued TCP data can be processed after the original ingress device has been removed, for example during veth or net namespace teardown. In that case dev_get_by_index_rcu() returns NULL. The XFRM IPv4 and IPv6 input paths both expect skb->dev to be valid while building the route lookup, so queued ESP-in-TCP data can dereference a NULL device. Drop the packet if the saved ingress device can no longer be resolved. Such a packet can no longer be routed through the normal XFRM receive path, and this preserves the existing behaviour for packets whose ingress device still exists.
In the Linux kernel, the following vulnerability has been resolved: xfrm: ah6: validate routing header segments_left AH6 rearranges routing-header addresses before computing or verifying the ICV. ipv6_rearrange_rthdr() assumes that segments_left is not larger than the number of addresses described by the routing header's hdrlen field. That assumption does not hold for raw IPv6 HDRINCL packets. A packet with hdrlen equal to 2 describes one address, but can carry an arbitrary segments_left value. With segments_left equal to 255, the function moves its address pointer 4,064 bytes backwards and passes a 4,064-byte length to memmove(), resulting in an out-of-bounds access. Validate the invariant locally before modifying the routing header or performing any address-pointer arithmetic, and propagate malformed-header errors to the existing AH6 input and output error paths.
In the Linux kernel, the following vulnerability has been resolved: xfrm: fix xfrm_state_construct() auth-trunc leak attach_auth_trunc() can allocate x->aalg while leaving x->props.aalgo at zero when the selected auth algorithm has no sadb_alg_id. One real case is cmac(aes). xfrm_state_construct() then treats !x->props.aalgo as "no auth algorithm attached yet" and calls attach_auth(). That overwrites x->aalg and loses the first allocation. Any later failure or teardown only frees the replacement pointer. Check whether x->aalg is already attached instead of inferring that state from x->props.aalgo.
In the Linux kernel, the following vulnerability has been resolved: usb: core: Add lock to usb_wakeup_notification() Add a spin lock to usb_wakeup notification to prevent a race condition with dereferencing freed memory. This could be hit by the xHCI driver as it calls this function from an IRQ and could race with the hub_disconnect() function, which properly grabs this lock to protect the state of the device.
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write in snd_usbmidi_novation_output() snd_usbmidi_novation_output() lays out a two-byte header at transfer_buffer[0..1] and passes &transfer_buffer[2] together with a length of ep->max_transfer - 2 to snd_rawmidi_transmit(): count = snd_rawmidi_transmit(ep->ports[0].substream, &transfer_buffer[2], ep->max_transfer - 2); ep->max_transfer comes from the output endpoint's wMaxPacketSize via usb_maxpacket(). A malformed or malicious device can advertise a bulk OUT endpoint with a wMaxPacketSize of 1 - the USB core only clamps this value downwards - so ep->max_transfer becomes 1 and the count argument becomes -1. snd_rawmidi_transmit() passes the negative count on to __snd_rawmidi_transmit_peek(), where "if (count1 > count) count1 = count" leaves count1 negative; get_aligned_size() keeps it negative for a byte-stream substream, so the following memcpy(buffer, ..., count1) runs with a (size_t)-1 length and writes far past the transfer buffer, which was allocated with usb_alloc_coherent(ep->max_transfer). This is the same class of bug that was fixed for snd_usbmidi_akai_output() in commit 0970274613fb ("ALSA: usb-audio: fix OOB write in snd_usbmidi_akai_output()"); the novation output routine was left unguarded. Bail out when the endpoint cannot hold the two-byte header plus at least one payload byte.
In the Linux kernel, the following vulnerability has been resolved: USB: serial: option: fix slab OOB read in interrupt URB callback The interrupt URB buffer is allocated in setup_port_interrupt_in() based on the endpoint's wMaxPacketSize: buffer_size = usb_endpoint_maxp(epd); port->interrupt_in_buffer = kmalloc(buffer_size, GFP_KERNEL); When a USB device declares wMaxPacketSize = 8 on its interrupt IN endpoint, the buffer is allocated from kmalloc-8 cache (exactly 8 bytes). If the device sends a short packet (actual_length < wMaxPacketSize), the URB completes with status == 0 and the callback proceeds to read: data[sizeof(struct usb_ctrlrequest)] which evaluates to data[8], accessing 1 byte beyond the allocated 8-byte buffer. This results in a slab out-of-bounds read. Fix this by adding the missing bounds check: first verify that the actual length is large enough to contain the struct usb_ctrlrequest header before accessing req_pkt->bRequestType and req_pkt->bRequest, and then verify that there is an additional byte for the modem signal state before reading data[sizeof(struct usb_ctrlrequest)] inside the conditional. Use sizeof(*req_pkt) instead of sizeof(struct usb_ctrlrequest) for consistency. [ johan: use dev_err(); split signals declaration and initialisation ]
In the Linux kernel, the following vulnerability has been resolved: USB: c67x00: fix use-after-free in c67x00_add_iso_urb() When TD creation fails for the last packet of an isochronous URB, c67x00_add_iso_urb() gives the URB back before updating the endpoint scheduling state. c67x00_giveback_urb() frees the URB private data, and the completion callback may release the final URB reference. The following accesses to urbp->ep_data, urb->interval, and urbp->cnt can therefore use freed memory. Update next_frame and cnt before giving back the failed final packet, making the giveback the last operation that uses the URB and its private data.
In the Linux kernel, the following vulnerability has been resolved: usb: usbfs: fix use-after-free of usb_device in usbdev_release() usbdev_release() drops its reference to the struct usb_device before draining the list of completed async URBs, but that drain path reads back through the same object: free_async() calls dec_usb_memory_use_count() for any URB whose buffer came from the usbfs mmap() region, and its first statement is bus_to_hcd(ps->dev->bus). After a disconnect the usbfs reference can be the last one, in which case usb_put_dev() frees the device and the subsequent loop reads offset 80 of freed memory and uses the result as a struct usb_hcd *, which hcd_buffer_free_pages() then dereferences. This is reachable by an unprivileged process that has read/write access to a /dev/bus/usb node: mmap() the fd, submit one URB with a buffer inside the mapping, wait for the device to be unplugged, then munmap() and close(). It reproduces on every attempt rather than being a race, because a live MAP_SHARED vma holds a reference on the struct file, so usbdev_release() cannot run until the last vma is gone and the freeing branch of dec_usb_memory_use_count() is always taken. BUG: KASAN: slab-use-after-free in dec_usb_memory_use_count+0x3ae/0x410 Read of size 8 at addr ffff8880122ee050 by task poc/769 CPU: 1 UID: 1000 PID: 769 Comm: poc Tainted: G B 6.12.94 #3 Call Trace: dec_usb_memory_use_count+0x3ae/0x410 free_async+0x2aa/0x4f0 usbdev_release+0x375/0x460 __fput+0x3ea/0xb50 __x64_sys_close+0x86/0x100 Allocated by task 11: usb_alloc_dev+0x55/0xd90 hub_event+0x2524/0x43d0 Freed by task 769: kfree+0x121/0x360 device_release+0xd2/0x280 usb_put_dev+0x23/0x30 usbdev_release+0x2d8/0x460 Release the device reference after the drain loop instead. Nothing between the two points requires it to have been dropped.
In the Linux kernel, the following vulnerability has been resolved: nfc: st21nfca: validate ATR_REQ length against the received frame st21nfca_tm_recv_atr_req() checks that the received ATR_REQ frame is at least ST21NFCA_ATR_REQ_MIN_SIZE and that the self-declared atr_req->length is at least sizeof(struct st21nfca_atr_req), but never checks that atr_req->length does not exceed the actual received length (skb->len). st21nfca_tm_send_atr_res() then trusts the declared length: gb_len = atr_req->length - sizeof(struct st21nfca_atr_req); ... memcpy(atr_res->gbi, atr_req->gbi, gb_len); so an RF peer that sends a short frame but sets atr_req->length larger than the frame makes gb_len exceed the general bytes actually present, and the memcpy reads out of bounds past the received skb. Those bytes are placed in the ATR_RES and sent back to the peer (kernel-memory disclosure to a proximity attacker); a larger declared length is an out-of-bounds read (DoS). Reject frames whose declared length exceeds the received length. The adjacent nfc_tm_activated() path in the same function already derives its general-bytes length from skb->len rather than the declared field. Found by 0sec (https://0sec.ai) using automated source analysis; the missing bound is evident from source. Compile-tested.
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept rfcomm_sock_recvmsg() completes a deferred setup by calling rfcomm_dlc_accept() without holding any RFCOMM lock: if (test_and_clear_bit(RFCOMM_DEFER_SETUP, &d->flags)) { rfcomm_dlc_accept(d); return 0; } and rfcomm_dlc_accept() dereferences the session on its first line: struct sock *sk = d->session->sock->sk; Every other path that touches d->session runs under rfcomm_mutex: rfcomm_dlc_open(), rfcomm_dlc_close(), rfcomm_dlc_exists(), rfcomm_dlc_send_rpn(), and the RFCOMM thread through rfcomm_process_sessions(). rfcomm_connect_ind() is even documented as "called under rfcomm_lock()". This call site is the only one that skips it. The RFCOMM_DEFER_SETUP bit looks like it serialises the accept against teardown, since __rfcomm_dlc_close() returns early when it wins the test_and_clear. But rfcomm_recv_disc() forces the state first: d->state = BT_CLOSED; __rfcomm_dlc_close(d, err); and the early return only covers BT_CONNECT, BT_CONFIG, BT_OPEN and BT_CONNECT2. With the state already BT_CLOSED that switch does not match, the bit is never consulted, and __rfcomm_dlc_close() falls through to rfcomm_dlc_unlink(), which sets d->session = NULL. So a remote DISC on a deferred dlc clears the session while leaving RFCOMM_DEFER_SETUP set. The next recvmsg() then passes the test_and_clear and dereferences a NULL session. No timing window is needed: once the DISC has been processed, the dereference is unconditional. Give rfcomm_dlc_accept() the same shape as rfcomm_dlc_open() and rfcomm_dlc_close(): an exported wrapper that takes rfcomm_mutex and re-checks the session, around a __rfcomm_dlc_accept() that the two in-core callers, which already hold the mutex, keep using. Reproduced on a KASAN + PROVE_LOCKING kernel with a BR/EDR peer emulated over /dev/vhci: the peer brings up an ACL link, opens L2CAP on the RFCOMM PSM, starts a session, opens a dlc on a channel bound with BT_DEFER_SETUP, and sends DISC after the socket is accepted. recv() on the accepted socket then hits: Oops: general protection fault KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:rfcomm_dlc_accept+0x54/0x350 Call Trace: rfcomm_sock_recvmsg+0x1cd/0x230 sock_recvmsg+0x166/0x1c0 __sys_recvfrom+0x20d/0x300 0x10 is the offset of sock in struct rfcomm_session. With this patch the same run completes with recv() returning 0 and no report, and lockdep stays quiet, confirming rfcomm_mutex is still taken before lock_sock on this path as it is on the thread side.
In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix missing metadata reservation for large xattrs [BUG] lsetxattr() panics the kernel when setting a large xattr value on a fragmented filesystem where the file already has an external xattr block. [CAUSE] ocfs2_calc_xattr_set_need() never reserves metadata blocks for a new xattr value's extent tree when the file already has an external xattr block. The not_found path leaves meta_add at zero, so meta_ac is NULL when ocfs2_xattr_extend_allocation() runs. A new value root has room for a single extent record. On a fragmented filesystem, the allocator cannot satisfy the xattr value in one contiguous run, so each non-contiguous run requires its own extent record. When the value root's extent list is full and meta_ac is NULL, ocfs2_add_clusters_in_btree() returns RESTART_META, and ocfs2_xattr_extend_allocation() hits BUG_ON(why == RESTART_META). [FIX] The case where no xattr block exists yet already calls ocfs2_extend_meta_needed(&def_xv.xv.xr_list) to reserve value tree metadata. Add the same reservation to the case where an xattr block already exists, making the two cases consistent. Replace the BUG_ON with a -ENOSPC return so that if RESTART_META is returned despite the reservation, the error propagates to userspace instead of panicking the kernel.
In the Linux kernel, the following vulnerability has been resolved: ext4: stop retrying saturated xattr cache entries ext4_xattr_block_set() retries when a cache entry selected for reuse has a saturated reference count after taking the buffer lock. The retry returns to the mbcache lookup without making that entry ineligible, so it can select the same unusable entry indefinitely. A task spinning there can hold the parent directory's i_rwsem and leave concurrent rmdir callers blocked. Normally a reusable entry has a reference count below EXT4_XATTR_REFCOUNT_MAX because the count and MBE_REUSABLE_B are updated under the same buffer lock. A corrupted filesystem can violate that invariant. The syzbot reproducer reports allocator and xattr corruption before triggering this retry loop. Check the untrusted on-disk count before incrementing it, avoiding overflow, and clear MBE_REUSABLE_B when it is already saturated. The next lookup then skips the entry that was just proven unusable. This mirrors the normal transition at EXT4_XATTR_REFCOUNT_MAX; the release path marks the entry reusable again on the exact 1024-to-1023 transition. Using the same QEMU harness and guest parameters, current unpatched Linux hung in 6 of 8 420-second trials with the do_rmdir signature; representative NMI backtraces caught the owner spinning in ext4_xattr_block_set(). The patched kernel completed 28 of 28 trials without a hung-task report; the final twelve trials exercised the reviewed overflow-safe form of the change. syzbot's patch testing also completed without reproducing the hang.
In the Linux kernel, the following vulnerability has been resolved: xfs: validate attr entry pointer before field access xfs_attr3_leaf_verify_entry() accesses lentry/rentry fields (namelen, valuelen) before checking if the entry pointer itself is within bounds. If nameidx is crafted to point near the end of the buffer, these field accesses can read out-of-bounds before the bounds check at name_end > buf_end is performed. Add explicit bounds checks for entry pointers before accessing their fields. Use offsetof() to check that the start of the flexible array member (nameval/name) is within bounds, which ensures all preceding fields are safe to access.