From 51fb2b9fa7218dd3a4793723778b48e29c538741 Mon Sep 17 00:00:00 2001 From: tabudz Date: Fri, 28 Feb 2025 21:27:42 +0800 Subject: [PATCH] parser: when flattening an eop, must preserve any data buffer An eop may have a data buffer associated with it as part of the same memory allocation. Therefore, we need to move "subexpr" up instead of merging it into "eop". This *partially* resolves BR 3392707, but that test case still triggers a violation when using -gcv8. Reported-by: Suhwan Signed-off-by: H. Peter Anvin (Intel) --- src/third_party/nasm/asm/parser.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/src/third_party/nasm/asm/parser.c b/src/third_party/nasm/asm/parser.c index 47b46ecd53..7e3c49a6e7 100644 --- a/src/third_party/nasm/asm/parser.c +++ b/src/third_party/nasm/asm/parser.c @@ -458,11 +458,17 @@ static int parse_eops(extop **result, bool critical, int elem) /* Subexpression is empty */ eop->type = EOT_NOTHING; } else if (!subexpr->next) { - /* Subexpression is a single element, flatten */ - eop->val = subexpr->val; - eop->type = subexpr->type; - eop->dup *= subexpr->dup; - nasm_free(subexpr); + /* + * Subexpression is a single element, flatten. + * Note that if subexpr has an allocated buffer associated + * with it, freeing it would free the buffer, too, so + * we need to move subexpr up, not eop down. + */ + if (!subexpr->elem) + subexpr->elem = eop->elem; + subexpr->dup *= eop->dup; + nasm_free(eop); + eop = subexpr; } else { eop->type = EOT_EXTOP; }