CVE-2026-63964

What it actually does

This is a local denial-of-service flaw in the Linux kernel USB Type-C UCSI CCG firmware update path. The vulnerable code parses Cypress .cyacd firmware records and assumes the firmware blob contains a ':' record header. If a malformed firmware file contains no ':' byte, the parser receives a NULL pointer, then performs invalid pointer arithmetic and an oversized search, causing a kernel oops or crash. Exploitation requires a local privileged user capable of placing a crafted firmware file under the system firmware search path, such as /lib/firmware, and triggering the relevant do_flash sysfs attribute.

Why it matters to the business

Successful exploitation can crash the operating system, causing an unplanned reboot or service outage on affected Linux systems using the vulnerable USB Type-C controller firmware update path. The risk is primarily operational rather than data-theft focused because exploitation requires local root-level capability, EPSS is low, the issue is not in CISA KEV, and no public exploit maturity is indicated; however, kernel crashes can still affect availability for servers, appliances, kiosks, workstations, and embedded devices where uptime matters.

How an attack unfolds

An attacker who already has root or equivalent local administrative access prepares a malformed firmware blob intended for the UCSI CCG firmware updater. The blob is crafted so it lacks the ':' record delimiter expected in .cyacd firmware records. The attacker places the file in a firmware search location such as /lib/firmware, then writes to the do_flash sysfs attribute associated with the USB Type-C UCSI CCG device to initiate a firmware update. Vulnerable kernels allow the unsigned malformed blob to reach the parsing loop. Because the parser does not reject images without an initial ':' record header, it dereferences and performs arithmetic from a NULL result, causing a kernel oops, panic, or system crash. The practical result is denial of service rather than privilege escalation, because the attacker already needs high local privileges to stage the firmware and trigger flashing.

How to fix it

Upgrade to a Linux kernel build that includes the fix for the UCSI CCG firmware parser, which rejects firmware images that do not contain an initial ':' record header and returns -EINVAL instead of continuing with invalid pointer state. If vendor kernels are used, apply the relevant distribution, appliance, or embedded-platform kernel update when available. Where immediate patching is not possible, reduce exposure by limiting local administrative access, monitoring and controlling writes to /lib/firmware, restricting unnecessary firmware update workflows, and ensuring only trusted administrators can access sysfs firmware flashing attributes. Because exploitation requires root-level access, mitigations should focus on hardening privileged access and preventing unauthorized local administrative activity until patched.

How to confirm the fix worked

Confirm the running kernel package or source tree includes the UCSI CCG fix that checks the first strnchr() result and returns -EINVAL when no ':' header is present. Validate through vendor advisories, kernel changelogs, package metadata, or source inspection of the UCSI CCG firmware update implementation. In a controlled non-production system with comparable hardware, triggering the firmware update path with a malformed no-colon test firmware should fail gracefully with an invalid-argument error and must not produce a kernel oops or panic. Also verify that firmware directories such as /lib/firmware are writable only by trusted privileged users and that sysfs do_flash attributes are not exposed through automation, management agents, or container/device passthrough in ways that broaden access.

Typical attack path

1. Obtain local root or equivalent administrative access to a Linux system with the vulnerable UCSI CCG firmware update code reachable.
2. Create or stage a malformed firmware image, typically a .cyacd-like blob, that contains no ':' record header.
3. Place the crafted firmware blob in a firmware search path such as /lib/firmware.
4. Identify the sysfs do_flash attribute for the affected USB Type-C UCSI CCG device.
5. Write to the do_flash sysfs attribute to trigger the firmware update path.
6. Cause the vulnerable parser to process the malformed image and trigger a kernel oops, panic, or crash.

How to detect it

To determine whether this was already exploited, review kernel logs, system journals, crash dumps, audit logs, and file integrity telemetry. Useful sources include dmesg output, journalctl -k, /var/log/kern.log, /var/log/messages, systemd-coredump or kdump/vmcore records, auditd logs, EDR file-write telemetry, and shell history or sudo logs for privileged actions. Look for kernel oops or panic events occurring shortly after writes to firmware directories or sysfs do_flash attributes. Investigate creation or modification of unusual firmware files under /lib/firmware, especially .cyacd-like files that do not contain ':' record headers. If audit rules were active, search for write events to /lib/firmware and sysfs paths containing do_flash. Because the expected impact is a crash, successful exploitation may leave limited application-level traces; the strongest evidence is a combination of privileged firmware file placement, a do_flash trigger, and a contemporaneous kernel oops referencing UCSI CCG, firmware update handling, or invalid pointer access.

• /lib/firmware
• do_flash
• /sys/
• ucsi_ccg
• UCSI
• ccg
• cyacd
• Unable to handle kernel NULL pointer dereference
• kernel NULL pointer dereference
• Kernel panic
• Oops:
• do_flash()
• ccg_fw_update_needed
• strnchr
• -EINVAL
• firmware: failed to load
• audit:
• SYSCALL
• PATH item
• /var/log/kern.log
• /var/log/messages

What your security team should do

• Prioritize kernel updates for systems where USB Type-C UCSI CCG firmware update functionality is present and availability is important.
• Inventory Linux assets with USB Type-C controller firmware update support and determine whether the vulnerable UCSI CCG driver code is included in the running kernel.
• Treat this as lower internet-facing risk but meaningful local availability risk: exploitation requires root-level local access, EPSS is low, and the vulnerability is not listed in CISA KEV.
• Audit privileged access paths because any attacker able to exploit this already has substantial local control; focus on root account compromise, sudo misuse, endpoint management abuse, and unauthorized configuration changes.
• Monitor for unexpected writes to /lib/firmware and unexpected writes to sysfs attributes named do_flash.
• Review recent kernel oops, panic, and reboot events for references to ucsi_ccg, UCSI, Type-C firmware flashing, do_flash, or malformed firmware parsing.
• If patching is delayed, restrict or disable unnecessary firmware update procedures and ensure firmware artifacts are obtained only from trusted vendor-controlled sources.