Bug 2457291 (CVE-2026-6069)
| Summary: | CVE-2026-6069 nasm: NASM: Arbitrary code execution via stack-based buffer overflow in `disasm()` | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | OSIDB Bzimport <bzimport> |
| Component: | vulnerability-draft | Assignee: | Product Security <prodsec-ir-bot> |
| Status: | NEW --- | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | unspecified | CC: | nickc, pogwuche, sipoyare |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | Flags: | pogwuche:
needinfo-
|
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | --- | |
| Doc Text: |
A flaw was found in NASM. The `disasm()` function contains a stack-based buffer overflow, a memory corruption vulnerability. A remote attacker can exploit this by providing specially crafted input, leading to an out-of-bounds write when the `slen` value exceeds the buffer capacity during disassembly output formatting. This can result in arbitrary code execution.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 2458086, 2458088 | ||
| Bug Blocks: | |||
|
Description
OSIDB Bzimport
2026-04-10 14:01:53 UTC
What's the threat model here? the CVSS score is completely out of whack: - nasm is a local program; how is this exploitable over the network? - What trust boundary is being crossed? The "poc" links against and calls the `disasm()` function in the nasm code base. nasm is not a library, so I don't see how the poc even makes sense. Please reassess, there's no justification to even assign a CVE here unless there's so far unpublished information that describes how a buffer overflow in a local program could somehow be exploited over the network, let alone have it marked as an "Important" CVE. Quickly looking at the nasm binary in Fedora, the disasm() function doesn't figure in the dynamic symbol table, so there's no case of some arbitrary code jumping/calling into disasm() . This means that the only way to trigger the bug is to trick a local user into disassembling an untrusted, crafted binary using the ndisasm utility without sandboxing, which a bad security practice anyway; one must never download and analyze untrusted binaries without sandboxing. Unfortunately nasm does not have a proper security policy in place like yasm[1] or binutils[2], both of which specifically call out this problem. [1] https://github.com/yasm/yasm/blob/master/SECURITY.md [2] https://sourceware.org/git/?p=binutils-gdb.git;a=blob_plain;f=binutils/SECURITY.txt;hb=HEAD ... and digging further, this is probably completely bogus, disasm() is only ever called with a 256 byte buffer, so never with the small buffer size as the POC claims: https://github.com/netwide-assembler/nasm/issues/217#issuecomment-4244516856 There's no bug here AFAICT, let alone a security issue. |