Vulnerabilities

CVE-2026-73175 is an uncontrolled resource consumption flaw (CWE-400) in the OPC UA gateway component of the Advantech EKI-1242EIMS industrial gateway, confirmed in firmware version V1.06.01. An adjacent (same network segment) unauthenticated attacker can open multiple anonymous OPC UA sessions, exhausting the device's server session pool. Once the pool is exhausted, all legitimate OPC UA clients are denied service, resulting in a complete availability impact with no confidentiality or integrity impact (CVSS 4.0: 7.1 High). Operators of EKI-1242EIMS gateways in industrial and OT networks are affected, particularly where flat or poorly segmented networks allow adjacent devices to reach the OPC UA service. No public proof-of-concept is known, the flaw is not in CISA KEV, and there is no evidence of exploitation in the wild.

Do: Check the installed firmware version on EKI-1242EIMS units and upgrade to a fixed release from Advantech as soon as one is published (no fixed version is identified in the advisory). Until patching, restrict access to the gateway's OPC UA interface to trusted clients on the OT network segment, disable or limit anonymous sessions where the configuration allows, and segment the network so unauthenticated adjacent devices cannot reach the device. Monitor for abnormal session creation or gateway unavailability.

Advantech's EKI-1242EIMS edge device transmits its edgserver management protocol data without encryption (CWE-319), as identified by Nozomi Networks Labs in firmware V1.06.01. A network-adjacent attacker can passively observe this traffic—no active exploitation, privileges, or user interaction are required. By sniffing the cleartext management traffic, the attacker recovers sensitive device identity information and network metadata, which can support reconnaissance and follow-on attacks against the OT environment. Any deployment running EKI-1242EIMS firmware V1.06.01 where management traffic crosses network segments an attacker can observe is affected. No public proof-of-concept, CISA KEV listing, or confirmed in-the-wild exploitation is known at this time.

Do: Check deployed EKI-1242EIMS units for firmware V1.06.01 and monitor the Advantech security advisory and product pages for a fixed firmware release before upgrading. Until a fix is available, limit exposure by segmenting management traffic away from attacker-reachable network segments, restricting L2 adjacency, and carrying edgserver traffic over an encrypted tunnel or out-of-band management network. Review network monitoring for any passive sniffing indicators on segments hosting these devices.

The edgserver management protocol of the Advantech EKI-1242EIMS firmware version V1.06.01 performs no authentication for critical device-management functions (CWE-306). A remote, unauthenticated attacker can trigger these functions simply by sending crafted requests to TCP port 5058, gaining the ability to reconfigure the device's network settings, reboot or factory-reset it, and push a firmware upgrade. This effectively gives an attacker full administrative control over the device without any credentials, enabling denial of service, disruption of the network path the gateway manages, and potential implantation of malicious firmware. Any organization running the EKI-1242EIMS on the affected firmware is exposed, particularly where TCP port 5058 is reachable from untrusted networks. As of publication there is no evidence of exploitation in the wild, the issue is not in CISA's KEV catalog, and no public proof-of-concept is known; the flaw was identified by Nozomi Networks Labs.

Do: Inventory for EKI-1242EIMS devices and verify the firmware version, treating V1.06.01 as vulnerable. Immediately restrict access to TCP port 5058 with firewall rules or ACLs so only trusted management hosts can reach it, and never expose this port to the internet or flat IT networks. Contact Advantech for a patched firmware release and apply it as soon as available; until then, monitor the device for unexpected reboots, configuration changes, or firmware updates.

Advantech's EKI-1242EIMS edge gateway, in firmware version V1.06.01, contains an OS command injection flaw (CWE-78) in its edgserver management service. A remote, unauthenticated attacker can send specially crafted requests to TCP port 5058 to inject and execute arbitrary operating system commands on the device. Because the injected commands run with root privileges, a successful exploit gives the attacker full control of the gateway, which is typically positioned to bridge IT and OT/industrial network segments. Any deployed EKI-1242EIMS running firmware V1.06.01 is affected, particularly units where port 5058 is reachable from untrusted networks. No exploitation in the wild, public proof-of-concept code, or KEV listing is known as of this analysis.

Do: Check deployed EKI-1242EIMS devices and upgrade to a firmware version newer than V1.06.01 as soon as Advantech publishes a fix. In the meantime, restrict access to TCP port 5058 with firewall/ACL rules so only trusted management hosts can reach it, and review logs for unexpected connections to that port. Treat any gateway exposed to the internet on port 5058 as high priority to remediate, given the pre-authentication, root-level nature of the flaw.

Advantech EKI-1242EIMS industrial gateway firmware V1.06.01 contains an external control of file name or path flaw (CWE-73) in its backup-restore workflow, discovered by Nozomi Networks Labs. A remote attacker who already holds high-privileged (administrative) credentials can upload a crafted backup archive through the web management interface, with the archive's internal file paths not properly validated. This lets the attacker overwrite arbitrary files on the device filesystem, which the CVSS 4.0 score of 8.6 (high) reflects as high impact on the confidentiality, integrity, and availability of the device, potentially enabling persistent compromise or denial of service of the gateway. Only deployments of the EKI-1242EIMS running the affected firmware with the web interface reachable are exposed, and exploitation requires valid administrative credentials. As of now, the flaw is not in CISA's KEV catalog, no public proof-of-concept is known, and no exploitation has been reported.

Do: Restrict access to the EKI-1242EIMS web management interface to trusted management networks via firewalling or VLAN segmentation, and enforce strong, unique administrative credentials since valid high-privileged access is required to exploit this flaw. Monitor Advantech's product security advisories and upgrade to a fixed firmware release when one is published, as no fixed version is identified in the current data. Check logs for unexpected backup/restore operations and verify the integrity of files on affected devices.

Advantech EKI-1242EIMS firmware version V1.06.01 contains a CWE-94 code injection flaw in the device's Modbus CSV import workflow. An attacker who holds valid, high-privileged credentials can upload a crafted CSV file through the import function, causing the gateway to execute arbitrary Lua code embedded in the file. Successful exploitation yields full confidentiality, integrity, and availability impact on the device, meaning an attacker could take control of the gateway and potentially manipulate the Modbus communications it brokers in an industrial network. Any deployment of EKI-1242EIMS running V1.06.01 with users who can access the CSV import feature is affected, with the practical barrier being the need for an authenticated account. As of now, the vulnerability is not in CISA's KEV catalog, no public proof-of-concept is known, and no exploitation has been observed in the wild.

Do: Check with Advantech for a firmware release newer than V1.06.01 that addresses the Modbus CSV import code injection and apply it when available. Until then, restrict the device's management interface to trusted administrative users on a segmented OT network, never expose the gateway directly to the internet, and audit accounts that can perform CSV imports. Nozomi Networks Labs' advisory is the source for details; monitor OT traffic for unexpected Lua/script-related device behavior.

Nozomi Networks Labs identified a CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in the Modbus transaction management interface of Advantech EKI-1242EIMS in firmware version V1.06.01 that allows a remote authenticated attacker to store malicious script content that executes in the browser of any administrator who later opens an affected management page.

CVE-2026-19535 is a Cross-Site Request Forgery (CWE-352) flaw in the LuCI administrative web interface of the Advantech EKI-1242IEIMS running firmware V1.06.01, identified by Nozomi Networks Labs. A remote unauthenticated attacker can trigger it by inducing the browser of a logged-in administrator to submit unauthorized state-changing requests to the device's management interface, typically via a malicious page or link visited while the admin session is active. Successful exploitation grants the attacker the ability to invoke privileged management functions as the administrator, which per the CVSS 4.0 score (8.6 High) can compromise the confidentiality, integrity, and availability of the device. Only operators of the Advantech EKI-1242IEIMS running the affected firmware are exposed, and the attack requires user interaction from an authenticated administrator. As of this analysis, the issue is not listed in CISA KEV, no public proof-of-concept is known, and no in-the-wild exploitation has been reported.

Do: Contact Advantech or check its support portal for a firmware release that fixes this CSRF issue, as no fixed version is specified in the available data. Until patched, restrict access to the LuCI management interface to trusted OT network segments or VPN (block direct internet exposure), and have administrators close LuCI sessions before browsing untrusted websites. Review device configuration logs for unexpected or unauthorized management changes.

The WP Mega Menu plugin by Themeum fails to properly neutralize special elements in an SQL command, allowing blind SQL injection (CWE-89) in all versions through 1.4.2. Per the CVSS vector, exploitation requires a network-accessible attacker who already holds high privileges on the WordPress site (e.g., an administrator account), with no user interaction and low attack complexity. Through blind injection, an attacker can extract arbitrary data from the site database character by character, potentially exposing user credentials, password hashes, and other sensitive information, with minor availability impact. Any WordPress site running WP Mega Menu at version 1.4.2 or earlier is affected. No public proof-of-concept, listings in CISA's KEV catalog, or reports of in-the-wild exploitation are currently known.

Do: Update WP Mega Menu to the latest release (any version newer than 1.4.2 once available from Themeum/WordPress.org), or deactivate the plugin until a patched version is published. Restrict and audit administrator-level accounts, since the flaw requires high-privilege access to trigger, and monitor Patchstack's advisory for the fixed version details. Check plugin versions across your WordPress estate (e.g., via WP-CLI or a vulnerability scanner) to confirm no site is running 1.4.2 or earlier.

yshop-crm through 2.1.3 fails to enforce authorization on the GET /admin-api/system/user/page endpoint because the @PreAuthorize permission annotation is commented out (CWE-862, missing authorization). To exploit it, an attacker needs valid back-office credentials and a role assigned a data scope of ALL, but does not need the system:user:list permission that the endpoint is supposed to require. A successful attacker can retrieve the complete user directory, including login names, nicknames, departments, email addresses, mobile numbers, and last-login information — useful for follow-on phishing, credential attacks, or social engineering. Any deployment of yshop-crm at version 2.1.3 or earlier is affected. No exploitation has been reported, no public proof-of-concept is known, and the issue is not in CISA KEV; it carries a CVSS 4.0 score of 7.1 (high).

Do: Upgrade to a release in which the @PreAuthorize permission check on /admin-api/system/user/page is restored (no fixed version is specified in the data); as an interim measure, re-enable the authorization annotation or block/limit access to the endpoint at a gateway. Review roles configured with data scope ALL and least-privilege back-office accounts, and audit access logs for unexplained calls to /admin-api/system/user/page.

yshop-crm through version 2.1.3 contains a missing authorization flaw (CWE-862) in the CrmFlowController deleteFlowStep function. Any authenticated back-office user, regardless of assigned permissions, can invoke DELETE /admin-api/crm/flow/delete-step to delete arbitrary approval workflow steps. Because those steps gate the finalization of contracts, receivables, and invoices, an attacker can weaken or disable approval controls and push records through finalization without proper review, or disrupt the approval process entirely. Any organization running a self-hosted yshop-crm instance at version 2.1.3 or earlier is affected. No public proof-of-concept exists, the flaw is not in CISA's KEV catalog, and no exploitation is currently known.

Do: Upgrade yshop-crm to a release newer than 2.1.3 that restores the permission check on the deleteFlowStep endpoint as soon as one is published. Until then, restrict access to /admin-api/crm/flow/delete-step at the reverse proxy or gateway layer to roles that genuinely require it, and review approval workflow step configurations for unexplained deletions. Audit back-office account activity and API logs for DELETE requests to this endpoint to detect potential abuse.

yshop-crm through 2.1.3 contains a missing authorization vulnerability in the GET /admin-api/crm/flow/flow-users endpoint that allows any logged-in back-office user to access approval workflow data. Attackers can retrieve approval chain topology, step ordering, approver identifiers, and personal information including login names, nicknames, departments, email addresses, mobile numbers and last login IP addresses.

yshop-crm through 2.1.3 fails to enforce authorization (CWE-862) on the GET /admin-api/crm/operatelog/page endpoint, which serves the installation-wide operation/audit log. Any user with even low-privilege authenticated access to the back-office API can call this endpoint over the network without administrator rights. By doing so, the attacker obtains operator account names, display nicknames, client IP addresses, User-Agent strings, request URLs, action details, and customer identifiers — useful intelligence for further attacks, internal recon, or targeted phishing. Any organization running a self-hosted yshop-crm instance at version 2.1.3 or earlier is affected. No public proof-of-conct has been released, the issue is not in CISA KEV, and no in-the-wild exploitation is confirmed; CVSS 4.0 scores it 7.1 (High) with high confidentiality impact.

Do: Upgrade yshop-crm to a release newer than 2.1.3 as soon as a patched version incorporating an authorization check on the operatelog/page endpoint is available. Until then, restrict network access to the /admin-api/ surface (reverse-proxy ACL or VPN), and audit web-server logs for calls to /admin-api/crm/operatelog/page by non-administrator accounts, which would indicate abuse. Review back-office role assignments to minimize how many low-privilege users can reach admin-api endpoints.

yshop-crm through version 2.1.3 contains a missing authorization flaw (CWE-862) in the CrmCluesController receiveCustomer endpoint, which is used to claim sales leads. Any authenticated back-office user can invoke this endpoint without the permission check it should enforce, overwriting the ownerUserId field to reassign leads that belong to other employees to themselves. Because the endpoint performs no access logging and no quota validation, an attacker with even low-level credentials can silently siphon large volumes of leads in bulk, damaging the integrity of the sales pipeline. Any organization running yshop-crm up to and including 2.1.3 is affected. No public proof-of-concept is known and the flaw is not in CISA's KEV, so exploitation has not been confirmed in the wild.

Do: Upgrade yshop-crm to a version patched for CVE-2026-92459 when the vendor releases one (no fixed version is specified in current disclosures); meanwhile, restrict which back-office roles can reach the CrmCluesController receiveCustomer endpoint, e.g., via a gateway or WAF rule. Audit lead records for ownerUserId changes that no legitimate user action explains, and review which low-privilege accounts hold back-office credentials that could reach the endpoint.

yshop-crm through 2.1.3 contains a missing authorization vulnerability in the StoreProductController onSale handler that allows authenticated back-office users to modify product sale status. Attackers can invoke the GET /admin-api/product/store-product/sale endpoint with sequential product IDs to withdraw entire product catalogs from sale or re-enable withdrawn products without proper permission checks.

yshop-crm through 2.1.3 fails to enforce a permission check on the CrmInvoiceController issueInvoice endpoint, a classic CWE-862 missing authorization flaw. Any authenticated back-office user, regardless of assigned role, can call PUT /admin-api/crm/invoice/issue and perform invoice issuance actions that should require elevated permissions. By exploiting this, an attacker can modify invoice status, inflate contract invoiced amounts with arbitrary attacker-chosen values, and trigger invoice emails to arbitrary addresses, enabling financial-record manipulation and possible fraud or phishing via spoofed invoice emails. All deployments of yshop-crm up to and including version 2.1.3 are affected. No public proof-of-concept or confirmed in-the-wild exploitation is known at this time.

Do: Upgrade yshop-crm to a release newer than 2.1.3 as soon as a patched version is available. As interim mitigation, restrict access to the /admin-api/crm/invoice/issue endpoint (e.g., via a gateway or WAF rule) and audit back-office accounts for over-broad access. Review existing invoice records and contract invoiced amounts for tampering and check email logs for unexpected invoice issuances or messages sent to unknown addresses.

yshop-crm through version 2.1.3 fails to enforce authorization (CWE-862) on the saveRedisSet and getRedisSet endpoints in CrmCustomerController, leaving installation-wide lead-allocation and customer auto-recycling settings unprotected. Any authenticated back-office user, regardless of assigned role or permissions, can invoke these network-reachable endpoints to read and overwrite the shared Redis keys that drive customer auto-recycling behavior. By manipulating those keys, an attacker can trigger mass deletion of customer data, disable lead recycling entirely, or block creation of new customers across the whole deployment. All yshop-crm deployments at version 2.1.3 or earlier that have low-privilege back-office accounts are affected. No public proof-of-concept, CISA KEV listing, or confirmed in-the-wild exploitation is known; the flaw carries a CVSS 4.0 score of 7.1 (high).

Do: Upgrade to a fixed release newer than 2.1.3 as soon as the vendor publishes one, and track the project repository for the patch. As an interim mitigation, block or restrict access to the saveRedisSet and getRedisSet endpoints in CrmCustomerController at the reverse proxy or WAF, and audit shared Redis keys for unauthorized changes to recycling policy. Review back-office account lists and remove or downgrade low-privilege users who do not need CRM access.

yshop-crm through 2.1.3 fails to enforce authorization on the sendSms and sendMail endpoints in CrmCustomerController, allowing any authenticated back-office user to send SMS and email to arbitrary customers. Attackers can invoke POST /admin-api/crm/customer/send-sms and POST /admin-api/crm/customer/send-mail with arbitrary customerIds, templateCode, and templateParams to deliver unauthorized messages through the organization's SMS and email channels.

WNC's T-Mobile 5G Box IDU router contains an OS command injection flaw (CWE-78) in the portal.cgi component's password change functionality. The web application fails to properly neutralize special characters in the http_passwd_hidden and http_passwdConfirm_hidden parameters, allowing submitted values to be interpreted as operating system commands. An attacker who is already authenticated to the router's management portal (CVSS 4.0 rates privileges required as high, with adjacent-network attack vector) can leverage this to execute arbitrary commands with root privileges on the device's underlying OS. Any subscriber or operator running affected firmware on this gateway is exposed, primarily to attackers on the local network or connected clients. No exploitation in the wild, public proof-of-concept, or KEV listing is currently known, and a fixed firmware version (1.1.0.651412) has been released.

Do: Upgrade the gateway to firmware version 1.1.0.651412 or later, checking the current version in the router's admin portal. Restrict management-portal access to trusted LAN clients, ensure strong non-default admin credentials are set, and monitor for client compromise, since exploitation requires valid portal authentication from an adjacent network.

The WNC T-Mobile 5G Box IDU router contains an unauthenticated OS command injection flaw (CWE-78) in its /cgi-bin/portal.cgi web portal endpoint. The cli_cookie POST parameter is concatenated directly into a shell find command without sanitization, so a crafted POST request allows an attacker to append and execute arbitrary shell commands. Successful exploitation yields command execution as root on the underlying operating system, giving full control of the gateway and the traffic it handles. Per the CVSS 4.0 vector (AV:A), exploitation requires an attacker positioned on the network adjacent to the router, such as a device on its Wi-Fi or LAN, with no credentials or user interaction needed. All firmware prior to 1.1.0.651412 is affected; no public proof-of-concept, KEV listing, or confirmed in-the-wild exploitation is currently known.

Do: Upgrade the router to firmware version 1.1.0.651412 or later. Until updated, do not expose the management portal (/cgi-bin/portal.cgi) to the WAN and restrict LAN/Wi-Fi access to trusted devices. Check device logs for unexpected POST requests to /cgi-bin/portal.cgi containing a cli_cookie parameter, which may indicate exploitation attempts.

The WNC T-Mobile 5G Box IDU router contains a cross-site request forgery (CWE-352) flaw in its portal.cgi component: the anti-CSRF mechanism fails to actually validate the csrf_token_value parameter, so any arbitrary token value is accepted as valid. An attacker exploits this by luring an already-authenticated user (e.g., someone logged into the router's admin portal) into visiting a malicious website, whose pages silently submit forged requests to the gateway over the local network. Because the CSRF check is effectively bypassed, the attacker can perform unauthorized actions on the device with the victim's session, such as changing device settings — reflected in the CVSS 4.0 score of 8.4 with high confidentiality and integrity impact and a requirement for user interaction. All users of this T-Mobile-branded router running firmware older than 1.1.0.651412 are affected. No exploitation has been reported in the wild, no public proof-of-concept is known, and the flaw is not listed in CISA's KEV catalog.

Do: Upgrade the router to firmware version 1.1.0.651412 or later, available through the device's update mechanism or T-Mobile support. Until updated, avoid clicking links in unsolicited emails or websites while connected to the gateway's network, and review device settings (DNS servers, admin credentials, port forwarding) for unexpected changes.

The WNC T-Mobile 5G Box IDU router has an improper access control flaw (CWE-306): the wnc_maccheck.cgi endpoint can be reached without any authentication. An unauthenticated attacker on an adjacent network (per the CVSS 4.0 attack vector, e.g., the same LAN or Wi-Fi segment) can query this endpoint and pull sensitive configuration data. The disclosed data includes the administrator web password, the Wi-Fi passphrase, and technical device information, potentially allowing takeover of router administration or access to the wireless network. All users of this router running firmware older than 1.1.0.651412 are affected. No public proof-of-concept, KEV listing, or confirmed in-the-wild exploitation is known.

Do: Upgrade the router to firmware version 1.1.0.651412 or later via the device's firmware update mechanism. Until patched, restrict the management interface to a trusted LAN segment and confirm remote/WAN administration is disabled. Because the admin password and Wi-Fi passphrase are recoverable by local attackers, rotate both credentials after updating if untrusted devices may have had local network access.

The WNC-manufactured T-Mobile 5G Box IDU router contains a command injection flaw (CWE-78) in the ping functionality of its /cgi-bin/portal.cgi web endpoint. The ping_ip, ping_size, and ping_times POST parameters are incorporated into a system command without verification or sanitization, allowing an attacker to append arbitrary shell commands. Because the CVSS vector requires adjacent-network access and high privileges, an attacker needs valid credentials on the router's portal interface, but once authenticated they can execute arbitrary commands and gain root access, fully compromising the gateway. All units running firmware before 1.1.0.651412 are affected, and a fixed firmware is available. No public proof-of-concept is known, the issue is not in CISA's KEV, and no in-the-wild exploitation has been confirmed.

Do: Upgrade the router to firmware 1.1.0.651412 or later via the admin portal or carrier-pushed updates, and verify the running version in the web interface. Because exploitation requires portal credentials, set a strong admin password, keep remote/WAN management of the portal disabled, and limit admin access to trusted LAN clients.

The WNC T-Mobile 5G Box IDU router contains an authentication bypass (CWE-290) in its portal.cgi component, where session verification only checks that a file matching the sessionid cookie value exists under /tmp/login_user. Because that check can be satisfied with directory entries such as '.' or '..', an unauthenticated attacker can forge a cookie value that passes validation. Successful bypass grants unauthorized access to the router's administration panel, where high-impact configuration and control actions are possible (CVSS 4.0 rates confidentiality, integrity, and availability impact as high). The attack vector is adjacent (AV:A), meaning the attacker must already be on the local network, such as a Wi-Fi or LAN client. No public proof-of-concept, in-the-wild exploitation, or KEV listing is known; affected users should move to firmware 1.1.0.651412 or later.

Do: Upgrade the router to firmware 1.1.0.651412 or later and verify the installed version in the administration panel. Because exploitation requires adjacent network access, avoid connecting untrusted devices to the router's LAN/guest networks until updated, and confirm the administration interface is not reachable from the WAN side.

A vulnerability was identified in a2ui-project a2ui 0.8/0.9/1.0. Impacted is an unknown function of the file model-processor.ts of the component Model Processor. The manipulation of the argument current[segment] leads to information disclosure. The attack may be initiated remotely. The identifier of the patch is 1b3bff234661ce922cbc3771be642b23ec9fd0fa. To fix this issue, it is recommended to deploy a patch.

A vulnerability was determined in a2ui-project a2ui 0.9/0.9.1. This issue affects the function updateComponents of the file basic_functions.ts of the component Update Components. Executing a manipulation can lead to resource consumption. The attack can be launched remotely. The project was informed of the problem early through an issue report but has not responded yet.

The Linux kernel's skb_zerocopy() helper destructively calls skb_tx_error() on the source socket buffer when skb_orphan_frags() fails, completing the source skb's zerocopy uarg and clearing the SKBFL_SHARED_FRAG page-ownership flag on a buffer the helper does not own. On the Open vSwitch OVS_ACTION_ATTR_USERSPACE path the skb is not freed after this error - do_execute_actions() ignores output_userspace()'s return value and keeps forwarding the same skb - so zerocopy buffers can be signaled as free while still in flight, and because SKBFL_SHARED_FRAG is cleared, esp_input() can decrypt in place over page fragments the skb does not privately own. A local attacker able to push traffic through an affected Open vSwitch datapath or an nfnetlink_queue (NFQUEUE) flow and trigger a frag-orphaning failure can cause use-after-free conditions and kernel memory/data corruption, with kernel-level confidentiality, integrity and availability impact (CVSS 9.3, local vector, scope changed). Any Linux system with the pre-fix kernel code is affected, with realistic trigger exposure on hosts running the Open vSwitch kernel datapath or NFQUEUE userspace queuing; the source data provides no specific vulnerable or fixed version numbers. No exploitation is known, no public proof-of-concept exists, and the issue is not listed in CISA KEV.

Do: Apply the stable fix ('net: skbuff: don't skb_tx_error() the source skb in skb_zerocopy()') as soon as your distribution or vendor ships an updated kernel, prioritizing hypervisors, SDN gateways and other hosts running the Open vSwitch kernel module or NFQUEUE/nfnetlink_queue rules (check with 'lsmod | grep openvswitch' and nftables/iptables NFQUEUE targets). Until patched, limit untrusted local code execution on OVS/NFQUEUE hosts and treat IPsec/ESP termination on those hosts as higher risk. No public PoC or in-the-wild exploitation is known, so monitor vendor advisories for fixed version numbers.

CVE-2026-90048 is a slab-out-of-bounds (heap) write in ni_create_attr_list() in the Linux kernel's NTFS3 filesystem driver: the attribute-list buffer is allocated at the fixed MFT record size, but a record packed with many minimal-size resident attributes generates an attribute list larger than that buffer, and the code advances its write cursor without any bounds check (the total size is only computed after the loop). It is triggered from a crafted, loop-mounted NTFS image - opening a file and adding an attribute (e.g., via setxattr) drives ntfs_set_ea() -> ni_insert_resident() -> ni_insert_attr() -> ni_ins_attr_ext() -> ni_create_attr_list(), with KASAN reporting a 4-byte write landing just past the end of a 1024-byte kmalloc-1k object. An attacker who can get a crafted image mounted gains kernel heap memory corruption, which typically enables local privilege escalation or a kernel crash (denial of service); despite the network-vector CVSS of 9.8, the practical trigger requires locally mounting untrusted NTFS media. Any Linux system with the NTFS3 driver enabled is affected, most notably desktops and multi-user servers where unprivileged users can mount removable drives or disk images. No public proof-of-concept, no CISA KEV listing, and no confirmed in-the-wild exploitation are known at this time.

Do: Update affected systems to a kernel that includes the upstream fs/ntfs3 fix that sizes the attribute-list buffer from the actual attributes (fixed-release version numbers were not available in the data - track your distro's kernel security updates). Until patched, avoid mounting untrusted NTFS images or removable media, restrict unprivileged loop mounting and use of setxattr on NTFS volumes, and blacklist/unload the ntfs3 module if NTFS support is not needed. Check your kernel config for CONFIG_NTFS3_FS/ntfs3 to determine exposure.

The Linux kernel's XE GPU driver (drm/xe, used for Intel Xe graphics) rounds the flat CCS compression-storage base up to 128 KiB and hands everything below that limit to the VRAM allocator, publishing the tail of a page that actually belongs to the GPU's compression hardware as free memory. The compression hardware overwrites that tail with metadata without needing a page-table entry, buffer object, or GPU submission, and does so before userspace even starts. On an Intel Battlemage G21 with 16 GiB VRAM, a Mesa VM's level-3 page table repeatedly landed on that page at cold boot, losing the mapping for the compositor's batch-buffer heap and causing gdm to restart in a loop, i.e. a black screen on an otherwise working machine. The flaw is rated 7.8 (high) with local attack vector and high confidentiality, integrity and availability impact, so the resulting memory corruption is exploitable in principle by a local attacker. No public proof-of-concept or known exploitation exists and the issue is not in CISA KEV; affected users are those running kernels with the XE driver on affected Intel Xe2/Battlemage hardware until they install a kernel with the one-line round_down() fix.

Do: Update to a Linux kernel build that includes the drm/xe fix (round_down() instead of round_up() in get_flat_ccs_offset()); no fixed version number is given in the data, so check your distribution for a kernel containing this patch. If you experience a black screen with gdm restarting in a loop at cold boot on a Battlemage GPU, restarting the display manager reallocates the page tables and temporarily clears the symptom. Confirm whether CONFIG_DRM_XE is enabled in your kernel and whether your system uses an Intel Xe2/Battlemage GPU; the equality-based debug assertion that should have caught this only compiles in with CONFIG_DRM_XE_DEBUG.

The Linux kernel's page allocator free path (free_pages_nolock()) performs an unsafe spin_trylock() when running in NMI context on uniprocessor (non-SMP) kernel builds; a prior fix (commit 620b46ed6ae17) addressed the allocation side but missed the free side. The flaw is triggered when BPF programs that use these page-allocation/freeing features in NMI context — most plausibly BPF tracing programs — run on a non-SMP kernel. A local attacker who can load such BPF programs could crash the kernel, and the reporter assesses it is probably exploitable for local privilege escalation. Only non-SMP/UP kernel builds are affected, and the patch author states the bugs were found by code review, have not been reproduced, and that no real-world user is suspected to be affected. No public proof-of-concept is known, the issue is not in CISA KEV, and there are no reports of exploitation in the wild.

Do: Apply the upstream mm/page_alloc fix from the 'fixes for free_pages_nolock() on RT/UP' patch series (patch 1 of 2) once it lands in mainline and stable trees for your kernel version. Operators of non-SMP/UP kernels (embedded, IoT, minimal single-vCPU systems) should audit whether BPF programs using NMI-context tracing/allocation features are loaded and restrict unprivileged BPF if so. SMP kernel builds are not affected.

The Linux kernel's USB gadget functionfs (ffs) driver stores a raw pointer to the submitting task's mm_struct for asynchronous I/O without holding a reference while requests are pending. A local user who queues async read requests through functionfs and then exits before completion handling finishes can trigger a use-after-free on the freed mm_struct. An attacker with low local privileges could potentially corrupt kernel memory to escalate privileges, read or write sensitive memory, or crash the system, consistent with the CVSS 3.1 score of 7.8 (AV:L/PR:L with high confidentiality, integrity, and availability impact). Any system running an affected kernel with the functionfs gadget in use is affected — a configuration common on Android devices (which use f_fs for ADB) and embedded/USB-peripheral deployments, but rare on typical servers and desktops. There is no public proof-of-concept, the issue is not in the CISA KEV catalog, and no in-the-wild exploitation is known.

Do: Upgrade to a kernel release that includes the upstream fix, which takes an mmgrab() reference when queuing the ffs read request and drops it with mmdrop() on completion; since exact fixed version numbers are not provided in the data, track the stable branch containing this ffs patch. If the system does not need USB gadget/functionfs functionality, disable or unload the f_fs gadget module to eliminate the attack surface. Restrict local shell access on devices that do use functionfs (e.g., ADB-enabled Android builds) until patched.

A use-after-free exists in the Linux kernel's USB gadget FunctionFS driver (f_fs), in the ffs_epfile_write_iter() and ffs_epfile_read_iter() functions. When an AIO (asynchronous I/O) operation fails with an error other than -EIOCBQUEUED, the io_data structure is freed while the kiocb cancellation handler is still armed and still points to that freed memory; a concurrent sys_io_cancel() call in that window dereferences the freed pointer. A local attacker with low privileges and access to a FunctionFS endpoint can trigger this race, gaining kernel memory corruption with potential for privilege escalation, since the CVSS impact is rated high for confidentiality, integrity, and availability (7.8, local vector). Affected systems are primarily Linux kernels with the f_fs gadget driver enabled, a configuration most common on Android devices (adbd uses FunctionFS) and embedded Linux boards acting as USB devices. No public proof-of-concept or exploitation in the wild is known, and the issue is not listed in CISA's KEV catalog.

Do: Apply the upstream kernel patch (or a stable/vendor backport that un-arms the kiocb cancellation in the f_fs AIO error path); for Android, install vendor security updates that include this kernel fix. As mitigation, restrict read/write access to /dev/usb-ffs/* endpoint nodes to trusted processes and avoid running untrusted local code on affected devices. Check whether your kernel configuration enables CONFIG_USB_FUNCTIONFS and whether any components use AIO (io_submit/io_cancel) on FunctionFS endpoints.

The zram compressed-swap driver in the Linux kernel stores its per-slot lock as a bit inside a 64-bit word that doubles as two 32-bit fields (entry flags and last-access time). On 64-bit big-endian systems the lock bit lands in the access-time half of the word, so when access-time tracking (ZRAM_TRACK_ENTRY_ACTIME) is enabled, a normal access-time write from mark_slot_accessed() or slot_free() erases a held lock bit, letting another CPU acquire the same slot lock concurrently; conversely, an access-time value that happens to set that bit makes the slot appear locked forever. A local, low-privilege attacker could exploit the resulting race to corrupt zram slot state, and the CVSS vector indicates high potential impact on confidentiality, integrity, and availability, i.e., possible local privilege escalation or a persistent denial of service. Only systems running zram on 64-bit big-endian architectures (e.g., s390x, big-endian POWER, sparc64) with access-time tracking enabled are affected; little-endian platforms such as x86_64, ARM64, and Android are not. No public proof-of-concept or in-the-wild exploitation is known, and the issue is not in CISA's KEV catalog.

Do: Apply the upstream kernel commit that shifts the slot-lock bit into the flags half of the word on big-endian 64-bit, or install your vendor's backported kernel update once published (the source data names no fixed version, so track vendor advisories). As an interim mitigation on affected big-endian hosts, avoid zram or do not enable access-time tracking (ZRAM_TRACK_ENTRY_ACTIME/writeback tracking), which is what clobbers the lock bit. Prioritize patching multi-tenant s390x/POWER/sparc systems, since exploitation requires only local low privileges.

The Ceph filesystem client in the Linux kernel allocates message buffers with kvmalloc(), which can fall back to vmalloc() memory when fragmentation prevents a large contiguous allocation, but ceph_fname_to_usr() passed these raw MDS reply buffers to the fscrypt scatterlist crypto API, which only accepts linear-mapping addresses. When a readdir/metadata reply from the Ceph metadata server lands in a vmalloc() buffer on a CephFS mount with filename encryption enabled, the kernel hits an invalid address and oopses; the reporter's testing hit this on roughly 1 in 8,000 readdir messages, with crashes most likely on non-x86 architectures. An attacker who controls or can spoof the Ceph metadata server, or can intercept client-cluster traffic, can therefore trigger kernel crashes — a denial of service; despite the CNA's 9.8 network-vector score, the advisory describes oopses rather than demonstrated code execution or data theft. Only Linux systems using the kernel CephFS client with fs-encryption (encrypted filenames) are affected. No in-the-wild exploitation or public PoC is known, although the fix commit references a reproducer, and the fix routes vmalloc() addresses through a linear bounce buffer.

Do: Update Linux systems that mount CephFS with encryption to a kernel containing the 'ceph: properly decrypt filenames in vmalloc() buffers' commit (latest mainline/stable, or your vendor's backport once released). As an interim mitigation, disable filename encryption on CephFS mounts and restrict which hosts can reach or impersonate the Ceph monitors/MDS, since a malicious or on-path metadata server is required to trigger the flaw. Audit your fleet for CephFS mounts using fscrypt to confirm whether you are in the affected population.

CVE-2026-90041 is a use-after-free in the Linux kernel's HID 'sony' driver (drivers/hid/hid-sony.c) caused by incorrect cleanup when controller probing fails. When a Sony controller is connected, sony_input_configured() links its state into sony_device_list before the input device is registered; if input_register_device() then fails, sony_probe() frees the driver state (via devres) while the list node is still linked, leaving a dangling entry in the shared device list. A subsequent controller connection that traverses the list touches freed memory, which could be leveraged for memory corruption or a crash by an attacker with local/adjacent access — such as plugging in or pairing over USB/Bluetooth a crafted or malfunctioning Sony-class HID device — consistent with the CVSS 8.8 (high, adjacent network, C:H/I:H/A:H) score. Any Linux system whose kernel includes the sony HID driver is affected, though the advisory does not specify vulnerable or fixed version ranges. No public proof-of-concept and no known in-the-wild exploitation; the flaw was found by 0sec using automated source analysis.

Do: Update to a kernel that includes the sony driver probe-failure cleanup patch as soon as your distribution ships it (mainline/stable backport; no fixed version number is given in the advisory). Until then, avoid attaching Sony DualShock-class controllers from untrusted sources to patched-pending systems, or blacklist the hid_sony module where Sony controllers are not needed (verify with 'lsmod | grep hid_sony').

In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped Wire up a gmem_invalidate_range() call for SNP VMs, and use it to force vCPUs to reload/recheck their guest-provided VMSA if the backing gmem page is being invalidated, e.g. is being PUNCH_HOLE'd. Use the same core logic to handle invalidations as VMX does for the APIC-access page, as the two concepts are nearly identical: shove the physical address of a page into the vCPU's control structure: 1. Snapshot the invalidation sequence counter 2. Grab the pfn (from guest_memfd in this case) 3. Acquire mmu_lock for read 4. Re-request reload if retry is needed, otherwise commit the change. Note, the re-request action in #4 is necessary as KVM's retry logic is fuzzy, i.e. can get false positives. If the guest_memfd page has been dropped, at some point a subsequent reload will fail to get a PFN from guest_memfd, and KVM will fail KVM_RUN. If the retry was due to a false positive, KVM will retry until there are no relevant MMU notifier events (and will retry in the "outer" loop, i.e. will drop locks and resched as needed). Note #2! Take care to invalidate the VMSA when a relevant memslot is DELETED or MOVED, as invalidations in response to PUNCH_HOLE are predicated on memslot bindings (KVM doesn't know what GFN range(s) to invalidate without a binding). And more importantly, the VMSA mapping requires a memslot, i.e. must be invalidated if its memslots disappears, regardless of the state of the underlying guest_memfd inode. Failure to invalidate the vCPU's control.vmsa_pa (which is checked by pre_sev_run()) can prevent KVM from properly freeing the page as firmware will reject the RMPUPDATE to reclaim the page with FAIL_INUSE if the vCPU is actively running, i.e. if VMSA page is in-use. That in turn leads to an RMP #PF on the next use, as the page will still be assigned to the SNP VM. SEV-SNP: RMPUPDATE failed for PFN 78d198, pg_level: 1, ret: 3 SEV-SNP: PFN 0x78d198, RMP entry: [0xfff0000000144001 - 0x000000000000000f] CPU: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026 Call Trace: dump_stack_lvl+0x54/0x70 rmpupdate+0x12c/0x140 rmp_make_shared+0x3b/0x60 sev_gmem_invalidate+0xe0/0x170 [kvm_amd] delete_from_page_cache_batch+0x1d8/0x220 truncate_inode_pages_range+0x120/0x3d0 kvm_gmem_fallocate+0x19a/0x270 [kvm] vfs_fallocate+0x1bc/0x1f0 __x64_sys_fallocate+0x48/0x70 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x496c7e ------------[ cut here ]------------ SEV: Failed to update RMP entry for PFN 0x78d198 error -14 WARNING: arch/x86/kvm/svm/sev.c:5160 at sev_gmem_invalidate+0x126/0x170 [kvm_amd], CPU#3: sev_snp_vmsa_pu/31345 CPU: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026 RIP: 0010:sev_gmem_invalidate+0x12b/0x170 [kvm_amd] Call Trace: delete_from_page_cache_batch+0x1d8/0x220 truncate_inode_pages_range+0x120/0x3d0 kvm_gmem_fallocate+0x19a/0x270 [kvm] vfs_fallocate+0x1bc/0x1f0 __x64_sys_fallocate+0x48/0x70 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x496c7e irq event stamp: 20689 hardirqs last enabled at (20699): [ ] __console_unlock+0x5c/0x60 hardirqs last disabled at (20708): [ ] __console_unlock+0x41/0x60 softirqs last enabled at (20722): [ ] __irq_exit_rcu+0x7e/0x140 softirqs last disabled at (20717): [ ] __irq_exit_rcu+0x7e/0x140 ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: ffff99 ---truncated---

In the Linux kernel, the following vulnerability has been resolved: NFSD: Guard admin state-revocation walks with NFSD_NET_UP Writing to /proc/fs/nfsd/unlock_filesystem, or sending the NFSD_CMD_UNLOCK_FILESYSTEM or NFSD_CMD_UNLOCK_EXPORT netlink command, walks the NFSv4 client hash tables to revoke open state and cancel async COPY operations. All three handlers gate that walk on nn->nfsd_serv, but a listener added via portlist or netlink listener_set sets nn->nfsd_serv before any nfsd thread starts. nfsd_startup_net() has not yet allocated nn->conf_id_hashtbl, so the walkers dereference a NULL table. A local administrator with CAP_SYS_ADMIN can crash the kernel this way without ever starting the server. nn->nfsd_serv is set when the service is created, which precedes table allocation. NFSD_NET_UP instead brackets the window where the tables are live: set at the end of nfsd_startup_net() and cleared in nfsd_shutdown_net() after they are freed, both under nfsd_mutex. Gating the three unlock paths on NFSD_NET_UP fixes the startup-time NULL dereference while preserving the earlier post-shutdown use-after-free fix.

CVE-2026-90038 is a use-after-free in the Linux kernel's NFS server (NFSD): nfsd4_revoke_export_states() drops the shared client_lock across revoke_one_stid() and a subsequent read of clp->cl_minorversion, and the stateid reference it holds does not pin the client, so a concurrent client teardown can free the client while it is still being dereferenced. The flaw is reached when an administrator removes an NFS export — exportfs -u drives the path via the NFSD_CMD_UNLOCK_EXPORT netlink command — and that revocation races with a client expiry. Successful triggering yields a kernel use-after-free that can crash the server (denial of service) and, as is typical for kernel UAF bugs, may be exploitable for privilege escalation; the assigned CVSS 3.1 score is 9.8 critical (AV:N/AC:L/PR:N), although practical triggering requires the export-revocation path to race client expiry. Any Linux system acting as an NFS server with the export-state revocation code is affected. No public proof-of-concept is known, the issue is not in CISA KEV, and no in-the-wild exploitation has been reported.

Do: Apply the upstream patch 'NFSD: Prevent client use-after-free during export state revocation' and update to a kernel that includes the fix. As an interim mitigation, avoid removing exports (exportfs -u / NFSD_CMD_UNLOCK_EXPORT) while NFSv4 clients are active or expiring, and schedule export changes during maintenance windows. Check whether your running kernel contains the nfsd4_revoke_export_states()/UNLOCK_EXPORT code to determine if the issue is relevant to your systems.

A use-after-free flaw in the Linux kernel's NFS server daemon (NFSD) occurs when an open owner left on the close_lru list after its final CLOSE keeps its last closed stateid holding only a raw, unpinned pointer to its nfs4_client. When the NFSD laundromat thread reaps a timed-out entry it drops the client lock and calls nfs4_put_stid(), which dereferences the client through cl_lock; a concurrent force_expire_client() can free the client in that window, so the server reads freed kernel memory, and __destroy_client() hits the same race by walking cl_openowners without holding cl_lock. An attacker acting as an NFS client that opens/closes files and triggers or coincides with client expiry could corrupt server kernel memory, most plausibly crashing the server (denial of service) and potentially more, per the critical CVSS score. Any Linux system running the in-kernel NFSv4 server (NFSD) — enterprise file servers, virtualization storage hosts, and Linux-based NAS appliances — is potentially affected. No public proof-of-concept or in-the-wild exploitation is currently known.

Do: Upgrade to a kernel that includes the NFSD fix (pinning the client via cl_rpc_users before dropping client_lock) — since no fixed version is given in the advisory, follow your distribution's kernel security tracker for the backported update. Until patched, restrict NFS access (TCP/UDP 2049 and related ports) to trusted client networks with firewall rules and tight export ACLs, and avoid unnecessary forced client-expiry operations on production servers. Monitor servers for NFSD crashes, hung NFS clients, or kernel use-after-free/oops messages involving nfs4_put_stid or the laundromat thread.

CVE-2026-90036 is a use-after-free in the Linux kernel's NFS server (NFSD) state management: a 'bare' lock owner whose only remaining reference is a blocked lock on the blocked_locks LRU holds a raw pointer to its nfs4_client without keeping the client alive. When the per-net laundromat reaps such a blocked lock, freeing the lock owner can make nfs4_put_stateowner() dereference the client's cl_lock, and because the laundromat detaches the lock first, a concurrent force_expire_client() can free the client before that call, touching freed memory. Triggering it requires NFS clients performing blocked-lock (NLM) operations while client expiry runs concurrently, which an attacker able to mount exports could attempt remotely. A successful exploit corrupts kernel memory in the NFS state machinery, with potential for denial of service and, per the CVSS 9.8 score, high confidentiality/integrity/availability impact. Any Linux system acting as an NFS server is potentially affected; no public proof-of-concept or in-the-wild exploitation is currently known.

Do: Apply the upstream NFSD fix via your distribution's kernel update as soon as vendors ship it. In the meantime, restrict NFS access (TCP/UDP 2049) to trusted clients with firewall rules, avoid unauthenticated or broad exports, and check whether the NFS server service is enabled and whether any clients rely on blocked (NLM) locks. Not currently listed in CISA KEV and no public exploit is known.

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix division by zero in get_estimated_bw() get_estimated_bw() divides by link->dpia_bw_alloc_config.bw_granularity, which is zeroed by reset_bw_alloc_struct() and only populated once DP_TUNNELING_BW_ALLOC_CAP_CHANGED has been handled. link_dp_dpia_handle_bw_alloc_status(), the DPCD interrupt handler, calls get_estimated_bw() whenever DP_TUNNELING_ESTIMATED_BW_CHANGED is set, independently of whether DP_TUNNELING_BW_ALLOC_CAP_CHANGED has ever fired for that link. A connected USB4/DPIA tunneling device that reports an estimated-bandwidth change before ever reporting a capability change drives a division by zero in this IRQ path. link_dpia_send_bw_alloc_request() already guards the same bw_granularity division; add the identical guard here rather than introducing a new pattern. (cherry picked from commit f2a961457c33dc34223aad5c9e8971de34a4eed3)

In the Linux kernel, the following vulnerability has been resolved: usb: image: mdc800: change kmalloc() to kzalloc() Change the kmalloc() calls in usb_mdc800_init() for irq_urb_buffer and download_urb_buffer to kzalloc(), avoiding potential stack leaks if a shorter message is received in mdc800_usb_irq() and mdc800_usb_download_notify()

In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write in snd_usbmidi_us122l_output() The snd_usbmidi_us122l_output() picks a count of 2 on anything slower than high speed and never relates it to ep->max_transfer. The URB buffer holds exactly max_transfer bytes, so a device declaring a one byte bulk endpoint takes two bytes from snd_rawmidi_transmit(), and the memset that pads the rest computes 1 - 2 in int and wraps to SIZE_MAX. Only 0x800e and 0x800f are pinned to nine bytes. The US-122MKII at 0x0644:0x8021 falls to the default and takes usb_maxpacket(), which the USB core only clamps downward. The akai and novation output ops in this file were given the same guard recently. Do the same here.

A use-after-free flaw in the Linux kernel's usbtv driver, which handles USBTV007-class USB video capture dongles, can leave a freed driver structure referenced by an open ALSA PCM stream. If the USB device is disconnected while a PCM file is still open, the disconnect path drops the V4L2 device reference and frees struct usbtv, because usbtv_audio_free() uses snd_card_free_when_closed(); a later close of that PCM file then dereferences freed memory in snd_usbtv_pcm_close(). The fix takes a V4L2 device reference for the ALSA card and releases it from the card's private_free callback, keeping struct usbtv alive until ALSA has closed remaining files. A local attacker able to open the dongle's ALSA/V4L2 device nodes and trigger or race with a disconnect could crash the kernel or potentially achieve code execution with high confidentiality, integrity, and availability impact, consistent with the CVSS 7.8 local-attack vector. Only Linux systems with a kernel built with the usbtv driver and a supported capture dongle attached are affected, and no public proof-of-concept, known exploitation, or KEV listing exists.

Do: Update to a kernel that includes the commit 'media: usbtv: keep device alive while ALSA card exists' or apply your distribution's backported stable/kernel security update when released. Check whether you are exposed with 'lsmod | grep usbtv'; systems without a USBTV007-class dongle are not affected. As an interim mitigation, restrict access to the relevant /dev/snd and /dev/video device nodes to trusted local users and avoid unplugging the dongle while audio streams are open.

In the Linux kernel, the following vulnerability has been resolved: usb-storage: ene_ub6250: fix race between scan work and probe ene_ub6250_probe() calls usb_stor_probe2(), which starts the usb-storage infrastructure and schedules the delayed scan work. The driver then calls ene_get_card_type(), which sends an ENE command through ene_send_scsi_cmd() and the usb-storage bulk transfer helpers. Both the delayed scan work, through usb_stor_Bulk_max_lun(), and ene_get_card_type() use us->current_urb. The scan work serializes this access with us->dev_mutex, but the ENE card-type probe does not. If the scan work runs while ene_get_card_type() is still using us->current_urb, usb_submit_urb() warns that the URB is already active. Serialize ene_get_card_type() with us->dev_mutex, matching the locking used by the scan path.