The WP Import Export Lite WordPress plugin before 3.9.33 does not validate a user-supplied file path before reading it and copying it into a publicly accessible directory, allowing any user whose role an administrator has granted the WP Import Export Lite WordPress plugin before 3.9.33's import permission to disclose sensitive files from the server, including files located outside the web root. The same code path also relaxes the file-system permissions of any path it is given, whether or not the copy succeeds.
The WP Import Export Lite WordPress plugin before 3.9.33 does not validate a path taken from stored, user-supplied data before recursively deleting the directory it resolves to, allowing users to whom an administrator has delegated a WP Import Export Lite WordPress plugin before 3.9.33 capability to delete arbitrary directories, and every file within them, including outside the web root.
The WP Import Export Lite WordPress plugin before 3.9.33 does not validate the type, extension or content of files it retrieves from a user-supplied URL during import, allowing users granted its import permission to store arbitrary files, including executable ones, on the server and achieve remote code execution.
The WP Import Export Lite WordPress plugin before 3.9.33 does not restrict which PHP function may be applied to exported field values, allowing users granted its export permission to have arbitrary functions invoked on values they control, leading to remote code execution.
The WP Import Export Lite WordPress plugin before 3.9.34 does not validate a user-supplied output path when writing export files, allowing users granted its export permission to write files with arbitrary names to arbitrary locations on the server, leading to remote code execution.
The MultiVendorX WordPress plugin before 5.0.16 does not verify that a user owns the store they are acting on in one of its REST API routes, allowing any authenticated user, such as a subscriber, to overwrite any store's details and payout settings and to replace the record of who owns it.
Session hijacking in the SSID bring-your-own-device (BYOD) onboarding workflow of Cisco Identity Services Engine (ISE) allows an unauthenticated, adjacent attacker to spoof a legitimate user mid-onboarding and take over that user's session, ultimately gaining access to protected 802.1X networks. The root cause is an authentication bypass by spoofing (CWE-290): insufficient authentication checks during onboarding let the attacker trigger a redirection to the guest web portal and bind their device to the victim's in-flight session. The CVSS vector (AV:A/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N, score 3.8) confirms no credentials are required but that the attacker must be on the same Layer-2 segment and a genuine user must be actively onboarding; this is a deliberately disabled-by-default optional NAC feature rather than a baseline ISE capability, so real-world exploitability is narrow. No public exploit code and no active exploitation have been identified at time of analysis, and no EPSS signal was provided with the source data.
Improper access controls in Tanium Threat Response let an authenticated, high-privilege operator (PR:H) reach a function that lacks an adequate authorization check, allowing them to read or modify data outside their assigned scope over the network without user interaction. The vendor addressed the flaw (tracked as TAN-2026-034) and the impact is limited - confidentiality and integrity are both rated Low and there is no availability impact - yielding a CVSS 3.1 base score of 3.8. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the high-privilege prerequisite plus narrow scope keep real-world risk low.
NLnet Labs Unbound 1.20.0 through 1.26.0 can be made to accumulate an unbounded number of pending recursive queries from a single source IP because a double decrement on the per-client 'wait-limit' counter occurs on the 'serve-expired' code path. A remote, unauthenticated attacker who controls an authoritative zone with short TTLs alternates a deliberately unanswered 'slow' query with a 'pump' query for an expired cached name, keeping the counter at or below the configured limit and eventually filling a thread's global mesh quota (num-queries-per-thread), thereby bypassing one of the countermeasures introduced for DNSBomb (CVE-2024-33655). Impact is availability-only and limited (CVSS 3.7, AC:H, A:L) and depends on the non-default 'serve-expired' feature; no public exploit has been identified at time of analysis.
Path traversal in junrar (the open source Java RAR archive library) prior to version 7.6.1 lets an attacker-supplied RAR archive cause LocalFolderExtractor to create directories outside the intended extraction root. The flaw exists because createFile() validates only the final canonical file path while makeFile() creates intermediate path segments with unchecked mkdir() calls, so a crafted entry whose final path resolves inside the destination can still spawn directories elsewhere - a specificity that is why the assessed vector carries AC:H. Impact is confined to directory creation and file-versus-directory squatting that can make later security-sensitive writes fail; there is no arbitrary file-content write and no confidentiality loss, unauthenticated remote attackers are the relevant threat model only when a host application extracts untrusted archives through this specific extractor, and no public exploit code has been identified at time of analysis. This is a genuinely low-priority issue, and the vendor's CVSS of 3.7 reflects that honestly rather than inflating it.
Prototype pollution in node-opcua-client versions prior to 2.145.0 lets an attacker who controls OPC UA event or condition field names corrupt Object.prototype through the internal fieldsToJson helper in packages/node-opcua-client/source/alarms_and_conditions/client_alarm.ts, which assigns unsanitized field names and permits a __proto__.pollutedKey assignment path. Only host applications that feed attacker-controlled event field names into that serialization helper are exposed; a malicious or compromised OPC UA server (or untrusted publisher) must supply the crafted field name AND the application must omit field-name sanitization, which is why the vendor rates attack complexity as high. There is no public exploit identified at time of analysis and no confirmed remote code execution - impact is bounded to denial of service or application logic corruption with no confidentiality exposure, making this a genuinely low-priority issue despite being a real prototype-pollution flaw. The issue is unauthenticated per the CVSS vector (PR:N) and is fixed in 2.145.0.
Credential disclosure in Jenkins Pipeline: Multibranch Plugin 841.vec5b_9e1806ec and earlier allows users who already hold Item/Configure permission to capture credentials they are not entitled to by authoring or modifying a Pipeline that invokes the resolveScm step, which fails to establish the correct context for credentials lookup. The issue is an access-control scoping flaw (CWE-863) rated CVSS 3.1 (AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N), reflecting the authenticated Item/Configure prerequisite, the high complexity of targeting specific credential IDs, and impact limited to confidentiality with no integrity or availability effect. It requires a Jenkins instance that actually uses Pipeline/multibranch jobs with resolveScm; at time of analysis there is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified, though the vendor advisory of 2026-09-16 should be reviewed for the fixed release.
A link-following (symlink) defect in the Dell Update Package (DUP) Framework before version 26.07.03 allows a locally authenticated high-privileged attacker to plant or control a symbolic link so that a privileged DUP file operation resolves to an attacker-chosen path, producing limited integrity and availability impact on the affected host. Exploitation is tightly constrained: the attack vector is local-only (CVSS:3.1/AV:L), requires high privileges (PR:H) plus the ability to create or control symlinks in a path consumed by a DUP operation, and depends on a race or predictable-path condition (AC:H), yielding a base score of 3.0 with I:L/A:L and C:N. No public exploit code was identified at time of analysis and there is no KEV confirmation of active exploitation; Dell has published a fixed version (26.07.03) via advisory DSA-2026-417. Note that the accompanying 'Information Disclosure' tag is not supported by the assessed vector, which shows no confidentiality impact, making this a low-priority local hardening issue rather than a data-exposure event.
Improper link resolution in the Dell Update Package (DUP) Framework before 26.07.03 allows an attacker who already holds high local privileges on a host to point framework file operations at a location of their choosing, resulting in unauthorized filesystem access with limited integrity and availability impact (CVSS 3.1 base score 3.0, AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:L). Because exploitation demands pre-existing high privilege, local access, the ability to plant a symbolic link in a path the framework touches, and a successful link-resolution race, this is a low-severity, hard-to-reach issue that cannot be triggered remotely or by an unprivileged user. There is no public exploit identified at time of analysis, no CISA KEV listing, and a vendor patch is available as version 26.07.03.
Arista EOS devices configured with SNMPv3 users store the one-way hashed, localized SNMPv3 authentication key inside the running configuration and, notably, inside sanitized configuration exports, so any authenticated user who can read either artifact obtains reusable credential material for that device's SNMP engine. With that material an attacker can issue unauthorized SNMP read operations against MIB tables or inject fraudulent trap notifications into the Network Management System, though there is no configuration-write or availability impact. The vendor discovered the flaw internally, states it is unaware of malicious exploitation in customer networks, and no public exploit code has been identified at time of analysis; the CVSS 3.1 base score is 4.2 (AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N), with exploitation gated on SNMPv3 being in use and on the attacker already holding authenticated device access or a leaked sanitized configuration.
Incorrect authorization results in Arista EOS gNMI (gRPC Network Management Interface) can allow an already-authenticated management user to reach resources and operations slightly beyond the permissions assigned to their role. Per the assessed vector (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N, score 4.2), exploitation requires the gNMI interface to be enabled and reachable plus a valid account with at least some gNMI access, and success depends on specific role/permission configurations - a high-complexity, low-impact condition rather than a remote unauthenticated bypass. There is no public exploit identified at time of analysis, no CISA KEV listing, and Arista states the issue was found internally with no known malicious use in customer networks.
Apache NiFi 2.11.0 does not evaluate Process Group authorization when listing or submitting version-controlled Process Group migrations into a Connector, so an authenticated user holding only Connector-level permissions can reach flows they were never granted policy access to. Read access to a Connector is sufficient to enumerate the identifiers, names, and flow registry details of version-controlled Process Groups outside the user's read policies, while write access to a Connector allows migrating such a group - copying its flow definition, referenced assets, and component state into the Connector and leaving the source group disabled and renamed. Only installations that configure component-level authorization policies for Process Groups are affected, sensitive property values are excluded from migration, and the source group must already be stopped with empty queues; no public exploit code identified at time of analysis and the assessed impact is low (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N).
A permissive cross-origin resource sharing (CORS) misconfiguration in the AG-UI aws-strands Python integration (ag-ui 0.3.0) allows a remote, unauthenticated attacker who convinces a victim to load an attacker-controlled web page to issue cross-origin requests against a deployed agent endpoint and read limited response data. The flaw is confined to deployments that bootstrap a FastAPI app via create_strands_app in integrations/aws-strands/python/src/ag_ui_strands/utils.py, where the helper installs wildcard CORS (any origin, method, and header) and mounts the agent route with no authentication dependency; deployments that supply an explicit origins allowlist, set cors_enabled=False, or attach an auth dependency are not affected. Exploitation is rated high complexity and difficult (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N, CVSS 4.0 base 2.3), the impact is limited to low confidentiality loss with no integrity or availability effect, and the browser prohibition on combining wildcard origins with credentialed requests further constrains what a successful attack can expose. No confirmed active exploitation (no CISA KEV listing) and no public exploit code were identified at time of analysis, and no EPSS score was provided in the source data.
Cleartext disclosure of peer VRRP authentication credentials in Arista EOS log output allows an authenticated, privileged user - or anyone able to read a system receiving forwarded agent trace logs - to recover the shared secret that authenticates VRRP advertisements, without needing any presence on the VRRP network segment itself. The defect applies to EOS platforms configured with authenticated VRRP; exploitation requires high-privilege access to the switch's agent trace logs or to a downstream log collector, and the resulting impact is confidentiality-only (CVSS 4.0 base 2.1; our independent assessment rates it CVSS 3.1 AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N, i.e. PR:H and C:L). No public exploit code and no confirmed active exploitation were identified at time of analysis; this is a low-priority log-hygiene issue whose only notable edge over routine secret-in-log bugs is that the leak escapes the on-link boundary normally assumed for VRRP secrets.
Concrete CMS 9.2.0 through 9.5.3 fails to enforce an authorization check on its REST API user-creation endpoint (POST /ccm/api/1.0/users), so any request bearing a valid OAuth token that carries the users:add scope - including a client_credentials token with no associated user context - can create active, validated accounts while bypassing email verification and administrator approval. The endpoint's add() method in concrete/src/Api/Controller/Users.php performs no permission verification, making this a classic missing-authorization weakness (CWE-862) that an authenticated API consumer can abuse to gain a foothold. Under default registration settings the newly minted accounts are allowed to edit page content, which provides an escalation path to stored cross-site scripting and further compromise of the CMS. No public exploit code or confirmed active exploitation (CISA KEV) was identified at time of analysis, and the reporter-independent assessment rates the impact as limited to low integrity loss on the CMS itself.
OpenTelemetry-Go versions 1.5.0 through 1.44.0 can write sensitive collector configuration into an application's own logs when the application explicitly opts into internal diagnostic logging through otel.SetLogger at Info verbosity: the TracerProvider created event serializes span processor, exporter, and client configuration, exposing OTLP gRPC and HTTP collector endpoints, the OTLP HTTP Insecure flag, and complete Zipkin collector URLs. Anyone able to read those logs - local files, aggregated log stores, or a SIEM - can reconstruct internal collector topology and can recover credentials or tokens where operators embedded them in Zipkin URL user-info or query strings. The vendor CVSS 4.0 base score is 2.0 and no public exploit identified at time of analysis; note that OTLP authentication headers, TLS key material, and span payloads are never written by this path, and default OpenTelemetry configurations that do not install a logger are unaffected because the default logger does not emit the diagnostic event.
Deactivated, deleted, or password-reset-locked Concrete CMS accounts keep working API access via any bearer token issued to them before the account state change, letting the holder continue calling the OAuth REST API endpoints under /ccm/api/1.0/* until that already-issued token expires on its own. All Concrete CMS versions before 9.5.4 are affected when the OAuth REST API is enabled; the vendor rates this only 2.0 (CVSS v4.0) and our independent assessment aligns with a low-impact, high-complexity authenticated issue, with no public exploit identified at time of analysis. The flaw is time-limited to the residual lifetime of the token and grants no more access than that token originally had, so it is a stale-credential/session-expiration problem rather than a route to new privileges.
Missing authorization in Apache NiFi 2.9.0 through 2.11.0 allows an authenticated user who already holds write privileges on a Connector to apply Secret and Asset references through the Connector configuration UPDATE and VERIFY REST API methods without the framework verifying that the user may read the backing Parameter Provider or that the Asset actually belongs to the Connector being configured. The result is limited confidentiality and integrity exposure: a user can surface Secret values backed by a Parameter Provider outside their read scope and can bind foreign Asset identifiers to a Connector, consistent with the assessed CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N vector. Impact is confined to installations that deliberately implement different authorization levels across Connectors and Parameter Providers - the vendor states that deployments treating uniform Connector-write permission as the security boundary are not affected; there is no public exploit identified at time of analysis and no CISA KEV listing, which together with the tiered-configuration precondition makes this a low-priority authorization defect.
A remote attacker who controls a container registry may be able to direct a client's token request to a host of the attacker's choice, and disclose the victim's registry credentials to that host. This vulnerability is addressed in containerization version 0.41.0.
Sentry Seer is vulnerable to a multi-stage trust-boundary violation that allows unauthenticated attacker-controlled telemetry to become code that is executed by an agent in a privileged automation environment. An external attacker can submit fabricated Sentry events without having access to the victim’s Sentry account, source repository, or infrastructure.
Apache MyFaces, the JSF/Jakarta Faces implementation used by many Java web applications, is affected by a combined server-side request forgery and local file inclusion flaw: an attacker who can reach an application's normal HTTP interface can coerce the server into fetching attacker-chosen URLs or reading files that reside on the application host, giving high confidentiality impact with no integrity or availability impact (assessed CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, indicating no privileges and no user interaction are needed). The specific vulnerable versions, the feature or parameter that reaches the resource-loading path, and whether a non-default configuration or ProjectStage setting is required could not be confirmed, because the only supplied reference - the oss-security advisory at seclists.org/oss-sec/2026/q3/810 - did not render its body in the available data, leaving no CVSS vector, CWE identifier, CPE string, or fix version in the input. No public exploit code, EPSS score, or CISA KEV entry was available at time of analysis, so no public exploit is identified at time of analysis.
Remote, unauthenticated denial of service in Apache MyFaces allows any network-reachable attacker to exhaust server resources by submitting request parameters that the framework parses without bounds, degrading or halting the hosting JSF application. All supported release lines are affected in their earlier patch levels: 2.2.0 through 2.2.15, 2.3.0 through 2.3.11, 3.0.0 through 3.0.3, 4.0.0 through 4.0.3, 4.1.0 through 4.1.3, and the 2.3-next development branch, with older unsupported versions possibly affected as well. Per the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) there is no authentication or user interaction prerequisite, and impact is confined to availability with no confidentiality or integrity loss; there is no public exploit identified at time of analysis and no CISA KEV listing. Fixed releases are already published (2.3.12, 2.3-next-M9, 3.0.4, 4.0.4, and 4.1.4), so exposure is a straightforward patch-management problem rather than an unresolved zero-day.
Memory-exhaustion denial of service in Apache NiFi 2.11.0 allows unauthenticated remote attackers to force the server to decompress gzip-encoded HTTP request bodies through the application REST API, potentially exhausting heap and degrading or halting the service. The release nominally disabled gzip request decompression via a framework enforcement filter, but that filter fails to inspect multiple Content-Encoding header instances and fails to reject non-standard or mixed-case gzip identifiers, so crafted requests slip through and are decompressed anyway. Only the single 2.11.0 release is affected according to the independent assessment; exploit code is not publicly identified at time of analysis and there is no confirmed active exploitation (no CISA KEV listing). Impact is limited to availability (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) - this is not a code-execution or data-exposure flaw.
Jenkins Script Security Plugin 1415.v9a_f9b_3a_c253d and earlier does not reject @Builder annotations whose builderStrategy member names an arbitrary class, allowing attackers with permission to define and run sandboxed scripts, including Pipelines, to execute code outside the sandbox if a suitable class is present on the classpath of the component that evaluates the script.
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: <TASK> 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 </TASK> ------------[ 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: <TASK> 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 </TASK> irq event stamp: 20689 hardirqs last enabled at (20699): [<ffffffff8e76092c>] __console_unlock+0x5c/0x60 hardirqs last disabled at (20708): [<ffffffff8e760911>] __console_unlock+0x41/0x60 softirqs last enabled at (20722): [<ffffffff8e6cd74e>] __irq_exit_rcu+0x7e/0x140 softirqs last disabled at (20717): [<ffffffff8e6cd74e>] __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.
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.
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.
In the Linux kernel, the following vulnerability has been resolved: usb: storage: realtek_cr: fix use-after-free on disconnect realtek_cr_destructor() calls timer_delete() before the chip containing the timer is freed. The timer callback may still be running and can rearm itself, resulting in a use-after-free. Use timer_shutdown_sync() to wait for the callback and prevent further rearming. Do this unconditionally because ss_en may be changed after the timer is armed. Move timer_setup() into init_realtek_cr() so the timer is initialized before any failure path can invoke the destructor. Found by static analysis.
In the Linux kernel, the following vulnerability has been resolved: usb: typec: hd3ss3220: track VBUS enable state per consumer regulator_is_enabled() reports the aggregate regulator state, not whether this consumer holds an enable reference. If another consumer enables VBUS first, the driver can skip its own regulator_enable() call and later attempt to drop a reference it never acquired, triggering an unbalanced regulator disable warning. Track successful enable and disable calls locally. Keep the state unchanged when an operation fails so a later role or ID notification retries the operation while this consumer keeps balanced references.
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: midi2: Fix null-pointer dereference in f_midi2_free_ep_reqs A null-pointer dereference occurs in f_midi2_free_ep_reqs() when attempting to clean up an endpoint that was never initialized. When configuring the MIDI 2.0 gadget via configfs and setting the block direction to SNDRV_UMP_DIR_INPUT, the initialization of the midi1_ep_out endpoint is explicitly skipped during the gadget bind phase (f_midi2_bind()). As a result, the usb_ep->card field remains NULL. Later, when the host sets the alternate setting, f_midi2_set_alt() unconditionally stops both the IN and OUT endpoints by calling f_midi2_stop_eps(), which in turn calls f_midi2_free_ep_reqs() for both endpoints. When f_midi2_free_ep_reqs() is called for the uninitialized midi1_ep_out, it attempts to dereference usb_ep->card to determine the number of requests to free, leading to a crash. Fix this by using usb_ep->num_reqs instead of usb_ep->card->info.num_reqs in f_midi2_free_ep_reqs(). usb_ep->num_reqs is correctly set during f_midi2_init_ep() and remains 0 if the endpoint was never initialized, safely avoiding the loop. For consistency, apply the same change to f_midi2_alloc_ep_reqs(). Oops: general protection fault, probably for non-canonical address 0xdffffc00000000ee: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000770-0x0000000000000777] ... RIP: 0010:f_midi2_free_ep_reqs drivers/usb/gadget/function/f_midi2.c:1166 [inline] RIP: 0010:f_midi2_stop_eps+0x28e/0x4d0 drivers/usb/gadget/function/f_midi2.c:1246 ... Call Trace: <TASK> f_midi2_set_alt+0x11c/0xf00 drivers/usb/gadget/function/f_midi2.c:1296 composite_setup+0x1ffd/0x3480 drivers/usb/gadget/composite.c:1933 configfs_composite_setup+0xbd/0x100 drivers/usb/gadget/configfs.c:1877
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_mass_storage: fix null pointer dereference in fsg_common_set_num_buffers() Previously fsg_num_buffers_validate() was removed as it was not necessary due to Kconfig setting the limits for n from 2 to 256 with default as 2. However, setting the page content in such a way that kstrtou8() reflects n value as either 0 or 1 bypasses these restrictions leading to a null pointer dereference if n is 0. Fix this by adding a check for n < 2 and returning -EINVAL if n is either 0 or 1 consistent with Kconfig logic.
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: initialize work in f_midi_alloc() f_midi_alloc initializes free_ref to 1 and it can only be incremented when a sound card is registered via f_midi_register_card(). f_midi_register_card() is only called in f_midi_bind() which actually performs INIT_WORK. If f_midi_bind() is never run, work is not initialized and the if condition in f_midi_free becomes true, this results in a warning later in __flush_work as work->func = 0. Fix this by moving INIT_WORK from f_midi_bind() to f_midi_alloc().
In the Linux kernel, the following vulnerability has been resolved: USB: gadget: fix NULL pointer dereference in gadget_dev_ioctl() gadget_dev_ioctl() reads dev->gadget before acquiring dev->lock, but dev->state is checked after acquiring the lock. Therefore a concurrent bind can change the device state between these operations, which can leave ioctl with a stale NULL gadget pointer and causing a NULL pointer dereference at gadget->ops->ioctl. Read dev->gadget while holding dev->lock so that the gadget pointer and device state are sampled consistently.
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: fix null pointer dereference in usb_put_function_instance() usb_put_function_instance() attempts to dereference fd inside fi struct to get mod in uvc_alloc_inst() error path. However, fd is not allocated until later in try_get_usb_function_instance() after allocating fi in uvc_alloc_inst() and thus guranteed to be null in error path. Fix this by adding a null check for fi->fd that returns if fd is null.
In the Linux kernel, the following vulnerability has been resolved: xhci: fix lost bounce buffers on TDs spanning several ring segments When a TD reaches a link TRB with data that is not aligned to the endpoint's wMaxPacketSize, xhci_align_td() stages the unalignable tail through the bounce buffer of the ring segment holding that link TRB. xhci_unmap_td_bounce_buffer() later unmaps it and, for IN transfers, copies the data back into the URB's buffer. The enqueue path records the segment that was bounced in td->bounce_seg, under the assumption that a TD never spans more than two ring segments. That assumption does not hold: a TD large enough to span three or more segments crosses several link TRBs and can be bounced at each of them. Only the last one survives in td->bounce_seg, so every earlier bounce buffer is neither copied back nor DMA unmapped. The URB still completes with actual_length equal to the requested length and no error, so the transfer looks successful while a wMaxPacketSize sized hole in the destination buffer silently keeps its previous contents. It also leaks a DMA mapping per dropped bounce. Any sufficiently large and fragmented bulk transfer can hit this. It was found with a USB mass storage device behind xHCI backing a dm-verity target with 512 byte hash blocks, where the stale data is detected rather than silently consumed. The device enumerates as SuperSpeed, so wMaxPacketSize is 1024, while dm-bufio issues one 512 byte bio per hash block. verity_prefetch_io() makes the block layer merge hundreds of them into a single request of up to 512 scatterlist entries of 512 bytes each. At 256 TRBs per ring segment such a TD spans three segments, and every segment boundary falls on an odd multiple of 512, i.e. unaligned to wMaxPacketSize. dm-bufio then caches a hash block holding stale data and dm-verity declares the metadata block corrupted: device-mapper: verity: 8:2: metadata block 10850 is corrupted A reproducer running this under qemu is available at https://github.com/baloo/xhci-verity The bounce state (bounce_buf, bounce_dma, bounce_len, bounce_offs) already lives on the ring segment, so there is nothing extra to track. Keep recording the last bounced segment in td->bounce_seg and, on completion, walk the segments from td->start_seg up to it, unmapping every segment that still has a pending bounce. Stopping at td->bounce_seg rather than td->end_seg matters: a bounce implies the TD continues past that segment's link TRB, so bounce_seg is always strictly before end_seg, and a later TD may already have started in end_seg and been bounced there. Walking that far would copy a foreign bounce buffer into this URB and unmap it twice. It also keeps the walk correct if a TD ever wraps the whole ring so that end_seg == start_seg. [mn: Add ring->num_segs check to prevent unlikely infinite for loop.]
In the Linux kernel, the following vulnerability has been resolved: samples/damon/mtier: handle damon_stop() failure damon_sample_mtier_stop() assumes its damon_stop() call will always successfully stops the two DAMON contexts. Hence it deallocates the two DAMON contexts after the damon_stop() call. However, if a given context is already stopped, damon_stop() fails and returns an error while letting the DAMON contexts that have not yet stopped keep running. This kind of unexpected early DAMON context stops could happen due to memory allocation failures in kdamond_fn(). Because damon_sample_mtier_stop() just deallocates all DAMON contexts with damon_target and damon_region objects that are linked to the contexts, the execution of the unstopped DAMON context (kdamond) ends up using the memory that freed (use-after-free). Fix the issue by separating the damon_stop() to be invoked per context. Note that DAMON_SYSFS also allows multiple DAMON contexts execution. But, it calls damon_stop() for each context one by one. Hence this issue is only in mtier. For the long term, it would be better to refactor damon_stop() to always ensure stopping all contexts regardless of the failures in the middle. Make this fix in the current way, though, to keep it simple and easy to backport. I will do the refactoring later. The issue was discovered [1] by Sashiko.
In the Linux kernel, the following vulnerability has been resolved: samples/damon/wsse: handle damon_start() failure Patch series "samples/damon: handle damon_{start,stop}() failures". All DAMON sample modules are not correctly handling failures from damon_start(). Among those, mtier also has an additional problem for handling of damon_stop() failures. wsse and prcl also have a problem in their damon_call() failure handling. As a result, memory leaks, next DAMON operation disruptions, and use-after-free can happen. Fix those. Note that only the damon_start() failure caused issues can reliably be reproduced. Reproducing those issues require the admin permission, though. This patch (of 6): damon_sample_wsse_start() callers assume it will clean up resources when it fails. And the function does the cleanup for context buildup failures. However, it is not doing the cleanup for damon_start() failure. As a result, when damon_start() fails, it leaks the memory for DAMON context. Free the context in case of the failure to fix the issues. Note that the issue can reliably be reproduced because the module calls damon_start() in the exclusive mode. For example, $ sudo damo start $ echo $$ | sudo tee /sys/module/damon_sample_wsse/parameters/target_pid $ echo Y | sudo tee /sys/module/damon_sample_wsse/parameters/enabled $ sudo cat /proc/allocinfo | grep damon_new_ctx Because the first command is running another DAMON instance, the third command fails the damon_start() call because the new DAMON instance cannot exclusively run. And without this fix, by repeating the third and the fourth commands above, we can show the memory consumption is only increasing due to the leaks. It requires the sudo permission though. The issue was discovered [1] by Sashiko.
In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: handle region split failure in apply_min_nr_regions() damon_apply_min_nr_regions() repeatedly split each region until its size becomes small enough to meet the user-defined low limit of the number of regions. The loop assumes the split operation (damon_split_region_at()) will always succeed and create the new region. But the operation could silently fail for memory allocation failures, for example. If such failure happens and the region was the last region, the linked list-based next region fetching returns invalid pointer. As a result, invalid memory dereference and corruption could happen. Even if the corner case is handled, it imposes stress to the allocator by trying split regions for other targets. Fix the issue by breaking all the loops for any region split failure. This means there could be a min_nr_regions violation. It will only rarely happen since the allocation is arguably too small to fail. Even if it happens, it is only temporal. damon_apply_min_nr_regions() will be called again after the aggregation interval. The user impact of the issue should be minor, since the allocation is arguably too small to fail. But, it could still theoretically happen, and the consequence is very bad. This issue was discovered [1] by Sashiko.
In the Linux kernel, the following vulnerability has been resolved: dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds DMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd into the caller's fd table via dma_buf_fd() -> fd_install() before dma_heap_ioctl() copies the result back to userspace. If the trailing copy_to_user() fails, userspace never learns the fd number, but the fd (and the underlying dma-buf reference) are already visible to other threads in the same process and are leaked for the lifetime of the process. The obvious "close it on the failure path" fix is unsafe: once fd_install() has run, another thread can already dup() the fd, send it via SCM_RIGHTS, or close() it and let its number be reused, so a subsequent close_fd() from the ioctl path can operate on an unrelated file. This was pointed out by Christian König on v1 [1]. Restructure the allocation path so that fd_install() is the last, unfailable step of a successful ioctl: 1. heap->ops->allocate() creates the dma_buf. 2. get_unused_fd_flags() reserves an fd number in the caller's fd table without publishing it, so no other thread can observe it. 3. copy_to_user() delivers the fd number to userspace; on failure the fd is returned with put_unused_fd() and the dma_buf reference is dropped with dma_buf_put(), leaving no user- visible state behind. 4. dma_buf_fd_install() publishes the fd and emits the trace_dma_buf_fd tracepoint -- from here on the ioctl cannot fail. A new dma_buf_fd_install() helper is introduced in dma-buf.c to wrap fd_install() together with the DMA_BUF_TRACE() call, preserving the export tracing that dma_buf_fd() provides. dma_heap_ioctl_allocate() is refactored to return the struct dma_buf * directly (returning ERR_PTR on failure) so the caller holds the dmabuf reference across steps 3 and 4. The failure at step 3 is easily reachable from userspace: pass a struct dma_heap_allocation_data that lives in a page whose protection is flipped to PROT_READ between copy_from_user() and copy_to_user() (e.g. via mprotect()). Before this change each such ioctl leaks one dmabuf fd; after it, the fd table is unchanged on failure and only /dev/dma_heap/<name> remains open. No UAPI or heap-driver interface change. [1] https://lore.kernel.org/dri-devel/175e98de-f414-47d7-81c1-c0fe0a8f7f62@amd.com/
In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: Initialize IRQ data before requesting IRQs dw_edma_irq_request() passes struct dw_edma_irq to request_irq() before dw_edma_channel_setup() fills the back pointer. A shared interrupt can therefore enter the handler with dw_irq->dw still NULL, leading to a NULL pointer dereference. Set the back pointer before installing each handler.
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix infinite loop in pcpu_freelist push with one possible CPU __pcpu_freelist_push() can loop forever when only one CPU is possible and an NMI re-enters pcpu_freelist_push() while the interrupted context holds that CPU's freelist lock. After the current-CPU fast path fails, the fallback loop walks cpu_possible_mask while skipping the current CPU. With CONFIG_SMP=n, or when an SMP kernel is limited to one possible CPU with nr_cpus=1 or possible_cpus=1, there are no other possible CPUs to examine. The loop therefore makes no lock acquisition attempt and can never make progress. The following stack was observed on a UP system: NMI context: pcpu_freelist_push free_htab_elem htab_map_delete_elem [perf-event BPF program] __perf_event_overflow perf_event_nmi_handler exc_nmi Interrupted context: __pcpu_freelist_push pcpu_freelist_push free_htab_elem htab_map_delete_elem [raw_tp/sys_enter BPF program] __bpf_trace_sys_enter do_syscall_64 raw_res_spin_lock() detects the same-CPU recursive acquisition and returns -EDEADLK, but the subsequent fallback loop has no candidate head on a system with one possible CPU. Restore the extra fallback head that existed before the rqspinlock conversion. Keep the current-CPU fast path, then try the other possible CPUs and finally the extra head. The additional head lets a push, which cannot fail without losing a preallocated element, make progress when the only per-CPU head is held by the interrupted context. Also check the extra head from the pop path so that nodes placed there can be reused.
In the Linux kernel, the following vulnerability has been resolved: ima: Check for ERR_PTR from dentry_path() in validate_hash_algo() dentry_path() returns ERR_PTR(-ENAMETOOLONG) when the path exceeds the buffer. validate_hash_algo() passes the result straight to integrity_audit_msg() without checking. ERR_PTR is not NULL, so integrity_audit_message() sees a valid pointer and calls strlen() on it, which faults: BUG: unable to handle page fault for address: ffffffffffffffdc RIP: 0010:strlen+0x30/0xa0 Call Trace: audit_log_untrustedstring+0x19/0x30 integrity_audit_message+0x366/0x4f0 ima_inode_setxattr+0x512/0x5f0 Check for IS_ERR() and use NULL instead, which makes the audit message skip the name= field instead of crashing.