From mboxrd@z Thu Jan 1 00:00:00 1970 From: AL-KERNEL To: kernel-cve@kernelcve.org Subject: [CVE-2026-64205][MODERATE REGULAR] i2c: i801: fix hardware state machine corruption in error path Date: Mon, 20 Jul 2026 12:55:44 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AL-KERNEL-CVE: CVE-2026-64205 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: 4 X-AL-KERNEL-ActionableScore-Lower: 1 X-AL-KERNEL-Commit: bb5133a7d5f3fe5c387770e25f2e00e682ce11ed List-Id: CVE: CVE-2026-64205 Priority: MODERATE REGULAR AL-KERNEL base severity: MODERATE KPANIC flag: NO Patch: i2c: i801: fix hardware state machine corruption in error path Commit: bb5133a7d5f3fe5c387770e25f2e00e682ce11ed Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bb5133a7d5f3fe5c387770e25f2e00e682ce11ed Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-64205 Analysis date: Mon, 20 Jul 2026 12:55:44 -0400 ActionableScore: 4 ActionableScore lower bound: 1 Actionable bucket: Borderline, manual review recommended Manual review required: YES Summary: The i2c-i801 error path could clear SMBus hardware status bits without owning the controller, corrupting the BIOS/ACPI-mediated SMBus state and causing repeated busy failures, console livelock, and a possible Hung Task panic from local SMBus access. ====================================================================== ABOUT THIS REPORT ====================================================================== The original Linux kernel CVE announcement for CVE-2026-64205 is available here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-64205 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-64205 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:N/I:N/A:H';CWE-703;CWE-667;**CWE-400;Other CVSS 'AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H';BEST CVSS score: '4.7';DESCR 'The i2c i801 error path can clear SMBus hardware status bits even when i801_check_pre() failed and the kernel did not own the controller. This can interfere with an active BIOS/ACPI transaction, corrupt the SMBus controller state machine, and make later i801_access() calls repeatedly fail with busy errors. Under heavy local fuzzing or repeated local SMBus access, the resulting printk flood can cause console livelock and then a hung task panic. For the CVSS the PR:L is used for the paranoid score because some systems expose /dev/i2c-* access to non root local users or service accounts through delegated permissions. The issue is not network reachable and does not show a memory corruption primitive. Impact is denial of service through hardware state corruption, CPU starvation, and possible kernel panic.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Borderline, manual review recommended (with actual score 3) YES READ DANGER USB ERRORPATH HARDWARE LINUS DECREASED_TO_MODERATE_REGULAR_FROM_MODERATE7_BASED_ON_GUESSCVSS_AND_CIANNH YES NO checked ====================================================================== ACTIONABLESCORE ANALYSIS ====================================================================== ActionableScore=4 ActionableScoreLower=1 ## 1. ActionableScore * Conservative score: 1 * Paranoid score: 4 * Final recommended bucket: **Borderline, manual review recommended** ## 2. Signal breakdown Conservative signals: * Firmware-mediated external influence: +1 The failure condition depends on SMBus being actively used by BIOS/ACPI when `i801_check_pre()` fails. * Reliable kernel crash / strong DoS: +1 The commit describes severe livelock followed by Hung Task panic. * Availability impact realistic: +1 The corrupted SMBus state can cause repeated busy failures and printk flooding, not just a single transient warning. * Broad/default/common hardware exposure: +1 `i2c-i801` is a common Intel SMBus controller driver on many systems. * Hard or timing-dependent condition: -1 The problematic path requires concurrent SMBus access and a specific ownership failure window. * Requires admin/root/CAP-like access in typical deployments: -2 Direct SMBus/I2C access is commonly restricted to root or privileged device access. Paranoid delta: * Local unprivileged trigger: +1 Some systems expose `/dev/i2c-*` to non-root users or service accounts through group permissions or delegated device access. * Privilege penalty removed or reduced in paranoid interpretation A delegated `/dev/i2c-*` user is not equivalent to full host root. No memory corruption, UAF, OOB write, arbitrary write, credential bypass, or LPE primitive is supported by the patch. Call-site confidence: high. The patch directly shows the error-path label movement inside `i801_access()` and the problematic hardware register cleanup. ## 3. Reachability analysis The bug is locally reachable through SMBus/I2C operations that invoke `i801_access()`. In typical deployments this requires root or privileged access to I2C device nodes, so the conservative score is low. In environments where `/dev/i2c-*` is delegated to non-root users, containers, hardware-management services, or fuzzing frameworks, the practical trigger may become PR:L-like. The issue is not network reachable. It depends on hardware and firmware interaction with BIOS/ACPI ownership of the SMBus controller. Realistic exploitation requires repeated or concurrent SMBus access plus the controller being busy at the pre-check stage. ## 4. Severity interpretation This behaves like a hardware-state corruption DoS, not a kernel memory corruption vulnerability. The realistic impact is local denial of service through SMBus controller state corruption, printk flood, console livelock, and possible Hung Task panic. There is no evidence of confidentiality impact, integrity impact on kernel memory, or privilege escalation. The conservative result is Low-like ordinary Moderate. The paranoid result reaches borderline manual-review territory because delegated `/dev/i2c-*` access can make the trigger available to non-root local users and the observed impact can become host-wide availability loss. ## 5. One-sentence report phrase The i2c-i801 error path could clear SMBus hardware status bits without owning the controller, corrupting the BIOS/ACPI-mediated SMBus state and causing repeated busy failures, console livelock, and a possible Hung Task panic from local SMBus access. ## 6. Manual review recommendation MANUAL CHECK RECOMMENDED Manual review is recommended because practical severity depends heavily on whether non-root users or services can access `/dev/i2c-*`, whether the affected hardware is present, and whether firmware/ACPI SMBus activity can make the error path reproducible. ====================================================================== UPSTREAM PATCH SUMMARY ====================================================================== Patch: i2c: i801: fix hardware state machine corruption in error path Commit: bb5133a7d5f3fe5c387770e25f2e00e682ce11ed Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bb5133a7d5f3fe5c387770e25f2e00e682ce11ed Commit description: A severe livelock and subsequent Hung Task panic were observed in the i2c-i801 driver during concurrent Fuzzing. The crash is caused by an unconditional hardware register cleanup in the error handling path of i801_access(). When i801_check_pre() fails (e.g., returning -EBUSY because the SMBus controller is actively used by BIOS/ACPI), the kernel does not actually acquire the hardware ownership. However, the code jumps to the 'out' label and executes: iowrite8(SMBHSTSTS_INUSE_STS | STATUS_FLAGS, SMBHSTSTS(priv)); This forcefully clears the INUSE_STS lock and resets the hardware status flags without owning the controller. Doing so interrupts ongoing BIOS/ACPI transactions and totally corrupts the SMBus hardware state machine. Consequently, all subsequent i801_access() calls fail at the pre-check stage, triggering an endless stream of "SMBus is busy, can't use it!" error logs. Over a slow serial console, this printk flood monopolizes the CPU (Console Livelock), starving other processes trying to acquire the mmap_lock down_read semaphore, ultimately triggering the hung task watchdog. Fix this by moving the 'out' label below the hardware register cleanup. If i801_check_pre() fails, we safely bypass the iowrite8() and only release the software locks (pm_runtime and mutex), strictly adhering to the rule of not releasing resources that were never acquired. Fixes: 1f760b8 ("i2c: i801: Call i801_check_pre() from i801_access()") Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn> Cc: # v6.3+ Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260512093534.348655-1-w15303746062@163.com Signed-off-by: Greg Kroah-Hartman Changed files: drivers/i2c/busses/i2c-i801.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=bb5133a7d5f3fe5c387770e25f2e00e682ce11ed ====================================================================== DETAILED REPORT METHODOLOGY ====================================================================== The original Linux kernel CVE announcement for CVE-2026-64205 can be found here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-64205 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:H/UI:N/S:U/C:N/I:N/A:H The Best / paranoid CVSS vector: AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H The Best / paranoid CVSS score: 4.7 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: 1 Paranoid ActionableScore: 4 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).