Re: [PATCH 0/5] elf-parse: validate what the host ELF tools read from the file

[Leizhen Zhang <lzsx618@gmail.com>]

On Sun, 19 Oct 2026 08:57:54 -0400 Steven Rostedt <rostedt@goodmis.org> wrote:
> Definitely not a security threat here. If the object files are corrupted,
> then this is not where you should be detecting it. Unless we change the
> purpose of this tool as a corruption detector, this code *expects* the
> input to not be corrupt. The reasons for checking various ELF header info
> is if someone is porting this code to a new architecture where it doesn't
> support it yet, we want to warn.
>
> I'm fine with adding robustness, but not complexity for an issue that
> should never exist.

Understood, and thank you for being direct about it. You are right and I am
dropping most of this series.

To be clear about what I did and did not establish: every reproducer in the
series is a file I corrupted by hand, one field at a time. I never had a
legitimate object that triggers any of 2/5 through 5/5, and I should have
treated "I can only reach this by editing the file" as the answer rather
than as something for you to rule on. The cover letter asked you to review
the threat-model classification; your answer is that the classification is
not the interesting question, the premise is, and that is a fair correction.

So:

 - 2/5, 3/5, 4/5, 5/5: withdrawn. They buy nothing for a toolchain-produced
   object and, as you say, if the object is corrupt the build has already
   lost. I am not going to re-send them in another shape.

 - 1/5: I would like to keep this one, and I am sending a v2 that just
   deletes the comment you called useless. Not because of the fuzzer -- that
   one does not rest on a corrupt file at all. include/uapi/linux/elf.h
   declares

	#define ET_LOPROC 0xff00
	#define ET_HIPROC 0xffff

   so a well-formed processor-specific object, and anything in the
   0xfe00..0xfeff OS-specific range the spec reserves next to it, shifts by
   more than the width of int in

	if (!((1 << type) & types))

   The tools should and still do reject such a file; they just currently get
   there through undefined behaviour, and on a UBSan build that is a hard
   error rather than a clean "Invalid ELF type". That is a one-line fix with
   no added state and no new failure mode.

   If you would rather see even that as churn, say so and I will drop it too.

 - The separate sorttable and tracepoint-update patches are the same class of
   change as 2/5-5/5. I am withdrawing both; see the other mail for the
   tracepoint one.

On the "porting to a new architecture" purpose: that is useful to know and it
is not what I assumed the checks were for. It also explains why 1/5 is worth
keeping and the rest are not -- the type check is exactly the warn-on-port
path, and it should not be the thing that trips UBSan.

Sorry for the noise on the other four.