GHSA-gm4g-6c78-gr3w: libriscv: Out of bounds read vuln in the ELF parser (Denial of service)
libriscv is a RISC-V sandbox and emulator. Prior to 1.18, a crafted ELF binary can cause out-of-bounds reads in the host emulator. Memory<W>::binaryloader checks PTLOAD program-header bounds, but Memory<W>::serializeexecutesegment trusts section-header shoffset and shsize when locating .text without verifying the file range against mbinary.size(); Memory<W>::lookup() has a similar section-table problem. Malformed .text or .symtab offsets can therefore bypass the program-header checks and point outside the binary buffer, crashing rvlinux. With suitable memory layout or integer overflow, out-of-buffer host heap memory may instead be mapped into the guest by createexecutesegment(), potentially exposing host memory. The reported reproducer demonstrates a host SIGSEGV, while memory disclosure through grooming is described as possible rather than demonstrated. This issue is fixed in version 1.18.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
libriscvto a version that resolves this vulnerability.Fixed in 1.18
Event History
Frequently Asked Questions
Who is exposed to this issue?
Deployments using libriscv versions before 1.18 that load attacker-controlled or otherwise malformed ELF binaries are exposed. The described crash affects the host emulator, including rvlinux.
What does an attacker need to exploit it?
An attacker needs to provide a crafted ELF binary with malformed section-header offsets or sizes, such as for .text or .symtab. No privileges or user interaction are indicated by the supplied severity vector.
Are default program-header checks sufficient protection?
No. Although the binary loader validates PT_LOAD program-header bounds, the affected paths trust section-header sh_offset and sh_size values without confirming that they fall within the binary buffer.
What is the practical impact?
The demonstrated outcome is a host SIGSEGV and denial of service. Host-memory disclosure is described as possible if memory layout or integer-overflow conditions allow out-of-buffer heap memory to be mapped into the guest, but it was not demonstrated.
What should teams do if they cannot patch immediately?
Do not load untrusted ELF binaries with affected libriscv versions. The issue is fixed in version 1.18.