CVE-2026-53351

What it actually does

This is a local denial-of-service flaw in the Linux kernel on RISC-V systems related to core-dump generation and ptrace register-set metadata. When the kernel dumps an ELF core file, the RISC-V REGSET_CFI entry can reach the ELF core-dump path without the expected note type/name metadata, triggering a kernel warning in fs/binfmt_elf.c at elf_core_dump(). On systems configured to treat kernel warnings as fatal, such as with panic_on_warn enabled, a low-privileged local user may be able to crash or reboot the system by causing a process to dump core. On systems that do not panic on warnings, the impact is more likely limited to kernel log noise and potential operational disruption during repeated triggering.

Why it matters to the business

An attacker who already has local code execution on an affected RISC-V Linux system could disrupt service availability by repeatedly triggering kernel warnings or, on hardened configurations that panic on kernel warnings, forcing system crashes. This is most relevant for organizations running Linux on RISC-V infrastructure, appliances, embedded platforms, CI/build hardware, or multi-user systems. The vulnerability is not known to be exploited in the wild, is not in CISA KEV, has very low EPSS likelihood, and has no reported ransomware association, so urgency is mainly driven by exposure of RISC-V Linux systems where untrusted users can run code or where kernel warnings cause reboots.

How an attack unfolds

An attacker first needs local access to an affected Linux system running on RISC-V, such as a shell account, compromised application user, container escape context with access to the host kernel behavior, or another path to execute local code. The attacker then runs or manipulates a process so that it terminates and produces an ELF core dump involving the affected RISC-V ptrace/register-set handling path. During core-dump generation, the kernel attempts to emit note information for the CFI register set, but the affected code uses metadata that can leave the ELF core-dump code without the expected note name/type. This triggers a kernel warning similar to a WARNING in fs/binfmt_elf.c at elf_core_dump(). If the system is configured with panic_on_warn, that warning can escalate from a logged kernel warning into a system panic, causing a reboot or outage. If panic_on_warn is not enabled, the attacker may still repeatedly trigger warnings and core dumps to create log volume or minor resource pressure, but the practical impact is lower.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the RISC-V ptrace REGSET_CFI core-dump handling change, specifically the patch described as using USER_REGSET_NOTE_TYPE for REGSET_CFI. No exact fixed package versions were provided in the input, so use the fixed kernel releases from the operating system, distribution, appliance, or embedded vendor that backport this patch. Prioritize RISC-V systems that allow untrusted local users, run shared workloads, or have panic_on_warn enabled. If immediate patching is not possible, reduce risk by disabling or limiting core dumps for untrusted users, restricting local shell/code-execution access, reviewing ulimit/core_pattern settings, and avoiding configurations that convert kernel warnings into panics unless operationally required. These mitigations reduce exploitability but should not be treated as a substitute for the kernel fix.

How to confirm the fix worked

Confirm the running kernel includes the fix by checking the installed kernel package changelog, vendor advisory, or source tree for the RISC-V ptrace change that uses USER_REGSET_NOTE_TYPE for REGSET_CFI. Verify the system architecture is RISC-V before prioritizing exposure, because the described flaw is architecture-specific. Check the active kernel version with uname -a and compare it against the vendor-fixed release stream. Review /proc/sys/kernel/panic_on_warn to understand whether a kernel warning can become a crash. Confirm core-dump policy using ulimit -c, systemd-coredump configuration, and /proc/sys/kernel/core_pattern. After patching, controlled testing in a non-production RISC-V environment should no longer produce the referenced fs/binfmt_elf.c elf_core_dump warning during core-dump generation.

Typical attack path

1. Gain local ability to execute code on an affected RISC-V Linux system.
2. Identify that core dumps are permitted and that the kernel is vulnerable to the RISC-V REGSET_CFI core-dump warning path.
3. Run a process or test program that terminates in a way that causes the kernel to generate an ELF core dump.
4. Trigger the affected RISC-V ptrace/register-set note handling during core-dump creation.
5. Cause a kernel warning in fs/binfmt_elf.c at elf_core_dump().
6. If panic_on_warn or equivalent policy is enabled, force a kernel panic/reboot and disrupt system availability.
7. Repeat the trigger where possible to sustain operational disruption or generate excessive kernel logs.

How to detect it

Look for evidence of repeated kernel warnings during ELF core-dump generation on RISC-V systems. Primary log sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, systemd-coredump logs, and crash/reboot telemetry. Search for WARNING entries referencing fs/binfmt_elf.c, elf_core_dump(), missing note name conditions, REGSET_CFI, or RISC-V ptrace activity around the same time as process crashes. Correlate these events with user sessions, recently executed local binaries, abnormal core-dump volume, and unexpected reboots. If panic_on_warn is enabled, investigate any reboot immediately preceded by the matching kernel warning. There are no known public exploit tools, named threat actors, KEV listing, or ransomware campaigns associated with this issue in the provided data, so detection should focus on behavioral evidence rather than threat-actor-specific infrastructure.

• WARNING: [!note_name] fs/binfmt_elf.c:1771
• elf_core_dump+0x910/0xf68
• elf_core_dump
• fs/binfmt_elf.c:1771
• REGSET_CFI
• riscv/ptrace
• USER_REGSET_NOTE_TYPE
• panic_on_warn

What your security team should do

• Inventory Linux systems running on RISC-V and determine which kernels are affected by this ptrace/REGSET_CFI core-dump issue.
• Prioritize patching RISC-V systems that permit local code execution by multiple users, run untrusted workloads, or have kernel.panic_on_warn enabled.
• Apply vendor kernel updates that include the upstream fix; if using custom kernels, backport the patch that changes REGSET_CFI to use USER_REGSET_NOTE_TYPE.
• As an interim mitigation, restrict core dumps for untrusted users and review systemd-coredump, ulimit, and core_pattern settings.
• Review /proc/sys/kernel/panic_on_warn and related hardening settings to determine whether warnings can cause outages; adjust only after weighing security policy and operational risk.
• Monitor kernel logs for the specific elf_core_dump warning pattern and repeated core-dump activity on RISC-V hosts.
• Because EPSS is very low, exploit maturity is listed as none, and the issue is not in KEV, treat this as a targeted hardening and availability patch rather than an emergency internet-wide response.