NASM’s disasm() function contains a stack based buffer overflow when formatting disassembly output, allowing an attacker triggered out-of-bounds write when `slen` exceeds the buffer capacity.
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.