On Fri, 8 Feb 2008, Abel Bernabeu wrote:
> What is the official forum to report bugs in the kernel?
Hi Abel,
lkml is the most official forum you can find.
> I've making some testing of the elf loader in my host system (an x86
> PC with Linux version 2.6.18)... and I have finally found a bug.
> The elf loader does not always return the correct error code when
> trying to load incorrect binaries.
> The execution with 2 badly formed elf binaries leads to different error codes:
[ ... ]
> # ls ./bb386 ./bb386nc
> ./bb386 ./bb386nc <------ Both files exist!!
> # ./execve ./bb386
> Executing ./bb386
> The result of exec is 2 <--------- Bad!!
> # ./execve ./bb386nc
> Executing ./bb386nc
> The result of exec is 8
> Execve should return 8 in both cases.
> I attach the two binaries so anyone familiar with the elf loader can
> try to figure out the problem... I can supply some details about how I
> produced the binaries if needed.
Well, bb386nc has its e_flags set to 0x2, which means that the binary is
of type EF_BFIN_FDPIC.
The fdpic handler returns ENOENT if the PT_INTERP field of the binary is
malformed, which is what you are probabling hitting here:
retval = -ENOENT;
if (interpreter_name[phdr->p_filesz - 1] != '\0')
goto error;
The 'standard' ELF binary handler returns ENOEXEC in such cases, and this
is the difference you are seeing here.
I basically think that both errnos are allowed here:
ENOENT The file filename or a script or ELF interpreter does not exist, or
a shared library needed for file or interpreter cannot be found.
ENOEXEC An executable is not in a recognized format, is for the wrong
architecture, or has some other format error that means it cannot be
executed.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
