Re: [SECURITY] e2fsprogs v1.47.4 Vulnerabilities — Orphan File & Extent Handling

["Theodore Tso" <tytso@mit.edu>]

On Fri, Apr 03, 2026 at 10:17:38AM -0600, Andreas Dilger wrote:
> 
> I don't see how this exposes any kind of security vulnerability if it
> requires that the image be specially modified in the first place?
> At that point the "attacker" can directly modify the image in any way
> they want, regardless of how e2fsprogs behaves.

After taking a closer look the "vulnerabilities", I understand where
Andreas is coming from.  If the threat model is "the attacker can
modify the file system, then the fact that you can craft the orphan to
"force" the the file system to release an inode isn't interesting ---
because the attacker could just simply overwrite the inode and mark
the blocks as not in use in the block allocation directly.

If there was a way an attempt to pass an inode number which is very
large to release_orphan_inode() could result in a buffer overrun, then
that might be interesting.  But the oh, nooes!  You might be able to
force the file system to release the resize inode is not interesting;
the attacker could just stomp on the resize inode directly.

Should we add some better bounds checking?  Sure, so that we can give
a more user-friendly error message, and reduce the chance of
accidentally making things worse if the file system is corrupted by
chance and metadata checksum is not enabled.  But is it a "security
vulnerability"?  No.

No, if you could actually force a malicious payload to run due to a
stack overrun attack, that would be interesting.  And I was expecting
to find *something* like that in your analysis, only to be
disappointed.

Cheers,

					- Ted