From mboxrd@z Thu Jan 1 00:00:00 1970 From: AL-KERNEL To: kernel-cve@kernelcve.org Subject: [CVE-2026-63927][MODERATE REGULAR] usb: dwc2: Fix use after free in debug code Date: Sun, 19 Jul 2026 15:07:38 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AL-KERNEL-CVE: CVE-2026-63927 X-AL-KERNEL-Priority: MODERATE REGULAR X-AL-KERNEL-Severity: MODERATE REGULAR X-AL-KERNEL-Base-Severity: MODERATE X-AL-KERNEL-KPANIC: NO X-AL-KERNEL-ActionableScore: 3 X-AL-KERNEL-ActionableScore-Lower: 2 X-AL-KERNEL-Commit: d5fc183ed614aeba6779cc992325be560f9a4451 List-Id: CVE: CVE-2026-63927 Priority: MODERATE REGULAR AL-KERNEL base severity: MODERATE KPANIC flag: NO Patch: usb: dwc2: Fix use after free in debug code Commit: d5fc183ed614aeba6779cc992325be560f9a4451 Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d5fc183ed614aeba6779cc992325be560f9a4451 Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-63927 Analysis date: Sun, 19 Jul 2026 15:07:38 -0400 ActionableScore: 3 ActionableScore lower bound: 2 Actionable bucket: Borderline Moderate. Manual review recommended Manual review required: YES Summary: A DWC2 USB host debug path reads `urb->status` after `usb_hcd_giveback_urb()` may have released the URB, creating a constrained use-after-free read that is local or USB-adjacent and mainly relevant when the affected debug logging path is enabled. ====================================================================== ABOUT THIS REPORT ====================================================================== The original Linux kernel CVE announcement for CVE-2026-63927 is available here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-63927 The original announcement does not normally provide a security severity estimate, CVSS assessment, or enough information to determine whether the reported kernel bug represents a practically relevant security issue. This report was generated by AL-KERNEL, an AI-assisted Linux kernel vulnerability analysis system developed by Alexander Larkin. It combines an autonomous classifier with LLM-assisted technical analysis and a separate ActionableScore mechanism. The purpose of this report is to prioritize Linux kernel CVEs before manual review, identify cases that require prompt investigation, and support automatic closure of issues that are unlikely to have meaningful security impact. Published priority for this report: MODERATE REGULAR Manual review required: YES A detailed explanation of the methodology and priority rules is included at the end of this message. ====================================================================== AL-KERNEL CLASSIFICATION RESULT ====================================================================== CVE-2026-63927 MODERATE CHECK WITH IMPACT FROM ORIG NN MODERATE Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:H';*CWE-416;CWE-825;CWE-667;Other CVSS 'AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:L';BEST CVSS score: '5.3';DESCR 'A use after free read exists in the DWC2 USB host controller dequeue debug path because the code reads the URB status after usb_hcd_giveback_urb() returns ownership of the URB to upper layers. The URB may be completed and freed by that point, so the later debug read can access stale kernel memory. For the CVSS the PR:L is used because reliable triggering normally requires a local user or local process able to interact with the affected USB device path or cause URB dequeue activity. The issue is not network reachable and is mainly relevant on systems using the dwc2 host driver with the affected debug path active. Impact is at least a local denial of service or limited debug log information exposure, but the visible primitive is a read after free rather than a write primitive or confirmed privilege escalation path.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Borderline Moderate. Manual review recommended (with actual score 3) YES USB UAF DECREASED_TO_MODERATE_REGULAR_FROM_MODERATE7_BASED_ON_GUESSCVSS_AND_CIANNH NO NO checked ====================================================================== ACTIONABLESCORE ANALYSIS ====================================================================== ActionableScore=3 ActionableScoreLower=2 ## 1. ActionableScore * Conservative score: 2 * Paranoid score: 3 * Final recommended bucket: **Borderline Moderate. Manual review recommended** ## 2. Signal breakdown Positive signals: * Generic memory corruption, weak practical primitive: +1 This is a real use-after-free read, but only reads `urb->status` after `usb_hcd_giveback_urb()`. No write-after-free, callback control, type confusion, or reclaim primitive is shown. * Real lifetime corruption: +1 Ownership of the URB is returned to upper layers before the later dereference, so the lifetime rule is violated. * Local trigger possibility: +1 paranoid only A local process or local USB activity may be able to cause URB dequeue behavior, depending on device permissions and deployment. Negative / limiting signals: * Non-default debug exposure: -1 The dereference is in `dev_dbg()`. In normal builds or when the dynamic debug site is not enabled, the argument is usually not evaluated at runtime. * Highly constrained primitive: -1 The stale access is a small read for logging, not an attacker-controlled overwrite or object replacement primitive. Not awarded: * No remote/network reachability. * No privilege escalation plausibility beyond generic UAF concern. * No strong DoS signal, because a stale slab read in debug logging is not a reliable crash primitive in normal production settings. * No integrity impact. ## 3. Reachability analysis The affected path is in the DWC2 USB host controller URB dequeue flow. Realistic triggering requires a system using the `dwc2` host driver and activity that causes URB dequeue. This is local or physical-device-adjacent, not network reachable. Namespaces and containers do not substantially improve reachability unless the container is granted access to relevant USB device interfaces. Ordinary unprivileged users usually need device permissions or an exposed USB userspace path. The vulnerable dereference is in debug logging, so practical exposure depends heavily on `CONFIG_DYNAMIC_DEBUG`, `DEBUG`, or the specific debug callsite being enabled. Call-site confidence: high. The patch shows the relevant call site and the exact lifetime transition around `usb_hcd_giveback_urb()`. ## 4. Severity interpretation This behaves more like a low-end to borderline Moderate kernel lifetime bug than an Important vulnerability. Theoretical memory safety concern exists because the code dereferences a URB after ownership may have been released. Realistic exploitation evidence is weak because the visible primitive is only a debug-path read of an integer field after free. The paranoid score is kept slightly above the conservative score because UAF classes deserve manual review, but the issue should not be treated as an actionable Important candidate without additional evidence of attacker-controlled reuse, a write primitive, callback influence, or reliable crash behavior. ## 5. One-sentence report phrase A DWC2 USB host debug path reads `urb->status` after `usb_hcd_giveback_urb()` may have released the URB, creating a constrained use-after-free read that is local or USB-adjacent and mainly relevant when the affected debug logging path is enabled. ## 6. Manual review recommendation MANUAL CHECK REQUIRED Reason: the bug class is UAF and should not be auto-closed purely as a debug cleanup, but current evidence supports only a constrained debug-path stale read with low practical exploitability. ====================================================================== UPSTREAM PATCH SUMMARY ====================================================================== Patch: usb: dwc2: Fix use after free in debug code Commit: d5fc183ed614aeba6779cc992325be560f9a4451 Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d5fc183ed614aeba6779cc992325be560f9a4451 Commit description: We're not allowed to dereference "urb" after calling usb_hcd_giveback_urb() so save the urb->status ahead of time. Fixes: 7359d48 ("staging: HCD files for the DWC2 driver") Cc: stable Signed-off-by: Dan Carpenter Link: https://patch.msgid.link/ag1NwBpqT4IEQcdJ@stanley.mountain Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman Changed files: drivers/usb/dwc2/hcd.c Diff excerpt: Not included in this email. See the upstream URL for the full patch. Full patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d5fc183ed614aeba6779cc992325be560f9a4451 ====================================================================== DETAILED REPORT METHODOLOGY ====================================================================== The original Linux kernel CVE announcement for CVE-2026-63927 can be found here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-63927 The original CVE announcement normally does not include a security-level estimate. In particular, it may not contain a CVSS assessment, an impact level, or enough information to determine whether the reported bug is a practically relevant security issue. One purpose of this parallel CVE list is to provide that missing technical and prioritization information. The original goal of the AL-KERNEL project was to prioritize Linux kernel CVE analysis automatically before manual review. The system can also help identify non-security issues that may be suitable for automatic closure. This report was generated by AL-KERNEL, an AI-assisted Linux kernel vulnerability analysis system developed by Alexander Larkin. The first analysis stage combines an autonomous classifier with additional LLM-based analysis. The autonomous classifier runs locally on a CPU and is based on a backpropagation neural network. Together, these mechanisms produce a technical vulnerability description, identify likely weakness types, estimate CVSS severity, and provide input for ActionableScore. Two CVSS estimates are retained because incomplete kernel vulnerability information often permits more than one defensible interpretation: Conservative CVSS vector: AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:L The Best / paranoid CVSS vector: AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:H The Best / paranoid CVSS score: 5.3 The conservative vector represents a lower-impact interpretation. The Best/paranoid vector intentionally represents a plausible upper-bound interpretation and should not automatically be treated as demonstrated real-world impact. CVSS may also need to be adjusted for a particular Linux deployment, because actual reachability, privileges, enabled kernel configuration, hardware, namespaces, exposed device nodes, and other environmental conditions can differ significantly between systems. A separate ActionableScore mechanism evaluates practical remediation urgency. Its analysis may include reachability, attack prerequisites, subsystem exposure, memory-corruption characteristics, denial-of-service reliability, and possible confidentiality, integrity, or privilege-escalation impact. Conservative ActionableScore: 2 Paranoid ActionableScore: 3 The final base severity is taken directly from the second tab-separated field of the AL-KERNEL classification result. ActionableScore does not replace or independently override that final AL-KERNEL decision, and if ActionableScore adjusted impact level of ALKERNEL, then you would see self-readable flags above like INCREASED_TO_HIGH_BASED_ON_ACTIONABLESCOREHIGHEREQTHAN7. For an AL-KERNEL result of MODERATE, this report uses the following additional presentation split: ActionableScore below 5 -> MODERATE REGULAR ActionableScore 5 or more -> MODERATE 7.0 The distinction between MODERATE REGULAR and MODERATE 7.0 makes it possible to identify Moderate issues that should receive manual analysis and fixes before lower-priority MODERATE REGULAR issues. In many cases, MODERATE REGULAR fixes may wait for a later rebase or routine update. There is one override in which MODERATE REGULAR becomes MODERATE 7.0 even when the ActionableScore is below 5. When the AL-KERNEL result contains the KPANIC flag, a MODERATE result is always presented as MODERATE 7.0. The KPANIC flag selected with few regexps without usage of AI at all, so it helps to detect cases when Kernel Crash happens and similar (to filter False-Negative results from the LLM usage). KPANIC indicates that a reliable kernel crash, kernel panic, or similarly serious kernel availability impact was identified by the classification workflow. AL-KERNEL base severity for this report: MODERATE KPANIC detected for this report: NO Published priority for this report (same as in Subject): MODERATE REGULAR These results are intended to support engineering triage. They are machine-generated estimates, and cases marked for manual review should be validated by a human security engineer before final disposition. For more info read docs linked from here: https://kernelcve.org/ (and you can submit you own patch there to generate such a report for non-existant CVE-id yet). Note that in many cases this AI tool selects higher severity, than real is (means you can expect Importants instead of Moderate 7.0 or Moderates 7.0 instead of regular Moderates). If you see such cases, please use reply email interface to add additional manual analyses info to this particular CVE. And please, please, let me know when you see Lows instead of Importants or Important instead of Low (because particular for such cases I need to tune this AI tool to make it better for this one and next similar). My contact email for such notifications is alexanjelausa@gmail.com (and both send reply to CVE record itself too and see "reply" button below for howto reply).