Race condition in the Browser component of Google Chrome prior to 153.0.8010.36 allows a remote unauthenticated attacker to bypass system access restrictions by inducing a victim to visit a crafted HTML page. The CVSS vector (AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L) reflects limited, non-scope-changing impact - this is not a sandbox escape but a partial access-control bypass within the Browser process. EPSS at 0.20% (10th percentile), Chromium's own 'Medium' severity rating, and the absence of KEV listing or public exploit code all converge on low near-term exploitation risk.
UI spoofing via a confused deputy flaw in Google Chrome's Fullscreen API (all versions prior to 153.0.8010.36) enables a remote attacker who has already compromised the renderer process to impersonate browser-trusted UI elements using a crafted HTML page and social engineering. This is a secondary exploitation step - it does not provide initial access - and becomes relevant only after a separate, higher-severity renderer compromise has been achieved. No public exploit code or CISA KEV listing exists; EPSS of 0.17% (6th percentile) reflects very low automated exploitation probability consistent with the chained, human-dependent attack path.
Chrome's Downloads subsystem in versions prior to 153.0.8010.36 contains an incorrect authorization check (CWE-863) that allows an attacker who has already compromised the renderer process to spoof download-related UI elements via a crafted HTML page. This vulnerability is a post-renderer-compromise chaining primitive - it cannot be exploited independently and must be paired with a separate renderer exploit. Chromium rates this 'Medium' and the CVSS score of 4.2 aligns with that assessment; EPSS at 0.17% (6th percentile) and absence from CISA KEV confirm low real-world exploitation probability.
UI spoofing in the Passwords component of Google Chrome on Android (versions prior to 153.0.8010.36) enables an attacker who has already compromised the renderer process to display falsified password-manager interface elements via a crafted HTML page. Exploitation is constrained by a hard prerequisite - a separate renderer compromise must precede this attack - and requires user interaction with the malicious page. No public exploit code exists and EPSS sits at 0.16% (6th percentile), in line with Chromium's own 'Low' severity classification.
Clickjacking via TrustedWebActivities (TWA) in Google Chrome on Android prior to 153.0.8010.36 allows a local attacker with a co-installed malicious app to spoof the browser address bar, enabling deceptive phishing scenarios where the user believes they are on a trusted domain. The attack leverages CWE-1021 (UI layer redressing) in Chrome's TWA feature, which is designed to let Android apps surface web content with reduced browser chrome. No public exploit code has been identified and EPSS sits at 0.18% (8th percentile), consistent with the local-access requirement and high attack complexity. Google has released the fix in the stable channel update to 153.0.8010.36.
Out-of-bounds memory read in the stb library's stbsp_vsnprintf function (stb_sprintf.h) at commit 31c1ad3 enables a denial-of-service condition when a consuming application passes attacker-controlled input to the function. The nothings/stb project is Sean Barrett's widely-vendored, public-domain, single-file C library suite embedded across game engines, imaging tools, and embedded systems. No public exploit code and no CISA KEV listing exist at time of analysis; the local attack vector and high attack complexity in the CVSS vector further limit practical exploitability.
Permission control weakness in the HarmonyOS window module allows a local attacker to bypass access restrictions and read protected service data on HarmonyOS 6.1.0 devices. The CVSS vector (AV:L/AC:H/PR:N) confirms local-only exploitation with high attack complexity, substantially limiting reach. No public exploit code exists and the vulnerability is not listed in the CISA KEV catalog; the primary concern is confidentiality exposure on unpatched consumer and laptop devices.
Improper certificate validation in Dell Secure Connect Gateway (SCG) 5.0 exposes enterprise environments to unauthorized information disclosure via a network-based man-in-the-middle attack. Both the Appliance form factor (versions prior to 5.36.00.16) and the Application form factor (versions prior to 5.36.00.00) are affected. An unauthenticated remote attacker who can intercept network traffic between the SCG and a remote endpoint could present a forged or invalid certificate that the product accepts, allowing interception of sensitive communications. No public exploit or active exploitation (CISA KEV) has been identified at time of analysis, and a vendor-released patch is available.
Stored Cross-Site Scripting in LF Edge eKuiper (versions prior to 2.4.0) allows an authenticated API user to inject arbitrary HTML or JavaScript into external service names, which execute in any administrator's browser when the administrative web UI renders the unescaped identifier. Successful exploitation can lead to session token exfiltration or unauthorized browser-context actions on behalf of the viewing administrator. A detailed public proof-of-concept exists in GitHub Security Advisory GHSA-g8rh-fjm6-h2h9; no active exploitation has been confirmed by CISA KEV at time of analysis.
Improper certificate validation in Dell Secure Connect Gateway (SCG) 5.0 allows an unauthenticated remote attacker occupying a network interception position to bypass TLS certificate checks, enabling unauthorized access to protected communications. Both the Appliance (versions prior to 5.36.00.16) and Application (versions prior to 5.36.00.00) variants are affected. Dell has released fixed versions and published advisory DSA-2026-382; no public exploit or active exploitation has been identified at time of analysis.
Improper certificate validation in Dell Secure Connect Gateway (SCG) 5.0 allows a network-positioned unauthenticated attacker to intercept TLS communications, potentially gaining unauthorized access to data in transit. The Appliance variant (prior to 5.36.00.16) and Application variant (prior to 5.36.00.00) are both affected. CVSS 3.7 reflects the high attack complexity requirement - a man-in-the-middle network position - and a limited confidentiality-only impact, with no integrity or availability consequence. No public exploit or CISA KEV listing exists at time of analysis.
Improper certificate validation in Dell Secure Connect Gateway 5.0 (both Appliance and Application variants) exposes organizations to protection mechanism bypass by unauthenticated remote attackers positioned on the network path. Affected are all Appliance versions prior to 5.36.00.16 and all Application versions prior to 5.36.00.00, as confirmed by Dell advisory DSA-2026-382 and EUVD-2026-75026. The CVSS 3.7 Low score reflects high attack complexity - requiring man-in-the-middle positioning - with only limited confidentiality impact; no public exploit or active exploitation has been identified at time of analysis.
Unauthorized system log modification in Dell PowerScale OneFS (versions 9.5.0.0-9.7.1.15, 9.8.0.0-9.13.1.0, and all versions prior to 9.15.0.0) results from an Incorrect Authorization flaw (CWE-863) that allows a low-privileged attacker with adjacency to the cluster management network to tamper with audit logs. The direct impact is limited to low-integrity loss-no confidentiality or availability exposure is confirmed-but log tampering poses a meaningful forensic risk by enabling attackers to obscure prior activity. No public exploit code and no CISA KEV listing have been identified at time of analysis; a vendor-released patch is available.
Memory read outside the renderer sandbox in Google Chrome's GPU component affects all desktop versions prior to 153.0.8010.36. An uninitialized GPU resource (CWE-908) enables an attacker who has already gained code execution inside the renderer process to read stale memory contents from outside the sandbox boundary via a crafted HTML page, exposing browser process memory or heap addresses. No active exploitation has been confirmed (not in CISA KEV) and EPSS is 0.24% at the 16th percentile, consistent with the high-complexity, two-stage attack prerequisite.
Uninitialized resource use in Chrome's Media component (CVE-2026-87456) enables a renderer-compromised attacker to read memory outside the Chrome sandbox via a crafted HTML page, fixed in version 153.0.8010.36. This is a post-compromise, second-stage information disclosure capability rather than a standalone entry-point vulnerability - successful exploitation requires the attacker to have already achieved code execution within the renderer process through a separate exploit. CVSS 3.4 (Low), Chromium-rated Medium, with EPSS at 0.23% and no public exploit or CISA KEV entry.
Uninitialized GPU resource in Google Chrome for Android (prior to 153.0.8010.36) allows a renderer-compromised attacker to read memory outside the browser sandbox via a crafted HTML page. This is a second-stage vulnerability - it requires the renderer process to already be compromised, meaning it operates as a chained exploit component rather than an independent attack path. No public exploit has been identified; EPSS is 0.19% (9th percentile), and the Chromium team rates severity as Medium, consistent with the constrained impact and high prerequisite bar.
Least Privilege Violation in Dell Secure Connect Gateway (SCG) 5.0 allows a locally authenticated high-privileged attacker to perform unauthorized operations beyond their intended permission scope, resulting in low-impact integrity and availability degradation. Affected are both the Appliance variant (versions prior to 5.36.00.16) and the Application variant (versions prior to 5.36.00.00). No public exploit or active exploitation has been identified; the low CVSS score of 3.4 reflects the constrained attack surface requiring local, high-privileged access.
Dell Secure Connect Gateway 5.0 Appliance (prior to 5.36.00.16) and Application (prior to 5.36.00.00) contain a CWE-250 Execution with Unnecessary Privileges flaw in which internal components operate with OS-level permissions exceeding what their function requires, allowing a locally authenticated high-privileged attacker to perform unauthorized modifications to system integrity and availability. The affected products are Dell's enterprise remote support gateway platform used to facilitate secure ProSupport connectivity in production environments. No public exploit code has been identified and the CVSS 3.4 Low rating reflects the substantial access prerequisites - local access and a pre-existing high-privilege account - sharply limiting opportunistic exploitation potential.
Least Privilege Violation in Dell Secure Connect Gateway 5.0 allows a locally authenticated, high-privileged attacker to perform actions beyond their authorized scope, resulting in unauthorized integrity and availability impact. Affected deployments include Appliance versions prior to 5.36.00.16 and Application versions prior to 5.36.00.00, with a vendor-released patch available via Dell Security Advisory DSA-2026-382. No public exploit code or CISA KEV listing has been identified at time of analysis.
Dell Secure Connect Gateway (SCG) 5.0 - both the Appliance and Application editions - writes sensitive information into files or directories that are externally accessible on the local system (CWE-538). A local attacker with low privileges who can read those files gains access to information they should not be authorized to see. No public exploit code exists and no active exploitation has been reported; the low CVSS base score of 3.3 reflects the local, low-privilege access requirement and limited confidentiality impact.
Sensitive information insertion into log files in Dell Secure Connect Gateway (SCG) 5.0 exposes confidential data to local low-privileged users. Both the Appliance variant (versions prior to 5.36.00.16) and the Application variant (versions prior to 5.36.00.00) are affected, with the vulnerability covered under Dell advisory DSA-2026-382 alongside additional CVEs. No public exploit code or active exploitation has been identified, and the low CVSS score of 3.3 accurately reflects the constrained local access requirement and limited confidentiality impact.
Sensitive information insertion into log files in Dell Secure Connect Gateway (SCG) 5.0 exposes confidential data to local low-privileged users. Both the Appliance variant (prior to 5.36.00.16) and the Application variant (prior to 5.36.00.00) are affected. A local attacker with standard OS-level access can read log files containing sensitive data, potentially including credentials or configuration secrets. No active exploitation or public proof-of-concept has been identified at time of analysis.
Dell Secure Connect Gateway (SCG) 5.0 exposes sensitive system information through uncleared debug artifacts accessible to local low-privileged users, affecting both the Appliance variant (prior to 5.36.00.16) and the Application variant (prior to 5.36.00.00). The root cause is CWE-1258: debug data containing sensitive system details is not purged and remains readable on the local filesystem. No public exploit code has been identified and exploitation requires local authenticated access, making real-world impact limited to insider threat scenarios or post-compromise reconnaissance.
Prerender's confused deputy flaw in Google Chrome prior to 153.0.8010.36 enables an attacker who has already compromised the renderer process to bypass the web Same-Origin Policy via a crafted HTML page, potentially exposing limited cross-origin data. This is a chaining vulnerability: it requires a prior renderer compromise and user interaction, not a standalone exploit path. Google rated it Chromium 'Medium', consistent with the CVSS 3.1 base score of 3.1 (Low); no public exploit code exists and it is not listed in CISA KEV.
CORS authorization bypass in Google Chrome prior to 153.0.8010.36 allows an attacker who has already achieved renderer process compromise to circumvent the browser's same-origin policy and read limited cross-origin response data. The flaw (CWE-862, Missing Authorization) is a chaining primitive: it requires both user interaction via a crafted HTML page and a pre-existing renderer exploit, making it a second-stage capability rather than an independent entry point. No public exploit code has been identified, EPSS is 0.31% (24th percentile), and the vulnerability is not listed in CISA KEV, all consistent with its constrained real-world utility.
Incorrect authorization in Chrome's PushAPI (all versions prior to 153.0.8010.36) permits a remote attacker who has already obtained a renderer process compromise to bypass the web origin policy, potentially gaining access to push subscription data belonging to other web origins. This is a chained, secondary-stage vulnerability - it extends a renderer compromise rather than providing initial access, and its confidentiality impact is limited to PushAPI subscription metadata. No public exploit exists and EPSS is low at 0.29%; a vendor patch is available in the stable channel release 153.0.8010.36.
CORS authorization bypass in Google Chrome prior to 153.0.8010.36 enables a remote attacker - who has already compromised the renderer process - to circumvent the browser's web origin policy via a crafted HTML page. The vulnerability is classified CWE-863 (Incorrect Authorization) and is confined to a post-renderer-compromise scenario, meaning it functions as a second-stage primitive rather than an initial access vector. CVSS 3.1 and an EPSS of 0.26% (18th percentile) reflect the high exploitation complexity; no public exploit or CISA KEV listing exists at time of analysis.
Use-after-free in Chrome's V8 JavaScript engine enables an attacker with a pre-compromised renderer process to read arbitrary memory within the sandbox boundaries via a crafted HTML page. Affected versions are Chrome prior to 153.0.8010.36 on all desktop platforms. Unlike most Chrome UAF findings that achieve sandbox escape, this vulnerability is constrained to intra-sandbox memory disclosure (C:L, S:U), making it a stepping-stone primitive rather than a standalone critical exploit. No public exploit code or CISA KEV listing exists at time of analysis.
Cross-origin data disclosure in Chrome's WebMCP component before 153.0.8010.36 enables a renderer-compromised attacker to exfiltrate cross-origin page data via a crafted HTML page. This is a second-stage vulnerability in a multi-step exploit chain - it does not enable initial access but amplifies the impact of a prior renderer compromise by breaking the same-origin boundary through the WebMCP interface. With a CVSS score of 3.1, EPSS at 0.24% (15th percentile), no KEV listing, and no public exploit identified, real-world risk is low except in targeted attack chains pairing this with a separate, more severe renderer exploit.
Cross-origin data leakage in the Chrome Downloads subsystem exposes sensitive information to attackers who have already established renderer process compromise. Chrome versions prior to 153.0.8010.36 are affected; exploitation requires a renderer-compromised context combined with user interaction via a crafted HTML page. Google rated this 'Medium' internally; the CVSS 3.1 score of 3.1 reflects its role as a second-stage exploitation step rather than a standalone critical flaw. No public exploit code or CISA KEV listing exists at time of analysis.
Cross-origin data leakage in Google Chrome's Network component prior to version 153.0.8010.36 allows remote attackers to infer information about cross-origin resources through observable behavioral discrepancies (CWE-203). Exploitation requires a victim to visit a crafted HTML page (UI:R) and involves high attack complexity (AC:H), indicating that reliable exploitation depends on meeting specific preconditions in the victim's browser or network environment. With an EPSS of 0.21% (11th percentile), no CISA KEV listing, and no confirmed public exploit, real-world risk is low despite the network-accessible attack vector.
Web origin policy bypass in Google Chrome's Mobile component on iOS allows a remote attacker to read cross-origin content via a race condition triggered through a crafted HTML page. Affected versions are all Chrome releases prior to 153.0.8010.36 on iOS. Exploitation requires social engineering to induce the target to visit a malicious page, and the race condition's timing dependency (AC:H) limits reliable exploitation, though a successful attack permits limited cross-origin data disclosure. No public exploit identified at time of analysis.
Incorrect GPU authorization in Google Chrome on macOS (prior to 153.0.8010.36) allows an attacker who has already compromised the renderer process to read cross-origin data by directing the victim to a crafted HTML page. This is a second-stage, chained vulnerability - not an initial access primitive - requiring prior renderer compromise and user interaction, which constrains its practical exploitability. Chromium rates this Medium, consistent with the CVSS 3.1 base score and the strictly limited confidentiality-only impact.
Incorrect authorization in the ServiceWorker component of Google Chrome prior to 153.0.8010.36 enables a remote attacker who has already compromised the renderer process to bypass the browser's web origin policy via a crafted HTML page. Exploitation is constrained by two hard prerequisites: a prior renderer process compromise and user interaction, reflected accurately in the CVSS 3.1 Low score and Chromium's own 'Low' severity classification. No public exploit code or active exploitation (CISA KEV) has been identified; SSVC rates exploitation status as none and automatable as no.
Missing authorization in Chrome's WebUI component (prior to 153.0.8010.36) allows an attacker who has already compromised the renderer process to bypass the web origin policy via a crafted HTML page, potentially reading cross-origin content. This is a chained post-exploitation technique requiring a separately-achieved renderer compromise as a hard prerequisite, not a standalone initial-access vector. No public exploit code has been identified and the EPSS score of 0.19% (9th percentile) reflects low mass-exploitation probability; Google rates the Chromium severity as High, which diverges significantly from the CVSS 3.1 base score of 3.1.
Cross-origin data exfiltration in Google Chrome's CORS implementation prior to 153.0.8010.36 is exploitable only as a second-stage technique by an attacker who has already compromised the renderer process, allowing them to read data from foreign origins the victim is authenticated to via a crafted HTML page. With a CVSS of 3.1, EPSS of 0.17% (7th percentile), no CISA KEV listing, and no public exploit code identified, this represents a low standalone risk - its relevance is as a data-harvesting primitive chained after a renderer RCE. Chromium rated it 'Medium,' consistent with the constrained exploitation path.
Cross-origin data disclosure in Google Chrome's FileSystem component allows a remote attacker who has already compromised the renderer process to bypass authorization checks and read data from origins other than the attacker-controlled page. Affected versions are all Chrome releases prior to 153.0.8010.36. This is a post-renderer-compromise information disclosure step, not an initial entry point; no public exploit code has been identified and EPSS sits at 0.17% (6th percentile), consistent with its role as a chained component rather than a standalone threat.
Case-insensitive username comparisons in two code paths of the CUPS scheduler - printer ACL validation and private-attribute filtering - allow an authenticated adjacent-network attacker to bypass username-based access controls in configurations that rely on those ACLs. The bypass exposes private print attributes to users who should be excluded by ACL policy. Affected deployments span Red Hat Enterprise Linux 6 through 10, Red Hat Hardened Images, and OpenShift Container Platform 4. No public exploit or active exploitation has been identified at time of analysis, consistent with the low CVSS base score of 3.0.
Out-of-bounds memory read in Google Chrome's Chromoting (Chrome Remote Desktop) component on Windows prior to 153.0.8010.36 allows a local attacker to read memory beyond the Chrome sandbox boundary via a crafted local program. The vulnerability carries a CVSS score of only 2.7 (Low), reflecting significant exploitation constraints: local access, high attack complexity, required user interaction, and a partial confidentiality-only impact with no integrity or availability consequence. No public exploit has been identified, EPSS sits at the 4th percentile (0.15%), and SSVC classifies exploitation status as none with non-automatable, partial technical impact.
Uncleared debug information in Dell Secure Connect Gateway (SCG) 5.0 exposes sensitive system data to physically present unauthenticated attackers. Both the Appliance variant (versions prior to 5.36.00.16) and the Application variant (versions prior to 5.36.00.00) are affected, per CPE data and the Dell advisory DSA-2026-382. The CVSS vector (AV:P) confirms exploitation is constrained to physical access, yielding a low overall severity of 2.4, and no public exploit or active exploitation has been identified at time of analysis.
Snipe-IT 8.6.3 and earlier silently produce false compliance artifacts when the configured storage backend fails to write acceptance evidence files. In Account\AcceptanceController::store(), the return value of Storage::put() is never checked; if the storage layer returns false rather than throwing an exception, execution proceeds unconditionally to $acceptance->accept(), which stamps the record as complete, records signature and PDF filenames, creates the audit-log entry, and dispatches notifications - all referencing evidence files that were never persisted. The practical result is a compliance record whose audit trail appears valid but whose supporting documentation does not exist, a material risk in regulated environments using Snipe-IT for EULA acknowledgement or equipment-receipt workflows. No public exploit code exists and no active exploitation has been identified; the CVSS 4.0 score of 2.3 reflects the low real-world risk.
Race condition in Snipe-IT ≤8.6.3 allows two concurrent checkout requests for the same available asset to both pass the availability check and both commit, corrupting the audit trail with duplicate checkout-history rows, a doubled checkout_counter, and two spurious CheckoutableCheckedOut events. Authenticated users holding the assets.checkout permission can trigger this by issuing precisely timed concurrent HTTP requests. The visible asset assignment remains singular, so the primary tracking record is not altered, but reconciliation, utilization reporting, and ITSM integrations that rely on event counts or the checkout_counter are affected. No public exploit has been identified and CVSS 4.0 scores this 2.1 (Low).
Local information disclosure in Samsung Mobile's Watch Plugin for Android allows attackers with physical or local software access to read sensitive data from the device. Affected versions are all Watch Plugin releases prior to the Android Watch 17 patch, as confirmed by the Samsung Mobile security advisory. No active exploitation (not in CISA KEV) and no public proof-of-concept code are identified at time of analysis; the CVSS 4.0 score of 2.1 accurately reflects the constrained local-only, low-confidentiality-impact nature of this vulnerability.
In the Linux kernel, the following vulnerability has been resolved: HID: core: fix number/pointer type confusion on long items When fetch_item() is called by hid_scan_report() on an item with HID_ITEM_TAG_LONG, it stores a pointer to the item data in item->data.longdata instead of storing a value directly in item->data.{u8/u16/u32}. When item_udata() or item_sdata() encounters such an item, it incorrectly assumes that the item is in short format, and therefore returns the lower part of a kernel pointer reinterpreted as a number. When a HID device is connected whose descriptor contains a HID_GLOBAL_ITEM_TAG_REPORT_SIZE encoded in long format with size=4, this causes the lower half of a kernel pointer to be printed into dmesg as a number, like this: hid (null): invalid report_size 107953555 To fix it, let item_udata() and item_sdata() verify that the item is in short format. Note that this bug only affects hid_scan_report(), while the main parsing pass hid_parse_collections() will always bail out when encountering a long item. Sidenote: There are currently no users of data.longdata; maybe we should just remove any parsing of long-format descriptors as a follow-up.
In the Linux kernel, the following vulnerability has been resolved: xhci: dbgtty: Fix unregister on tty_register_driver() failure If tty_register_driver() fails, it drops the reference, but fails to set the global dbc_tty_driver to NULL, causing the unregister to be called again when module exits. On module unload dbc_tty_exit() only gates its cleanup on the driver pointer being non-NULL, so it operates on the already-freed driver: module_init(xhci_hcd_init) xhci_hcd_init() xhci_dbc_init() [return value ignored] dbc_tty_init() tty_register_driver() fails tty_driver_kref_put() -> driver freed (dbc_tty_driver left dangling) ... module_exit(xhci_hcd_fini) xhci_hcd_fini() xhci_dbc_exit() dbc_tty_exit() if (dbc_tty_driver) -> true (dangling) tty_unregister_driver() -> use-after-free
In the Linux kernel, the following vulnerability has been resolved: PCI: host-generic: Fix NULL pointer dereference on 32-bit CAM systems On 32-bit systems the config space is too large to ioremap in one go, so pci_ecam_create() maps each bus segment separately and relies on the ->add_bus callback (pci_ecam_add_bus) to populate the per-bus mapping in cfg->winp[]. pci_ecam_map_bus() then uses that mapping as the base for every config access. The generic ECAM ops (pci_generic_ecam_ops) already provide the ->add_bus and ->remove_bus callbacks, but the CAM (legacy) ops in pci-host-generic.c do not. As a result, on a 32-bit host using "pci-host-cam-generic" the per-bus mapping is never set up and the first config read dereferences a NULL base, crashing during bus enumeration: Unable to handle kernel NULL pointer dereference at virtual address 00000800 Oops [#1] CPU: 0 PID: 1 Comm: swapper Not tainted 6.9.7+ #43 Hardware name: Digilent Nexys-Video-A7 RV32 (DT) epc : pci_generic_config_read+0x40/0xb0 ra : pci_generic_config_read+0x2c/0xb0 [<c038db9c>] pci_generic_config_read+0x40/0xb0 [<c038da04>] pci_bus_read_config_dword+0x50/0xb0 [<c0391e94>] pci_bus_generic_read_dev_vendor_id+0x3c/0x1ec [<c039245c>] pci_scan_single_device+0xa4/0x11c [<c0392570>] pci_scan_slot+0x9c/0x23c [<c039388c>] pci_scan_child_bus_extend+0x58/0x2f4 [<c0393db0>] pci_scan_root_bus_bridge+0x64/0xe8 [<c0393e54>] pci_host_probe+0x20/0xc8 [<c03bc6f4>] pci_host_common_probe+0x144/0x1e4 Fix this by giving the CAM ops the same ->add_bus/->remove_bus callbacks. Since pci_ecam_add_bus() and pci_ecam_remove_bus() are static to ecam.c, move the CAM ops definition there as pci_generic_cam_ops (mirroring pci_generic_ecam_ops) and export it for pci-host-generic.c to reference. [mani: removed timestamp from log]
In the Linux kernel, the following vulnerability has been resolved: io_uring: defer eventfd signaling when queued from a wakeup handler io_req_local_work_add() signals the CQ ring eventfd inline when it is the one to push the first entry onto ->work_list. For DEFER_TASKRUN rings that add is frequently done from a waitqueue wakeup handler, where an arbitrary waitqueue lock is held. eventfd_signal_mask() only refuses to recurse when current->in_eventfd is set, but that bit is set by eventfd_signal_mask() itself. If the wake chain starts somewhere else, signal goes out inline and can feed back into epoll. Add IOU_F_TWQ_IN_WAKE, set it on the task_work add done from the three waitqueue callbacks, and use it to force io_eventfd_signal() down the existing call_rcu_hurry() deferral instead of signaling inline.
In the Linux kernel, the following vulnerability has been resolved: vlan: fix skb_under_panic and races when toggling HW VLAN offload Toggling hardware VLAN TX offload (NETIF_F_HW_VLAN_CTAG_TX or NETIF_F_HW_VLAN_STAG_TX) on a lower device invokes vlan_transfer_features(), which dynamically changed vlandev->hard_header_len. This causes two issues: 1. Lockless TX paths (e.g. packet_snd in af_packet.c, ip6_finish_output2) read dev->hard_header_len without holding RTNL lock. Mutating hard_header_len dynamically under RTNL creates a data race where upper layers reserve insufficient headroom based on a stale hard_header_len, resulting in skb_under_panic when vlan_dev_hard_header() is called. 2. In addition, vlan_transfer_features() updated hard_header_len without updating header_ops, causing a mismatch between allocated headroom and header creation. Always setting dev->hard_header_len = real_dev->hard_header_len and dev->needed_headroom = real_dev->needed_headroom + VLAN_HLEN unconditionally ensures: - dev->hard_header_len remains 100% static and immutable at real_dev->hard_header_len, eliminating all dynamic runtime updates and data races on hard_header_len. - Upper layers allocating skbs via LL_RESERVED_SPACE() will always reserve sufficient headroom for software VLAN tag insertion (real_dev->hard_header_len + real_dev->needed_headroom + VLAN_HLEN). - vlandev inherits real_dev->needed_tailroom so underlying trailer/padding/ICV requirements are honored. - AF_PACKET SOCK_RAW network header offsets remain correctly aligned at real_dev->hard_header_len. - vlan_header_ops is used unconditionally. Note to stable teams: Make sure to backport these commits: e16e960d55a4 ("ipvlan: inherit needed_headroom and needed_tailroom from phy_dev") cef51860becd ("macvlan: inherit needed_headroom and needed_tailroom from lowerdev")
In the Linux kernel, the following vulnerability has been resolved: crypto: qcom-rng - Allow zero as a random number Zero is a valid random number and needs to be allowed. Otherwise the output is distinguishable from random.
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix recursive ww_mutex acquire in amdgpu_devcoredump_format When dumping IB contents from a hung job, amdgpu_devcoredump_format() acquired the VM root PD's reservation via amdgpu_vm_lock_by_pasid() and then, for each IB, called amdgpu_bo_reserve() on the BO backing the IB. Both reservations are reservation_ww_class_mutex objects and neither used a ww_acquire_ctx, which trips lockdep: WARNING: possible recursive locking detected -------------------------------------------- kworker/u128:0 is trying to acquire lock: ffff88838b16e1f0 (reservation_ww_class_mutex){+.+.}-{4:4}, at: amdgpu_devcoredump_format+0x1594/0x23f0 [amdgpu] but task is already holding lock: ffff8882f82681f0 (reservation_ww_class_mutex){+.+.}-{4:4}, at: amdgpu_devcoredump_format+0x1594/0x23f0 [amdgpu] Possible unsafe locking scenario: CPU0 ---- lock(reservation_ww_class_mutex); lock(reservation_ww_class_mutex); *** DEADLOCK *** May be due to missing lock nesting notation Workqueue: events_unbound amdgpu_devcoredump_deferred_work [amdgpu] Call Trace: __ww_mutex_lock.constprop.0 ww_mutex_lock amdgpu_bo_reserve amdgpu_devcoredump_format+0x1594 [amdgpu] amdgpu_devcoredump_deferred_work+0xea [amdgpu] The two reservations are on different BOs in the captured trace, so the splat is a lockdep-correctness warning, not an observed deadlock. It becomes a real self-deadlock whenever the IB BO shares its dma_resv with the root PD (the always-valid case, see amdgpu_vm_is_bo_always_valid()): amdgpu_bo_reserve(abo) re-acquires the same ww_mutex without a ticket and blocks forever. With amdgpu.gpu_recovery=0 the timeout handler refires every ~2 s and each invocation produces this splat, drowning the kernel ring buffer. Now that amdgpu_vm_lock_by_pasid() takes a drm_exec context, move the IB dumping into a separate helper that locks the root PD and every IB BO together in a single drm_exec ticket. DRM_EXEC_IGNORE_DUPLICATES handles IB BOs that share a dma_resv (e.g. always-valid BOs, or two IBs backed by the same BO). Every lock is now a top-level acquire under one ww_acquire_ctx, so the recursive ww_mutex condition is gone, and the per-IB amdgpu_bo_reserve()/amdgpu_bo_unref() dance -- including a BO refcount leak on the amdgpu_bo_reserve() failure path -- is removed. (cherry picked from commit d6bf4242731219ee08ce54c365631e395486651e)