linux-kernel - RFC: possible bug in load_elf

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <46E5B6FA.7000902@nortel.com>
Date:	Mon, 10 Sep 2007 15:28:26 -0600
From:	"Chris Friesen" <cfriesen@...tel.com>
To:	linux-kernel@...r.kernel.org
Subject: RFC: possible bug in load_elf_binary

Hi,

We've got an unusual elf binary and we seem to be running into a bug in 
the elf loader.  I'm not an elf expert, so my apologies if I get the 
terminology wrong.

The elf spec says that PT_LOAD segments must be ordered by vaddr.  We 
want to have a segment at a relatively low fixed vaddr.  The exact 
address is not important, except that it's lower than the standard elf 
headers and so it must be the first segment in the elf file.

However, this segment also has no size in the file...it's basically all 
statically allocated at runtime.

In the kernel elf loader, the p_vaddr and p_offset of the first segment 
are used to determine the load_addr for use with the rest of the 
segments.  In the case of this elf file, the first segment does not 
actually have a valid p_offset.

Anyone have any suggestions on how to deal with this?  One crude hack we 
considered was to simply not set the load_addr if the first segment 
doesn't have a valid p_offset, but that doesn't solve the general case.

Thanks,

Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/