ELF loader should validate before load by bentheredonethat · Pull Request #687 · OpenAMP/open-amp

bentheredonethat · 2026-06-01T15:29:46Z

OpenAMP’s ELF loader should reject malformed firmware images before using ELF header metadata to size allocations, copy header tables, or look up section names.

OpenAMP’s remoteproc ELF loader trusts several ELF header and section-header fields while parsing firmware images. These fields control program-header and section-header table sizes, table
offsets, segment copy ranges, and section string-table lookups.

The main issue is in the header-table loading path. The loader computes program and section table sizes from firmware-controlled values such as e_phnum * e_phentsize and e_shnum * e_shentsize.
Those computed sizes are then used for allocation and memcpy(), while later code walks the copied buffers as native Elf32_Phdr, Elf64_Phdr, Elf32_Shdr, or Elf64_Shdr arrays. If the count, entry
size, or offset metadata is malformed, the allocation/copy size can diverge from the way the loader later indexes the table.

The range checks around these copies also rely on offset-plus-length arithmetic. With malformed offsets or sizes, unchecked addition can wrap and make an invalid range appear valid. Similar range
assumptions apply when loading the section string table and when the loader asks the backing image store for the next chunk of firmware data.

Section-name lookup has a separate parser-side read issue. The loader searches for sections such as .resource_table by using each section header’s sh_name as an offset into the loaded section
string table. Because sh_name is firmware-controlled, the loader must not form or compare name_table + sh_name unless the offset is within the loaded string table and the referenced string is NUL-
terminated before the end of that table.

The fix makes the ELF loader fail closed on malformed metadata:

add portable checked arithmetic helpers for size_t multiplication, addition, and image-chunk range validation;
validate ELF header shape before loading tables, including ELF class, ELF header size, program-header entry size, section-header entry size, and section string-table index;
use checked multiplication for program-header and section-header table sizes;
replace wrapping offset-plus-length checks with overflow-safe range validation;
validate the section string-table range before copying it;
store the loaded section string-table size in the ELF image state;
bound section-name lookup by checking sh_name and comparing only within the loaded string table;
avoid wrapping arithmetic in the remoteproc caller’s non-seekable offset comparison.

With these changes, valid firmware images continue to load normally, while malformed images with inconsistent table metadata, overflowing ranges, invalid entry sizes, or out-of-bounds section
names are rejected before allocation, copy, or table lookup proceeds.

edmooring · 2026-06-17T05:47:43Z

+static int elf_validate_header(const void *elf_info)
+{
+	if (elf_is_64(elf_info) == 0) {
+		const Elf32_Ehdr *ehdr = elf_info;


I think we can ignore the compliance check failures for the camel case ELF header names. They are defined in the ELF spec this way.

edmooring · 2026-06-17T05:59:25Z

 #include <openamp/elf_loader.h>
 #include <openamp/remoteproc.h>

+static int elf_mul_size(size_t a, size_t b, size_t *out)


This applies to all the newly defined functions. They need Doxygen comments to describe them.

edmooring · 2026-06-17T06:03:25Z

+	return 0;
+}
+
+static int elf_range_in_chunk(size_t chunk_offset, size_t chunk_len,


This function really needs the Doxygen comment to describe its return values. I think it returns zero on success, -RPROC_EINVAL for overflows, and 1 for just wrong values. If this is the case, then why can't it just return -RPROC_EINVAL for all error cases? This would simplify the code flow for users of this function.

edmooring · 2026-06-17T06:03:58Z

 	}
 }

+static int elf_validate_header(const void *elf_info)


Doxygen comments would be nice.

edmooring · 2026-06-17T06:09:44Z

+						    shdrs_size);
+		if (range_in_chunk < 0)
+			return range_in_chunk;
+		if (!range_in_chunk) {


What happens if elf_range_in_chunk() returns 1? I think that means that the inputs are wrong, but don't overflow.

edmooring · 2026-06-17T06:23:43Z

+						    shstrtab_size);
+		if (range_in_chunk < 0)
+			return range_in_chunk;
+		if (!range_in_chunk) {


Again, what happens if elf_range_in_chunk() returns 1? Some values don't get assigned.

bentheredonethat · 2026-06-17T17:29:10Z

Hi @edmooring

Addressed in the updated series:

For the ELF type-name compliance findings, I left the Elf32_Ehdr, Elf64_Ehdr, and related ELF names unchanged.

Agreed that these come from the ELF spec and should not be renamed just to satisfy the camel-case check.

For the newly added helper functions, I added Doxygen comments. In particular, elf_range_in_chunk() now documents its return values explicitly:

1: the requested range is contained in the current image chunk
0: the requested range is not contained in the current image chunk
-RPROC_EINVAL: overflow occurred while calculating the checked range endpoints

So 0 is not the success case for this helper. It is the normal streaming-loader path where the range is not present in
the current chunk, and the caller should set *noffset / *nlen and request that range. Returning -RPROC_EINVAL for that case would incorrectly turn a valid “load another chunk” condition into a hard failure.

I also renamed the local variables at the call sites from range_in_chunk to range_loaded to make the control flow clearer. If elf_range_in_chunk() returns 1, the requested table/string table is already present in img_data, so the code intentionally falls through and proceeds to copy from the current chunk. In that path, *noffset and *nlen do ot need to be assigned because no additional chunk is being requested.

If it returns 0, the code assigns *noffset / *nlen and returns the current load state so the caller can fetch the missing range.

arnopo

minor comments .
@bentheredonethat: Did you try to verify with an IA if some other overflows are detected ?

bentheredonethat · 2026-06-24T13:43:07Z

minor comments . @bentheredonethat: Did you try to verify with an IA if some other overflows are detected ?

@arnopo can you please clarify what is meant by this ? i did some impact analysys by passing in overflowing values

arnopo · 2026-06-26T08:32:10Z

can you please clarify what is meant by this ? i did some impact analysys by passing in overflowing values

My point behind my question is the validation part. Could you share test you performed.
I wonder how we can ensure that we address all the vulnerability reported in https://www.sentinelone.com/vulnerability-database/cve-2026-37540/

nathalie-ckc · 2026-07-15T16:10:35Z

7/15/2026 OpenAMP System Reference call:
Since some fixes for ELF loader have been submitted, someone is potentially using it. So, we should fix this (but the CVE severity is believed to be over-stated), as opposed to deprecating ELF loader entirely.
Ben will be able to come back to this in a few weeks.
Team doesn't believe it's urgent - by 2026.10 release would be good.

bentheredonethat · 2026-07-16T21:01:37Z

can you please clarify what is meant by this ? i did some impact analysys by passing in overflowing values

My point behind my question is the validation part. Could you share test you performed. I wonder how we can ensure that we address all the vulnerability reported in https://www.sentinelone.com/vulnerability-database/cve-2026-37540/

I initially performed a functional regression test using a valid ELF image loaded by the R5 onto the A53. The image was parsed, loaded, and executed successfully. In addition, I performed negative tests with deliberately malformed ELF images covering the validation paths introduced by this series:

@arnopo below are additional tests performed:

invalid e_ehsize
invalid e_phentsize
invalid e_shentsize
out-of-range e_shstrndx
out-of-range program-header table offset/range
out-of-range section-header table offset/range
invalid section string-table offset/size
sh_name beyond the string-table boundary
section-name entry without an in-bounds NUL terminator

with latest tree. and AFAIK the earlier review comments have been addressed

arnopo

few proposal, on concern that can be addressed later, else close to be good to me

arnopo · 2026-07-21T11:30:19Z

 			memcpy(*img_info, img_data, tmpsize);
+			ret = elf_validate_header(*img_info);
+			if (ret < 0)
+				return ret;


img_info is never free, if allocated. But it seems that is it also the case for some other allocations. I'm ok that we address error management later, in such case please create an issue to log the issue.

bentheredonethat · 2026-07-21T15:10:51Z

@arnopo Thanks for the review and the proposed helpers. I updated the series accordingly.

The changes are split across their original commit boundaries:

Added generic checked addition, subtraction, and multiplication helpers.
Added a generic range-containment helper and replaced the misleading loaded terminology with contained.
Preserved the distinction between arithmetic overflow and an otherwise valid range that is not contained in the current image chunk. Overflow returns -RPROC_EINVAL; non-containment requests
another chunk.
Documented and implemented the ranges as half-open ranges.
Made the builtin and fallback arithmetic paths consistently reject negative inputs.
Added checked multiplication because the ELF program and section table sizes require it.
Updated the program-header, section-header, and section string-table checks to use the new helpers.

I also addressed the img_info cleanup concern directly. elf_load_header() now tracks whether the current invocation allocated img_info. If header validation fails, it frees and nulls only that
newly allocated object. A caller-provided object remains caller-owned, avoiding an unconditional free or double-free through the outer cleanup path.

I tested the updated series with:

A focused arithmetic and range test application, including overflow, underflow, negative operands, narrow output types, zero-length ranges, containment, and wrapping ranges.
A native OpenAMP static-library build using the staged libmetal headers.
An AArch64 cross-build using AMD GCC 15.3 and the supplied libmetal/sysroot.
checkpatch.pl across all seven commits.

All tests and builds passed, and checkpatch reports no errors or warnings.

arnopo · 2026-07-29T16:38:21Z

@bentheredonethat : need to address CI build issue

nathalie-ckc · 2026-08-12T16:08:04Z

8/12/26 System reference call: Ben to rebase to resolve the last remaining CI failure

Add generic checked addition, subtraction, and multiplication helpers with consistent input validation across builtin and fallback implementations. Add a generic range-containment helper which reports arithmetic overflow separately from non-containment. This lets the ELF loader distinguish malformed ranges from data absent from the current image chunk. Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>

arnopo

LGTM after removing the checkpatch.conf update

arnopo · 2026-08-28T09:19:41Z

 --ignore NEW_TYPEDEFS
--ignore ARRAY_SIZE
+--ignore ARRAY_SIZE
+--ignore CAMELCASE


I'm not in favor of adding this that will mask cameCase issue for the rest of the code.
Remove this and kust ignore the CI check patch issue for this PR. It is Ok for me to merge with the CI camel case issue reported.

@arnopo ok pushed with that as only change

Reject malformed ELF headers before using program or section table metadata from the firmware image. Validate the ELF class, ELF header size, program header entry size, section header entry size, and section string-table index. Release an image-info object allocated by this call if validation fails, while leaving caller-owned objects untouched. Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>

Use checked multiplication when computing ELF program and section header table sizes from e_phnum/e_phentsize and e_shnum/e_shentsize. Also replace wrapping offset-plus-length range checks with overflow-safe image chunk validation before allocation and memcpy. Malformed firmware images with impossible table sizes now fail with -RPROC_EINVAL. Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>

Use overflow-safe range validation before copying the ELF section string table from the firmware image. The section string-table offset and size are read from untrusted section headers. Validate that the full table is present in the current image chunk without relying on wrapping offset arithmetic. Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>

Store the loaded section string-table size in the ELF image information for both ELF32 and ELF64 images. Keeping the size alongside the string-table pointer allows later section name lookups to validate sh_name offsets against the actual loaded table bounds. Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>

Make ELF section-name lookup validate sh_name before reading from the loaded section string table. Skip malformed section names whose sh_name offset is outside the table or whose string is not NUL-terminated within the remaining table bytes. Use bounded comparison for valid candidates so .resource_table lookup cannot read past the loaded string table. Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>

Replace the non-seekable loader offset comparison that used offset + len with an overflow-safe equivalent. This preserves existing behavior for normal ranges while avoiding a wraparound case when deciding whether required image data is contiguous with the current chunk. Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>

arnopo · 2026-09-01T07:38:31Z

Checkpatch complains about camelcase. Ok to ignore for this PR

arnopo requested review from arnopo, edmooring and tnmysh June 2, 2026 09:07

edmooring requested changes Jun 17, 2026

View reviewed changes

bentheredonethat force-pushed the amd-elf-load-fixup-june-1-2026 branch from 064b04a to bbf3dfa Compare June 17, 2026 17:29

arnopo requested changes Jun 19, 2026

View reviewed changes

arnopo linked an issue Jun 26, 2026 that may be closed by this pull request

CVE-2026-37540 report: integer overflow vulnerability on ELF Loader #688

Open

arnopo added this to the Release V2026.10 milestone Jun 26, 2026

bentheredonethat force-pushed the amd-elf-load-fixup-june-1-2026 branch from bbf3dfa to 9413fbd Compare July 16, 2026 21:16

arnopo reviewed Jul 21, 2026

View reviewed changes

bentheredonethat force-pushed the amd-elf-load-fixup-june-1-2026 branch from 9413fbd to 89a9da4 Compare July 21, 2026 15:11

bentheredonethat force-pushed the amd-elf-load-fixup-june-1-2026 branch from 89a9da4 to 33b4756 Compare August 3, 2026 15:38

bentheredonethat force-pushed the amd-elf-load-fixup-june-1-2026 branch from 33b4756 to 3e0033e Compare August 12, 2026 16:24

bentheredonethat force-pushed the amd-elf-load-fixup-june-1-2026 branch from 3e0033e to 73c4330 Compare August 26, 2026 13:04

bentheredonethat force-pushed the amd-elf-load-fixup-june-1-2026 branch from 73c4330 to f4530ee Compare August 26, 2026 13:09

arnopo requested changes Aug 28, 2026

View reviewed changes

bentheredonethat added 5 commits August 28, 2026 07:19

bentheredonethat force-pushed the amd-elf-load-fixup-june-1-2026 branch from f4530ee to 5072f5e Compare August 28, 2026 14:22

arnopo approved these changes Sep 1, 2026

View reviewed changes

arnopo requested a review from edmooring September 7, 2026 15:54

Uh oh!

Conversation

bentheredonethat commented Jun 1, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bentheredonethat commented Jun 17, 2026

Uh oh!

arnopo left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

bentheredonethat commented Jun 24, 2026

Uh oh!

arnopo commented Jun 26, 2026

Uh oh!

nathalie-ckc commented Jul 15, 2026

Uh oh!

bentheredonethat commented Jul 16, 2026

Uh oh!

arnopo left a comment

Choose a reason for hiding this comment

Uh oh!

arnopo Jul 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

bentheredonethat commented Jul 21, 2026

Uh oh!

arnopo commented Jul 29, 2026

Uh oh!

nathalie-ckc commented Aug 12, 2026

Uh oh!

arnopo left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

arnopo commented Sep 1, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

arnopo left a comment •

edited

Loading

arnopo Jul 21, 2026 •

edited

Loading