CVE-2026-63964

Description

In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: ccg: reject firmware images without a ':' record header do_flash() locates the first .cyacd record with p = strnchr(fw->data, fw->size, ':'); while (p < eof) { s = strnchr(p + 1, eof - p - 1, ':'); ... } If the firmware image contains no ':' byte, strnchr() returns NULL. NULL compares less than the valid kernel pointer eof, so the loop body runs and strnchr() is called with p + 1 == (void *)1 and a length of roughly (unsigned long)eof, causing a wonderful crash. The not_signed_fw fallthrough earlier in do_flash() and the chip-state branches in ccg_fw_update_needed() allow an unsigned blob to reach this loop, so a root user who can place a crafted file under /lib/firmware and write the do_flash sysfs attribute can trigger the oops. Bail out with -EINVAL when the initial strnchr() returns NULL.

Is your site exposed to CVE-2026-63964?

Run a free security scan — no signup, results in seconds.

EPSS — Exploit Prediction

0.0021

Probability of exploitation

0.11%

Percentile rank

EPSS estimates the probability that this vulnerability will be exploited in the wild within the next 30 days. A higher score means more likely to be exploited.

References

Other References

https://git.kernel.org/stable/c/2f395ca1263bd181995eb829f5943a83a20db213 https://git.kernel.org/stable/c/3f432b8203066c26770fe6ea591361f10021dd6b https://git.kernel.org/stable/c/6526f8684f72391138353642af908803ba70795e https://git.kernel.org/stable/c/a38ed87818b2419090fb1a6338ddce6842b65dfa https://git.kernel.org/stable/c/b41dfc033fe594e152648050e95b9489cd53e9e3 https://git.kernel.org/stable/c/c4ee519b06389e59ba2d6aa722fcc4a02a8bbcbb https://git.kernel.org/stable/c/c8460de584fe5415d212cfdd127d4db90835a450 https://git.kernel.org/stable/c/d7486952bf74e546ee3748fb14b2d07881fa6273

Frequently Asked Questions

What is CVE-2026-63964? +

In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: ccg: reject firmware images without a ':' record header do_flash() locates the first .cyacd record with p = strnchr(fw->data, fw->size, ':'); while (p < eof) { s = strnchr(p + 1, eof - p - 1, ':'); ... } If the firmware image contains no ':' byte, strnchr() returns NULL. NULL compares less than the valid kernel pointer eof, so the loop body runs and strnchr() is called with p + 1 == (void *)1 and a length of roughly (unsigned long)eof, causing a wonderful crash. The not_signed_fw fallthrough earlier in do_flash() and the chip-state branches in ccg_fw_update_needed() allow an unsigned blob to reach this loop, so a root user who can place a crafted file under /lib/firmware and write the do_flash sysfs attribute can trigger the oops. Bail out with -EINVAL when the initial strnchr() returns NULL.

How do I check if I'm vulnerable to CVE-2026-63964? +

You can use Secably's free Website Scanner to check your website for known vulnerabilities. For infrastructure scanning, use the Port Scanner to identify exposed services that may be affected. Check the vendor advisories linked above for specific patch and version information.