Unauthenticated comment deletion in Fabrik Extension for Joomla (versions 1.0.0 through 4.7.1) is possible because the DeleteComment endpoint performs no access control verification of any kind - a straightforward CWE-284 (Improper Access Control) failure. Any remote, unauthenticated party with network access to a Joomla installation running the affected extension can delete arbitrary comments by targeting their IDs. No active exploitation or public exploit code has been identified at time of analysis; the fix is available in version 4.7.2.
Unauthenticated comment tampering in the Fabrik extension for Joomla exposes all versions from 1.0.0 through 4.7.1 to arbitrary comment modification by any remote actor. The onUpdateComment endpoint performs no access control checks whatsoever - no session validation, no ownership verification - allowing any unauthenticated HTTP request to overwrite comment content in the database. No public exploit code has been identified at time of analysis, but the CVSS 4.0 vector (PR:N/AC:L/AT:N) confirms this is trivially exploitable with no prerequisites beyond network access to a Joomla site running the affected extension.
Unauthenticated email disclosure in Fabrik (Joomla extension, versions 1.0.0-4.7.1) exposes any commenter's email address to remote, unauthenticated requesters via the onGetEmail endpoint, which performed no access control checks. The flaw stems from a complete absence of authorization logic on a data-retrieval endpoint, allowing trivial mass enumeration of personal contact data. No public exploit code or CISA KEV listing has been identified at time of analysis, though zero-barrier network access makes opportunistic harvesting straightforward.
Unauthenticated row reordering in the Fabrik extension for Joomla (versions 1.0.0 through 4.7.1) allows any network-accessible attacker to arbitrarily manipulate record ordering in Fabrik lists without credentials. The order plugin processed reorder requests with no access control checks whatsoever, a CWE-284 failure reported by the Joomla security team. No public exploit code has been identified at time of analysis, and this vulnerability does not appear in CISA KEV.
Incomplete path blocklist in SiYuan's MCP file tool (versions before v3.8.0) allows authenticated administrators to read workspace files that the HTTP API is designed to protect, including plaintext publish-mode passwords from data/.siyuan/publishAccess.json. The flaw stems from a mismatch between the HTTP API's access restrictions and the MCP tool's narrower blocklist, classified as CWE-863 (Incorrect Authorization). No public exploit is identified at time of analysis; exploitation is bounded by the requirement for pre-existing administrator credentials.
Email enumeration in AVideo's RSS feed endpoint (feed/index.php) allows unauthenticated remote attackers to harvest channel owner email addresses across all versions through commit 9c39d8c8. By iterating through public channel names, attackers can systematically extract creator PII from the itunes:email and itunes:author elements of the platform's podcast-compatible RSS output. No public exploit has been identified at time of analysis, but the trivial exploitation path - a standard HTTP GET request requiring no credentials - substantially elevates downstream risk of phishing campaigns and credential-stuffing attacks targeting identified creators.
SSRF protection bypass in NLTK affects all versions before 3.10.0, where a fail-open logic error in validate_network_url() allows attackers to reach restricted network resources including cloud metadata endpoints such as 169.254.169.254. The flaw resides in _resolve_hostname(), which silently swallows OSError and ValueError from socket.getaddrinfo() and returns an empty list; the subsequent IP validation loop then iterates zero times, allowing urlopen() to execute the request with no filtering applied. No public exploit code or CISA KEV listing has been identified at time of analysis, but the real-world impact is meaningfully elevated for cloud-deployed applications where metadata API access can expose IAM credentials.
Heap buffer overflow in hashcat through version 7.1.2 allows an attacker who controls a hash file to crash the process and corrupt heap memory when an operator runs hashcat with the --username --show flags. The outfile_write() function in src/outfile.c sequentially appends username, separator, hash, and plaintext into a fixed ~16 MB heap buffer (HCBUFSIZ_LARGE) via memcpy without tracking accumulated length against buffer capacity, enabling an out-of-bounds write. No active exploitation has been confirmed (not in CISA KEV), and a vendor patch has been released via upstream commit.
Out-of-bounds heap write in hashcat's fgetl() function affects all versions through 7.1.2, triggered by supplying any input file - hash file, potfile, or wordlist - containing a line of exactly HCBUFSIZ_LARGE bytes, causing a one-byte null write past the caller's buffer. The resulting heap corruption can crash hashcat or, in a worst case, create memory exploitation primitives; confidentiality is unaffected (VC:N per the CVSS 4.0 vector) while availability impact is rated high. No public exploit or active exploitation has been identified at time of analysis, and a vendor-released patch commit is available.
Cross-site request forgery in WWBN AVideo through commit 9c39d8c8 allows an authenticated attacker to silently transfer video ownership to an attacker-controlled account by planting a malicious img tag in a video description. The vulnerable endpoint, objects/videoEditLight.php, accepts GET requests without any authenticity token validation, making it trivially exploitable via passive browser-side request forgery when an administrator views the crafted video page. No public exploit code or active exploitation (CISA KEV) has been identified at time of analysis; the CVSS 4.0 score of 6.9 reflects meaningful integrity impact constrained by the requirement for low-privilege account access and administrator interaction.
Heap-based buffer overflow in luci-lib-px5g's native ASN.1 encoding routine allows a locally authenticated attacker to write one byte beyond a heap-allocated buffer during certificate signing, with a high availability impact and limited confidentiality and integrity exposure. The flaw is triggered specifically when signing with a 2040-bit RSA key via the exported Lua interface create_selfsigned(), where a DER length encoding miscalculation causes an allocation of 259 bytes for a payload requiring 260. Remote exploitability is not confirmed - it depends entirely on whether the embedding application exposes this interface externally. No public exploit code has been identified at time of analysis, and this CVE is not listed in the CISA KEV catalog.
Symlink-based arbitrary file read in NLTK's IPIPANCorpusReader exposes files accessible to the running process on systems where untrusted local users can write to corpus root directories. Affected NLTK versions before 3.10.2 fail to follow symlinks through the nltk.pathsec validation layer when IPIPANCorpusReader methods - channels(), domains(), categories(), or fileids() - resolve filenames, allowing the symlink target to be read instead of the intended corpus file. No public exploit or CISA KEV listing has been identified at time of analysis; real-world risk is bounded by the local attack vector and the requirement for write access to the corpus directory.
Arbitrary file read in the Tutor LMS WordPress plugin (all versions before 4.0.6) allows authenticated instructors to retrieve any file on the server — including files outside the web root — by exploiting a missing path validation check in the plugin's media streaming functionality. Critically, readable targets include wp-config.php, which exposes database credentials and WordPress authentication keys and salts; possession of these constants enables an attacker to forge valid session cookies for any account, including site administrators. No public exploit has been identified at time of analysis, and the EPSS score of 0.18% (8th percentile) reflects low observed exploitation activity, but the cascading impact path from instructor account to full site compromise makes patching urgent for any site with open instructor registration.
Stored cross-site scripting in the Post Grid, Slider & Carousel Ultimate WordPress plugin (all versions before 1.8.1) allows any authenticated Contributor-level user to inject persistent JavaScript into a custom post type setting that executes in an administrator's browser session when the admin opens the poisoned item's edit screen. The attack effectively escalates a Contributor's limited privileges to full administrative control over the WordPress instance without any interaction from the attacker beyond the initial payload submission. No public exploit code has been identified and EPSS places exploitation probability at 0.16%, though the low technical barrier and the prevalence of multi-contributor WordPress sites make this a meaningful insider-threat and account-compromise vector.
Privilege escalation in Forminator Forms WordPress plugin (versions before 1.57.0.7) allows any user with form-builder permissions to create a registration form that grants the WordPress administrator role to every visitor who self-registers through it. The role-restriction enforcement applied to registration forms is inconsistently applied, meaning the control exists in the codebase but can be bypassed at the configuration layer by a sufficiently privileged form author. No public exploit code has been identified at time of analysis, and EPSS sits at 0.14% (4th percentile), indicating low observed exploitation activity; however, a successful exploitation chain yields full WordPress site compromise.
Command injection in TRENDnet TEW-823DRU firmware 1.1.02b01 allows a remote, authenticated attacker to inject arbitrary OS commands through the nvram_get function in the CLI Configuration Tool. Exploitation requires high-privilege credentials (PR:H per CVSS 4.0), limiting the attacker pool to those who have obtained administrative access. A public proof-of-concept is documented on GitHub; no CISA KEV listing has been recorded at time of analysis, and no vendor-released patch has been identified.
Stored Cross-Site Scripting in the Image Photo Gallery Final Tiles Grid WordPress plugin (versions through 3.6.12) allows authenticated contributors to inject persistent malicious scripts via the 'delay' shortcode attribute. The injected payload executes in the browser of any user who subsequently visits an affected page, enabling session hijacking, credential theft, or malicious redirects. No public exploit has been identified at time of analysis, and a code-level fix has been committed to the WordPress.org plugin repository (changeset 3490676).
Stored XSS in the MC4WP: Mailchimp for WordPress plugin allows authenticated WordPress users with Author-level access or above to inject persistent malicious scripts into form response message post meta fields (`text_subscribed`, `text_error`), affecting all versions through 4.12.0. Injected payloads execute in the browsers of any site visitor who loads a page rendering the compromised form response, enabling session hijacking, credential theft, or malicious redirects against other users including Administrators. No public exploit has been identified at time of analysis and the vulnerability is absent from CISA KEV, though the low privilege barrier of the Author role makes this a credible internal threat on multi-contributor WordPress installations.
Command injection in TRENDnet TEW-821DAP 2.2.01b05 allows remote low-privileged attackers to execute arbitrary OS commands via the `filename` argument in the `/cgi-bin/upload.cgi` CGI endpoint's SSI component. A public proof-of-concept exploit is available on GitHub, raising the operational risk above what the vendor-supplied CVSS 4.0 score of 2.1 suggests. No active exploitation has been confirmed via CISA KEV, but the combination of network accessibility, low complexity, and public PoC makes this a credible threat to any deployed unit.
Null byte and CRLF injection in Netty's SOCKS4 and SOCKS5 client encoders (Socks4ClientEncoder, Socks5ClientEncoder) allows an attacker who controls domain address or authentication fields to truncate or alter proxy connection parameters, enabling domain spoofing, userid truncation, authentication data injection, and protocol confusion. Affected are all Netty releases in the 4.1.x branch through 4.1.136.Final and the 4.2.x branch through 4.2.16.Final - both branches have been patched. No public exploit code has been identified at time of analysis and this CVE is not listed in CISA KEV, but the integrity impact on downstream SOCKS proxy routing is concrete.
Plugin integrity bypass in SiYuan before v3.7.4 allows attackers with same-origin access to overwrite trusted, installed plugins by exploiting the bazaar install endpoint's failure to verify that the downloaded package content matches the caller-supplied packageName. By pairing a legitimate plugin's packageName with an attacker-controlled repoURL, an adversary substitutes malicious plugin code that persists across application restarts, achieving durable code execution within the SiYuan application context. No public exploit code or active exploitation has been identified at time of analysis, but the persistence mechanism elevates the practical impact beyond the moderate CVSS score.
Unauthenticated shortcode injection in the kk Star Ratings - Rate Post & Collect User Feedbacks WordPress plugin (all versions through 5.4.10.3) allows any remote, unauthenticated attacker to execute arbitrary WordPress shortcodes by supplying a crafted payload to the plugin's AJAX handler. The flaw exists because the wp_ajax_kk-star-ratings action passes a user-controlled 'payload' parameter directly to do_shortcode() without allowlisting or sanitizing which shortcode tags are permitted. No public exploit has been identified at time of analysis and this CVE does not appear in the CISA KEV catalog; however, threat intelligence sources tag this as RCE, indicating that practical impact can escalate significantly depending on what shortcodes co-installed plugins register.
Unauthenticated styling data manipulation in the Themify Builder WordPress plugin (all versions through 7.8.0) allows any visitor to overwrite padding and margin properties on arbitrary posts, including private and draft content. The root cause is CWE-862 (missing authorization): the AJAX handler performing style writes relies solely on a WordPress nonce for access control, but that nonce is automatically broadcast to every frontend page via wp_localize_script, making it freely retrievable by any anonymous visitor. The CVSS score of 5.3 (AV:N/AC:L/PR:N/UI:N) is consistent with trivial unauthenticated network exploitation. No public exploit code or CISA KEV listing has been identified at time of analysis, but the low exploitation complexity makes opportunistic abuse realistic.
Permanent Wi-Fi denial-of-service in the Infineon AIROC driver shipped with Zephyr RTOS 3.6.0 through 4.4.1 allows a Wi-Fi-adjacent attacker to exhaust a fixed 20-buffer transmit/receive pool by inducing repeated synchronous WHD send failures, each of which leaks one buffer from airoc_pool without releasing it. Once the pool is fully exhausted, both transmit and WHD-driven receive paths fail, severing all Wi-Fi connectivity until the device is physically rebooted. No active exploitation is recorded in CISA KEV and no public exploit code has been identified, but the defect can also manifest organically over a device's operational lifetime through ordinary transient failures.
Webhook signature bypass in the Conekta Payment Gateway WordPress plugin (all versions before 6.2.2) allows unauthenticated remote attackers to fraudulently mark arbitrary WooCommerce orders as paid without any actual payment. The plugin neither validates that incoming webhook notifications originate from Conekta nor verifies that the payment amount or order binding matches the targeted order. No public exploit code or CISA KEV listing exists at time of analysis, but the attack path requires no authentication, no user interaction, and no special configuration, making it trivially automatable against any exposed merchant site.
Unauthenticated information disclosure in the FiboSearch WordPress plugin before 1.34.1 exposes password-protected WooCommerce products and their metadata to any website visitor without requiring the product password. Two AJAX endpoints - the autocomplete handler (dgwt_wcas_ajax_search) and the Details Panel handler (dgwt_wcas_result_details) - fail to enforce WooCommerce's native password-protection access control, allowing enumeration of restricted product names, slugs, and taxonomy data. No public exploit code identified at time of analysis; EPSS is 0.16% (5th percentile), indicating low current exploitation interest and no CISA KEV listing.
Cross-site request forgery in AVideo through commit 9c39d8c8 enables unauthenticated remote attackers to modify site-wide Gallery plugin configuration by exploiting the absence of CSRF token validation in channelToGallery.json.php. Any administrator who visits a crafted page while holding an active session can be silently coerced into promoting arbitrary channels to the front page or deleting curated gallery sections. No public exploit code or CISA KEV listing has been identified at time of analysis, and the impact is confined to integrity and limited availability of gallery content.
Authorization bypass in the Post Duplicator WordPress plugin (all versions ≤3.0.11) allows authenticated Contributor-level users to create duplicate posts with `future` (scheduled, auto-publishing) or `private` status, circumventing editorial review workflows that site administrators rely upon. The REST API endpoint's permission callback checks only the plugin's custom `duplicate_posts` capability while ignoring WordPress core status-gating capabilities such as `publish_posts`, and also disregards administrator-configured post-type duplication restrictions. No public exploit code has been identified and no CISA KEV listing exists, but the low attack complexity and network-accessible REST endpoint make this trivially abusable by any established contributor on a target site.
Unauthorized global theme modification in the GreenShift - Animation and Page Builder Blocks WordPress plugin (versions up to and including 12.8.9) is possible for any authenticated contributor-level user due to an insufficiently gated AJAX handler. The `gspb_update_global_wp_settings` function checks only for the `edit_posts` capability - a default contributor privilege - rather than requiring administrative rights, enabling site-wide defacement by overwriting theme color settings. No public exploit code or CISA KEV listing has been identified at time of analysis, but the low authentication bar makes this a realistic threat on any multi-author or open-registration WordPress deployment running the affected plugin.
Post Duplicator plugin for WordPress through version 3.0.11 permits authenticated contributors to forge post authorship by exploiting a missing capability check on the `duplicate-post` REST endpoint. The `duplicate_post()` function in includes/api.php accepts a `selectedAuthorId` parameter without verifying the caller holds the `edit_others_posts` capability, allowing any Contributor-level account to attribute cloned posts to administrators or other privileged users. No public exploit code exists and the CVE is not listed in the CISA KEV catalog, but the low attack complexity and broad availability of Contributor roles on multi-author WordPress sites make this a realistic threat to site integrity.
Authorization bypass in AutomatorWP WordPress plugin (all versions through 5.8.4) exposes ConvertKit integration credentials to any subscriber-level authenticated user. The ConvertKit AJAX endpoints in the plugin's integration layer perform no capability verification, and the nonce required to invoke them is embedded in every admin page load, eliminating the nonce's protective value for any authenticated user who can reach /wp-admin. No active exploitation is confirmed (not in CISA KEV) and no public exploit code has been identified at time of analysis, though the attack primitive is trivially reproducible from the referenced source code.
Authorization bypass in the AutomatorWP WordPress plugin (all versions ≤ 5.8.4) allows any authenticated subscriber to retrieve the site's Campaign Monitor mailing list catalog - list IDs and names - that should be restricted to users holding the plugin's manager capability. The flaw is compounded by unconditional nonce emission via wp_localize_script to every WordPress admin-area visitor, meaning the authentication token required to invoke the vulnerable AJAX endpoints is freely available to any registered user visiting /wp-admin/profile.php. No active exploitation is confirmed (not listed in CISA KEV) and no public exploit code was cited, though Wordfence identified and reported the issue with specific vulnerable code line references.
Tutor LMS WordPress plugin (all versions before 4.0.6) exposes private course content to any authenticated instructor via a missing per-object ownership check - a CWE-639 Insecure Direct Object Reference flaw. Any user holding the instructor role can read private course content authored by other instructors by referencing their course object IDs directly. No active exploitation has been confirmed (not in CISA KEV), EPSS sits at the 4th percentile (0.14%), and the vendor-released patch is available in version 4.0.6.
Path traversal in NLTK's CrubadanCorpusReader (versions 3.9.4 through 3.10.2) allows an attacker who controls a malicious corpus package to read arbitrary file contents outside the corpus root directory via the lang_freq interface. The vulnerability arises because _load_lang_ngrams bypasses NLTK's pathsec containment by calling the builtin open() instead of the pathsec-validated opener, enabling os.path.join to silently discard the corpus root prefix when an absolute path is supplied as the crubadan_code value. No public exploit exists and no KEV listing is present; a vendor patch is available in 3.10.3.
In the Linux kernel, the following vulnerability has been resolved: Input: evdev - sanitize event type index when fetching event masks The user-supplied event type index passed to EVIOCGMASK / EVIOCSMASK ioctls is used to index the static counts array in evdev_get_mask_cnt() and client evmasks array in evdev_get_mask(). While the event type is architecturally bounded by EV_CNT, speculative execution may mispredict bounds checks and perform out-of-bounds loads. Sanitize the event type index in evdev_get_mask_cnt() branchlessly using array_index_mask_nospec(). This clamps the index to 0 for safe array access and forces the returned count to 0 speculatively when the index is out of bounds. We do not need additional array_index_nospec() calls in evdev_get_mask() because evdev_get_mask_cnt() speculatively forces the count (and resulting xfer_size) to 0 for out-of-bounds types, preventing any speculative memory access to client evmasks array.
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: Use unsigned int for ndp_index The variable ndp_index is declared as a signed integer, but it stores the return value of get_ncm(), which is unsigned. A malicious host can supply a large offset that overflows the signed ndp_index, making it negative. Because ndp_index is compared against unsigned bounds, this negative value bypasses sanity checks and leads to an out-of-bounds read when calculating the address of the NDP block (ntb_ptr + ndp_index). Fix this by changing ndp_index to unsigned int to ensure consistent unsigned comparisons throughout the function.
In the Linux kernel, the following vulnerability has been resolved: net/smc: fix qentry overwrite for CONFIRM_LINK and ADD_LINK_CONT in smc_llc_event_handler() The SMC_LLC_CONFIRM_LINK / SMC_LLC_ADD_LINK_CONT branch in smc_llc_event_handler() stores an incoming qentry into the local LLC flow without first checking whether a qentry is already pending. If a malicious or buggy peer sends a second CONFIRM_LINK or ADD_LINK_CONT request while a flow is active and flow->qentry is already set, smc_llc_flow_qentry_set() overwrites the pointer without freeing the previous allocation, leaking one kmalloc-96 object per spurious message. The sibling SMC_LLC_DELETE_LINK branch already has the correct !flow->qentry guard. Apply the same guard to the CONFIRM_LINK/ADD_LINK_CONT branch so that a duplicate message when qentry is already occupied falls through to break and is freed by the kfree(qentry) at the out: label, rather than silently leaking the existing allocation. The response direction (smc_llc_rx_response()) is unaffected: it already guards with flow->qentry at the equivalent site and drops duplicate responses correctly.
In the Linux kernel, the following vulnerability has been resolved: net/ncsi: fix heap OOB read in NCSI_CMD_SEND_CMD payload length ncsi_send_cmd_nl() takes the number of bytes to copy from the attacker-controlled ncsi_pkt_hdr.length field of the in-band packet header, while the source buffer is the NCSI_ATTR_DATA netlink attribute whose readable size is nla_len() - sizeof(ncsi_pkt_hdr). The two length sources are never cross-checked: only nla_len() >= sizeof(struct ncsi_pkt_hdr) is enforced. With hdr->length set larger than the attribute payload (up to 65535 against at most 2032 readable bytes), ncsi_cmd_handler_oem() copies past the end of the netlink attribute buffer with unsafe_memcpy(), leaking up to ~64KB of kernel heap memory into the transmitted NCSI command packet. The destination skb is sized by the declared payload, so the write side does not overflow - this is a pure OOB read / information leak, reachable with CAP_NET_ADMIN on systems with a registered NCSI device (e.g. OpenBMC on Aspeed BMC SoCs, where NET_NCSI=y is standard). Reject commands whose declared payload extends past the end of the data attribute. The issue was found by the autokbug dynamic kernel fuzzer at Tencent Yunding Lab.
In the Linux kernel, the following vulnerability has been resolved: net: prestera: validate firmware header length prestera_fw_hdr_parse() reads the firmware header before checking that the firmware image contains that header. Reject images shorter than struct prestera_fw_header before decoding the magic and version fields.
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write on Type II inbound URBs data_ep_set_params() sizes each URB transfer buffer before it adds the Format Type II transfer delimiter: u->packets = urb_packs; u->buffer_size = maxsize * u->packets; if (fmt->fmt_type == UAC_FORMAT_TYPE_II) u->packets++; /* for transfer delimiter */ u->urb = usb_alloc_urb(u->packets, GFP_KERNEL); buffer_size is computed from the pre-increment packet count and never recomputed, so for a Type II endpoint the buffer is one packet short of the packet count the URB is built with. prepare_inbound_urb() then lays out one iso frame per packet and never consults buffer_size: offs = 0; for (i = 0; i < urb_ctx->packets; i++) { urb->iso_frame_desc[i].offset = offs; urb->iso_frame_desc[i].length = ep->curpacksize; offs += ep->curpacksize; } urb->transfer_buffer_length = offs; urb->number_of_packets = urb_ctx->packets; The last descriptor therefore points one packet past the end of the transfer buffer, where the host controller writes device data on every inbound transfer. prepare_silent_urb() and prepare_playback_urb() bound their fill loops by ctx->buffer_size, so only capture is affected. fmt_type comes from the device's audio streaming descriptors, so any device advertising a Type II capture format hits this once userspace sets hw_params on the stream. KASAN on 7.2.0-rc5 (arm64) with a dummy_hcd/raw-gadget device, one report per inbound transfer: BUG: KASAN: slab-out-of-bounds in dummy_timer Write of size 64 at addr ffff0000186171c0 by task cons02/166 __asan_memcpy dummy_timer hrtimer_run_softirq Allocated by task 166: usb_alloc_coherent snd_usb_endpoint_set_params The buggy address is located 0 bytes to the right of allocated 64-byte region [ffff000018617180, ffff0000186171c0) Compute buffer_size after the delimiter packet has been accounted for, and bound the fill loop by buffer_size, as prepare_silent_urb() already does on the outbound side. This grows every Type II URB allocation by one maxsize packet. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>
In the Linux kernel, the following vulnerability has been resolved: usb: atm: cxacru: properly kill rcv_urb on error in cxacru_cm() If cxacru_cm() encounters an error while submitting or waiting for snd_urb, it aborts and returns the error without killing the already submitted rcv_urb. This leaves the rcv_urb active. When this happens during initialization (e.g., in cxacru_atm_start()), the driver may ignore the error and proceed to call cxacru_poll_status(), which invokes cxacru_cm() again. Attempting to submit the still-active rcv_urb triggers a warning in usb_submit_urb(): cxacru 1-1:1.0: send of cm 0x84 failed (-104) ATM dev 0: cxacru_atm_start: CHIP_ADSL_LINE_START returned -104 ------------[ cut here ]------------ URB ffff88812658d200 submitted while active WARNING: drivers/usb/core/urb.c:379 at usb_submit_urb+0x79/0x18b0 drivers/usb/core/urb.c:379 ... Call Trace: <TASK> cxacru_cm+0x21a/0xf10 drivers/usb/atm/cxacru.c:631 cxacru_cm_get_array drivers/usb/atm/cxacru.c:722 [inline] cxacru_poll_status+0x178/0x1110 drivers/usb/atm/cxacru.c:828 cxacru_atm_start+0x185/0x360 drivers/usb/atm/cxacru.c:814 usbatm_atm_init+0x144/0x3a0 drivers/usb/atm/usbatm.c:927 usbatm_usb_probe+0x15cb/0x1db0 drivers/usb/atm/usbatm.c:1178 cxacru_usb_probe+0x17f/0x220 drivers/usb/atm/cxacru.c:1370 ... To fix this, ensure that rcv_urb is properly killed if cxacru_cm() aborts early. We can safely call usb_kill_urb() on rcv_urb in the error path, as it is safe to call even if the URB is not active (e.g., if it failed to submit in the first place, or if it already completed).
In the Linux kernel, the following vulnerability has been resolved: vt: add permission check for KDSKBMETA ioctl KDSKBMETA modifies keyboard meta mode but lacks the !perm check that all other keyboard setter ioctls in vt_k_ioctl() enforce, allowing a process to change meta mode on a non-controlling console without authorization.
In the Linux kernel, the following vulnerability has been resolved: Input: evdev - fix information leak in evdev_pass_values() In evdev_pass_values(), the input_event structure is allocated on the kernel stack and populated field-by-field. However, it is never fully initialized. On architectures where struct input_event contains explicit or implicit padding (such as the 32-bit __pad field on SPARC64), these padding bytes are left uninitialized. When this event structure is subsequently passed to the client buffer and later copied to userspace, the uninitialized padding bytes leak kernel stack memory, potentially exposing sensitive information. Similar issues exist in __evdev_queue_syn_dropped and __pass_event. Fix this by explicitly zeroing the entire event structure with memset() before populating its fields. This ensures all padding bytes are cleared before the data crosses the security boundary.
In the Linux kernel, the following vulnerability has been resolved: ima: fix out-of-bounds read in xattr_verify() The digest-length check in xattr_verify() mixes int and size_t: if (xattr_len - sizeof(xattr_value->type) - hash_start >= iint->ima_hash->length) sizeof() yields size_t, so the usual arithmetic conversions promote the whole left-hand side to unsigned 64-bit before the subtraction runs. For a truncated xattr this underflows instead of going negative: a 1-byte IMA_XATTR_DIGEST_NG xattr (xattr_len == 1, hash_start == 1) turns "1 - 1 - 1" into SIZE_MAX, which is trivially >= ima_hash->length. The check then passes and the following memcmp() reads iint->ima_hash->length bytes starting past the end of the buffer vfs_getxattr_alloc() allocated for it. Nothing upstream clamps xattr_len back into a safe range first: ima_get_hash_algo() only special-cases xattr_len < 2 to pick a default algorithm, and evm_verifyxattr() returns INTEGRITY_UNKNOWN rather than failing when no HMAC key is loaded, so a truncated security.ima value reaches the length check as-is. Rewrite the comparison so every operand stays a signed int and no implicit conversion to size_t can occur.
In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: reallocate update replies for mismatched IDs ovs_flow_cmd_new() preallocates the optional reply skb before it takes ovs_mutex and before it knows which existing flow will be updated. That is normally fine because the skb is sized from the request flow identifier. That identifier also becomes the inserted flow's identifier. For updates, however, a request with a UFID may miss the UFID lookup and then fall back to the flow key lookup. That lookup can legitimately find an existing key-identified flow. UFIDs are optional and the flow key is the primary identifier. For echoed replies, ovs_flow_cmd_fill_info() writes the matched flow's identifier, not the request identifier used for the preallocation. A short request UFID can therefore leave too little room for the key identifier. The fill can then fail with -EMSGSIZE and hit the BUG_ON(error < 0) in the update path. Once the update target has been resolved, reallocate the reply skb if the matched flow needs a larger reply than the request identifier allowed. Do this before replacing the actions so the request can still fail cleanly if the rare extra allocation fails.
In the Linux kernel, the following vulnerability has been resolved: futex: Prevent robust futex exit race some more A robust futex unlock stores 0 over the whole futex value - wiping FUTEX_WAITERS - and wakes a single waiter. That wakeup is a one-shot notification: the protocol relies on its recipient to either acquire the futex (and eventually unlock while aware of the remaining contention) or re-arm FUTEX_WAITERS before sleeping again. If the woken waiter is killed before it can do either, the kernel must jump in and wake the next task down the line. This is a known complication of the futex protocol with a previous partial fix in commit ca16d5bee598 ("futex: Prevent robust futex exit race"). Unfortunately, that fix is insufficient. If a third task re-acquired the futex through the uncontended fast path in the meantime, the notification is lost: robust exit processing sees that it is owned by another task and does nothing, while the new owner sees no FUTEX_WAITERS when it unlocks and wakes nobody. The remaining waiters sleep forever behind a free futex: A owns the futex, B and C sleep in FUTEX_WAIT uval == A | FUTEX_WAITERS A robust unlock: store 0, FUTEX_WAKE(1) wakes B uval == 0 D fast path acquire: cmpxchg(0 -> D) uval == D, no FUTEX_WAITERS B killed before acting on the wakeup B exit walk, pending op: owner D != B -> no action D unlock: no FUTEX_WAITERS -> no wake C sleeps forever This is clearly a shortcoming in the implementation, which fails to keep the FUTEX_WAITERS bit consistent. Work around this by augmenting the robust list exit processing to also perform the extra wakeup if the futex word is owned by another thread but FUTEX_WAITERS is not set. This does not fix the problem of a non-contended take over/release and free sequence, which has been discussed for years and has been addressed by commit 3ca9595d9fb6 ("futex: Add support for unlocking robust futexes") and subsequent changes, but failed to take the problem described above into account. A more complete solution which is based on the in kernel unlock of contended robust futexes has been discussed in the context of this change and should show up in mainline sooner than later. [ tglx: Amend change log slightly and fixup coding style ]
In the Linux kernel, the following vulnerability has been resolved: serial: 8250_dma: Clear stale RX state on shutdown serial8250_release_dma() terminates RX DMA and releases the channel, but leaves rx_running set. If the port is closed while an RX transfer is active, the stale state remains while rxchan is NULL until the channel is requested again on the next open. The DesignWare BUSY workaround added by commit a7b9ce39fbe4 ("serial: 8250_dw: Ensure BUSY is deasserted") calls serial8250_rx_dma_flush() from the LCR write path during startup. This happens before serial8250_request_dma() obtains a new RX channel. On reopen, the stale rx_running state therefore makes the flush path pass a NULL channel to dmaengine_pause(), causing a kernel Oops. Clear rx_running after terminating RX DMA, matching the TX cleanup. Also make the flush helper return if the DMA object or RX channel is not available so startup and teardown paths cannot pass a NULL channel to the DMAengine API.
In the Linux kernel, the following vulnerability has been resolved: net: atlantic: free RX pages of consumed but not refilled buffers aq_ring_rx_deinit() only walks [sw_head, sw_tail), the region posted to hardware. Since the page reuse strategy was added, a cleaned RX buffer keeps its page (and its DMA mapping) in the ring for reuse, and refill is batched: aq_ring_rx_fill() returns early until AQ_CFG_RX_REFILL_THRES slots are free. Slots that were consumed but not yet reposted therefore sit in the complementary [sw_tail, sw_head) gap with a live page, and the deinit walk never visits them: up to a refill batch worth of pages and DMA mappings leak on every interface down. Walk the whole ring instead and release whatever is still there. Also bail out if the buffer ring is already gone: a partial aq_ptp_ring_alloc() failure frees the ring but leaves aq_nic set, so aq_ptp_ring_deinit() still gets here on the unwind path.
In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Bound the DROM dual link port number before indexing sw->ports tb_drom_parse_entry_port() validates the device-supplied header->index against sw->config.max_port_number before indexing sw->ports[], but the sibling field entry->dual_link_port_nr -- a 6-bit value also read from the DROM -- indexes the same array with no such check. A malicious or malformed Thunderbolt device can set dual_link_port_nr beyond the allocated sw->ports[] (max_port_number + 1 entries), producing an out-of-bounds tb_port pointer that is stored and later dereferenced. Reject a port entry whose dual_link_port_nr exceeds max_port_number, the same bound already applied to header->index.
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix memory leak in btrfs_do_encoded_write() Local fuzzing of 6.12.94 has found the following memory leak: Unreferenced object 0xffff888018050a80 (size 64): comm "syz.0.17", pid 10297, jiffies 4294953601 hex dump (first 32 bytes): 00 10 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................ 10 0a 05 18 80 88 ff ff 10 0a 05 18 80 88 ff ff ................ backtrace (crc a8a6fc29): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] extent_changeset_alloc fs/btrfs/extent_io.h:207 [inline] qgroup_reserve_data+0x1c5/0x7d0 fs/btrfs/qgroup.c:4305 btrfs_qgroup_reserve_data+0x2e/0xb0 fs/btrfs/qgroup.c:4355 btrfs_do_encoded_write+0x92e/0x1040 fs/btrfs/inode.c:9746 btrfs_encoded_write fs/btrfs/file.c:1482 [inline] btrfs_do_write_iter+0x280/0x610 fs/btrfs/file.c:1507 btrfs_ioctl_encoded_write+0x3d6/0x490 fs/btrfs/ioctl.c:4738 btrfs_ioctl+0x6f9/0xc90 fs/btrfs/ioctl.c:-1 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:47 [inline] do_syscall_64+0xbe/0x1a0 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f Unreferenced object 0xffff888018050a00 (size 64): comm "syz.0.17", pid 10297, jiffies 4294953601 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 ff 0f 00 00 00 00 00 00 ................ 90 0a 05 18 80 88 ff ff 90 0a 05 18 80 88 ff ff ................ backtrace (crc cb5c9580): kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline] slab_post_alloc_hook mm/slub.c:4152 [inline] slab_alloc_node mm/slub.c:4197 [inline] __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] ulist_prealloc+0x9c/0x110 fs/btrfs/ulist.c:114 extent_changeset_prealloc fs/btrfs/extent_io.h:217 [inline] __set_extent_bit+0x16b/0x1a70 fs/btrfs/extent-io-tree.c:1086 set_record_extent_bits+0x50/0x90 fs/btrfs/extent-io-tree.c:1821 qgroup_reserve_data+0x274/0x7d0 fs/btrfs/qgroup.c:4312 btrfs_qgroup_reserve_data+0x2e/0xb0 fs/btrfs/qgroup.c:4355 btrfs_do_encoded_write+0x92e/0x1040 fs/btrfs/inode.c:9746 btrfs_encoded_write fs/btrfs/file.c:1482 [inline] btrfs_do_write_iter+0x280/0x610 fs/btrfs/file.c:1507 btrfs_ioctl_encoded_write+0x3d6/0x490 fs/btrfs/ioctl.c:4738 btrfs_ioctl+0x6f9/0xc90 fs/btrfs/ioctl.c:-1 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:47 [inline] do_syscall_64+0xbe/0x1a0 arch/x86/entry/common.c:78 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this by freeing an extent changeset before returning from btrfs_do_encoded_write().