These patches fix a bug in AT_PHDR calculation.
We cannot calculate AT_PHDR as the sum of load_addr and exec->e_phoff.
This is because exec->e_phoff is the offset of PHDRs in the file and the
address of PHDRs in the memory may differ from it. These patches fix the
bug by calculating the address of program headers from PT_LOADs
directly.
Sorry for my latency.
Changes in v4
- Reflecting comments from Lukas, add a refactoring commit.
Changes in v3:
- Fix a reported bug from kernel test robot.
Changes in v2:
- Remove unused load_addr from create_elf_tables.
- Improve the commit message.
Akira Kawata (2):
fs/binfmt_elf: Fix AT_PHDR for unusual ELF files
fs/binfmt_elf: Refactor load_elf_binary function
fs/binfmt_elf.c | 36 +++++++++++++++++++++---------------
1 file changed, 21 insertions(+), 15 deletions(-)
base-commit: 4eee8d0b64ecc3231040fa68ba750317ffca5c52
--
2.34.1
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=197921
As pointed out in the discussion of buglink, we cannot calculate AT_PHDR
as the sum of load_addr and exec->e_phoff.
: The AT_PHDR of ELF auxiliary vectors should point to the memory address
: of program header. But binfmt_elf.c calculates this address as follows:
:
: NEW_AUX_ENT(AT_PHDR, load_addr + exec->e_phoff);
:
: which is wrong since e_phoff is the file offset of program header and
: load_addr is the memory base address from PT_LOAD entry.
:
: The ld.so uses AT_PHDR as the memory address of program header. In normal
: case, since the e_phoff is usually 64 and in the first PT_LOAD region, it
: is the correct program header address.
:
: But if the address of program header isn't equal to the first PT_LOAD
: address + e_phoff (e.g. Put the program header in other non-consecutive
: PT_LOAD region), ld.so will try to read program header from wrong address
: then crash or use incorrect program header.
This is because exec->e_phoff
is the offset of PHDRs in the file and the address of PHDRs in the
memory may differ from it. This patch fixes the bug by calculating the
address of program headers from PT_LOADs directly.
Signed-off-by: Akira Kawata <redacted>
Reported-by: kernel test robot <redacted>
---
fs/binfmt_elf.c | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
@@ -170,8 +170,8 @@ static int padzero(unsigned long elf_bss)staticintcreate_elf_tables(structlinux_binprm*bprm,conststructelfhdr*exec,-unsignedlongload_addr,unsignedlonginterp_load_addr,-unsignedlonge_entry)+unsignedlonginterp_load_addr,+unsignedlonge_entry,unsignedlongphdr_addr){structmm_struct*mm=current->mm;unsignedlongp=bprm->p;
I delete load_addr because it is not used anymore. And I rename
load_addr_set to first_pt_load because it is used only to capture the
first iteration of the loop.
Signed-off-by: Akira Kawata <redacted>
---
fs/binfmt_elf.c | 18 ++++++++----------
1 file changed, 8 insertions(+), 10 deletions(-)
These patches fix a bug in AT_PHDR calculation.
We cannot calculate AT_PHDR as the sum of load_addr and exec->e_phoff.
This is because exec->e_phoff is the offset of PHDRs in the file and the
address of PHDRs in the memory may differ from it. These patches fix the
bug by calculating the address of program headers from PT_LOADs
directly.
Sorry for my latency.
Changes in v4
- Reflecting comments from Lukas, add a refactoring commit.
Changes in v3:
- Fix a reported bug from kernel test robot.
Changes in v2:
- Remove unused load_addr from create_elf_tables.
- Improve the commit message.
Akira Kawata (2):
fs/binfmt_elf: Fix AT_PHDR for unusual ELF files
fs/binfmt_elf: Refactor load_elf_binary function
fs/binfmt_elf.c | 36 +++++++++++++++++++++---------------
1 file changed, 21 insertions(+), 15 deletions(-)
base-commit: 4eee8d0b64ecc3231040fa68ba750317ffca5c52
--
2.34.1
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=197921
As pointed out in the discussion of buglink, we cannot calculate AT_PHDR
as the sum of load_addr and exec->e_phoff.
: The AT_PHDR of ELF auxiliary vectors should point to the memory address
: of program header. But binfmt_elf.c calculates this address as follows:
:
: NEW_AUX_ENT(AT_PHDR, load_addr + exec->e_phoff);
:
: which is wrong since e_phoff is the file offset of program header and
: load_addr is the memory base address from PT_LOAD entry.
:
: The ld.so uses AT_PHDR as the memory address of program header. In normal
: case, since the e_phoff is usually 64 and in the first PT_LOAD region, it
: is the correct program header address.
:
: But if the address of program header isn't equal to the first PT_LOAD
: address + e_phoff (e.g. Put the program header in other non-consecutive
: PT_LOAD region), ld.so will try to read program header from wrong address
: then crash or use incorrect program header.
This is because exec->e_phoff
is the offset of PHDRs in the file and the address of PHDRs in the
memory may differ from it. This patch fixes the bug by calculating the
address of program headers from PT_LOADs directly.
Signed-off-by: Akira Kawata <redacted>
Reported-by: kernel test robot <redacted>
---
fs/binfmt_elf.c | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
@@ -170,8 +170,8 @@ static int padzero(unsigned long elf_bss)staticintcreate_elf_tables(structlinux_binprm*bprm,conststructelfhdr*exec,-unsignedlongload_addr,unsignedlonginterp_load_addr,-unsignedlonge_entry)+unsignedlonginterp_load_addr,+unsignedlonge_entry,unsignedlongphdr_addr){structmm_struct*mm=current->mm;unsignedlongp=bprm->p;
I delete load_addr because it is not used anymore. And I rename
load_addr_set to first_pt_load because it is used only to capture the
first iteration of the loop.
Signed-off-by: Akira Kawata <redacted>
---
fs/binfmt_elf.c | 18 ++++++++----------
1 file changed, 8 insertions(+), 10 deletions(-)
On Mon, Dec 13, 2021 at 08:24:13AM +0900, Akira Kawata wrote:
These patches fix a bug in AT_PHDR calculation.
We cannot calculate AT_PHDR as the sum of load_addr and exec->e_phoff.
This is because exec->e_phoff is the offset of PHDRs in the file and the
address of PHDRs in the memory may differ from it. These patches fix the
bug by calculating the address of program headers from PT_LOADs
directly.
Sorry for my latency.
Changes in v4
- Reflecting comments from Lukas, add a refactoring commit.
Changes in v3:
- Fix a reported bug from kernel test robot.
Changes in v2:
- Remove unused load_addr from create_elf_tables.
- Improve the commit message.
Akira Kawata (2):
fs/binfmt_elf: Fix AT_PHDR for unusual ELF files
fs/binfmt_elf: Refactor load_elf_binary function
fs/binfmt_elf.c | 36 +++++++++++++++++++++---------------
1 file changed, 21 insertions(+), 15 deletions(-)
base-commit: 4eee8d0b64ecc3231040fa68ba750317ffca5c52
--
2.34.1
I am sorry for sending duplicated emails by mistake.
Please ignore the later ones.
Akira
On Mon, Dec 13, 2021 at 08:24:11AM +0900, Akira Kawata wrote:
quoted hunk
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=197921
As pointed out in the discussion of buglink, we cannot calculate AT_PHDR
as the sum of load_addr and exec->e_phoff.
: The AT_PHDR of ELF auxiliary vectors should point to the memory address
: of program header. But binfmt_elf.c calculates this address as follows:
:
: NEW_AUX_ENT(AT_PHDR, load_addr + exec->e_phoff);
:
: which is wrong since e_phoff is the file offset of program header and
: load_addr is the memory base address from PT_LOAD entry.
:
: The ld.so uses AT_PHDR as the memory address of program header. In normal
: case, since the e_phoff is usually 64 and in the first PT_LOAD region, it
: is the correct program header address.
:
: But if the address of program header isn't equal to the first PT_LOAD
: address + e_phoff (e.g. Put the program header in other non-consecutive
: PT_LOAD region), ld.so will try to read program header from wrong address
: then crash or use incorrect program header.
This is because exec->e_phoff
is the offset of PHDRs in the file and the address of PHDRs in the
memory may differ from it. This patch fixes the bug by calculating the
address of program headers from PT_LOADs directly.
Signed-off-by: Akira Kawata <redacted>
Reported-by: kernel test robot <redacted>
---
fs/binfmt_elf.c | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
@@ -170,8 +170,8 @@ static int padzero(unsigned long elf_bss)staticintcreate_elf_tables(structlinux_binprm*bprm,conststructelfhdr*exec,-unsignedlongload_addr,unsignedlonginterp_load_addr,-unsignedlonge_entry)+unsignedlonginterp_load_addr,+unsignedlonge_entry,unsignedlongphdr_addr){structmm_struct*mm=current->mm;unsignedlongp=bprm->p;
@@ -822,7 +822,7 @@ static int parse_elf_properties(struct file *f, const struct elf_phdr *phdr,staticintload_elf_binary(structlinux_binprm*bprm){structfile*interpreter=NULL;/* to shut gcc up */-unsignedlongload_addr=0,load_bias=0;+unsignedlongload_addr,load_bias=0,phdr_addr=0;intload_addr_set=0;unsignedlongerror;structelf_phdr*elf_ppnt,*elf_phdata,*interp_elf_phdata=NULL;
@@ -1168,6 +1168,13 @@ static int load_elf_binary(struct linux_binprm *bprm)reloc_func_desc=load_bias;}}++if(elf_ppnt->p_offset<=elf_ex->e_phoff&&+elf_ex->e_phoff<elf_ppnt->p_offset+elf_ppnt->p_filesz){+phdr_addr=elf_ex->e_phoff-elf_ppnt->p_offset++elf_ppnt->p_vaddr;+}
This chunk could really use a comment above it. Maybe something like:
/*
* Figure out which segment in the file contains the Program
* Header table, and map to the associated memory address.
*/
Some additional thoughts:
1) The ELF spec says e_phoff is 0 if there's no program header table.
The old code would just pass the load_addr as a result. This patch will
now retain the same result (phdr_addr defaults to 0). I wonder if there
is a bug in this behavior, though? (To be addressed in a different patch
if needed...)
2) This finds any matching segment, not just PT_PHDR, which is good,
since PT_PHDR isn't strictly required.
quoted hunk
+ k = elf_ppnt->p_vaddr; if ((elf_ppnt->p_flags & PF_X) && k < start_code) start_code = k;
On Mon, Dec 13, 2021 at 08:24:12AM +0900, Akira Kawata wrote:
I delete load_addr because it is not used anymore. And I rename
load_addr_set to first_pt_load because it is used only to capture the
first iteration of the loop.
Signed-off-by: Akira Kawata <redacted>
Thanks for splitting this out. :)
Acked-by: Kees Cook <redacted>
--
Kees Cook
On Wed, Jan 26, 2022 at 09:01:30PM -0800, Kees Cook wrote:
On Mon, Dec 13, 2021 at 08:24:11AM +0900, Akira Kawata wrote:
quoted
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=197921
As pointed out in the discussion of buglink, we cannot calculate AT_PHDR
as the sum of load_addr and exec->e_phoff.
: The AT_PHDR of ELF auxiliary vectors should point to the memory address
: of program header. But binfmt_elf.c calculates this address as follows:
:
: NEW_AUX_ENT(AT_PHDR, load_addr + exec->e_phoff);
:
: which is wrong since e_phoff is the file offset of program header and
: load_addr is the memory base address from PT_LOAD entry.
:
: The ld.so uses AT_PHDR as the memory address of program header. In normal
: case, since the e_phoff is usually 64 and in the first PT_LOAD region, it
: is the correct program header address.
:
: But if the address of program header isn't equal to the first PT_LOAD
: address + e_phoff (e.g. Put the program header in other non-consecutive
: PT_LOAD region), ld.so will try to read program header from wrong address
: then crash or use incorrect program header.
This is because exec->e_phoff
is the offset of PHDRs in the file and the address of PHDRs in the
memory may differ from it. This patch fixes the bug by calculating the
address of program headers from PT_LOADs directly.
Signed-off-by: Akira Kawata <redacted>
Reported-by: kernel test robot <redacted>
---
fs/binfmt_elf.c | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
@@ -170,8 +170,8 @@ static int padzero(unsigned long elf_bss)staticintcreate_elf_tables(structlinux_binprm*bprm,conststructelfhdr*exec,-unsignedlongload_addr,unsignedlonginterp_load_addr,-unsignedlonge_entry)+unsignedlonginterp_load_addr,+unsignedlonge_entry,unsignedlongphdr_addr){structmm_struct*mm=current->mm;unsignedlongp=bprm->p;
@@ -822,7 +822,7 @@ static int parse_elf_properties(struct file *f, const struct elf_phdr *phdr,staticintload_elf_binary(structlinux_binprm*bprm){structfile*interpreter=NULL;/* to shut gcc up */-unsignedlongload_addr=0,load_bias=0;+unsignedlongload_addr,load_bias=0,phdr_addr=0;intload_addr_set=0;unsignedlongerror;structelf_phdr*elf_ppnt,*elf_phdata,*interp_elf_phdata=NULL;
@@ -1168,6 +1168,13 @@ static int load_elf_binary(struct linux_binprm *bprm)reloc_func_desc=load_bias;}}++if(elf_ppnt->p_offset<=elf_ex->e_phoff&&+elf_ex->e_phoff<elf_ppnt->p_offset+elf_ppnt->p_filesz){+phdr_addr=elf_ex->e_phoff-elf_ppnt->p_offset++elf_ppnt->p_vaddr;+}
This chunk could really use a comment above it. Maybe something like:
/*
* Figure out which segment in the file contains the Program
* Header table, and map to the associated memory address.
*/
Thank you. It looks good to me. I made v5 which contains it.
Some additional thoughts:
1) The ELF spec says e_phoff is 0 if there's no program header table.
The old code would just pass the load_addr as a result. This patch will
now retain the same result (phdr_addr defaults to 0). I wonder if there
is a bug in this behavior, though? (To be addressed in a different patch
if needed...)
It is better to return NULL from load_elf_phdrs when e_phoff == 0, I
think.
2) This finds any matching segment, not just PT_PHDR, which is good,
since PT_PHDR isn't strictly required.
quoted
+ k = elf_ppnt->p_vaddr; if ((elf_ppnt->p_flags & PF_X) && k < start_code) start_code = k;
On Thu, Jan 27, 2022 at 09:56:43PM +0900, Akira Kawata wrote:
On Wed, Jan 26, 2022 at 09:01:30PM -0800, Kees Cook wrote:
quoted
[...]
1) The ELF spec says e_phoff is 0 if there's no program header table.
The old code would just pass the load_addr as a result. This patch will
now retain the same result (phdr_addr defaults to 0). I wonder if there
is a bug in this behavior, though? (To be addressed in a different patch
if needed...)
It is better to return NULL from load_elf_phdrs when e_phoff == 0, I
think.
Yeah, right now it just returns a pointer to file offset 0.
I also wonder if we should sanity-check e_phoff vs PT_PHDR? Right now
Linux ignores PT_PHDR. Should we reject loading when e_phoff != PT_PHDR
file offset? (And I wonder if there are "broken" binaries right now that
have bad PT_PHDR segments that have gone unnoticed...)
And now I'm thinking about the excellent ELF loading analysis at:
https://nathanotterness.com/2021/10/tiny_elf_modernized.html
;)
--
Kees Cook
On Thu, Jan 27, 2022 at 08:23:51AM -0800, Kees Cook wrote:
On Thu, Jan 27, 2022 at 09:56:43PM +0900, Akira Kawata wrote:
quoted
On Wed, Jan 26, 2022 at 09:01:30PM -0800, Kees Cook wrote:
quoted
[...]
1) The ELF spec says e_phoff is 0 if there's no program header table.
The old code would just pass the load_addr as a result. This patch will
now retain the same result (phdr_addr defaults to 0). I wonder if there
is a bug in this behavior, though? (To be addressed in a different patch
if needed...)
It is better to return NULL from load_elf_phdrs when e_phoff == 0, I
think.
Yeah, right now it just returns a pointer to file offset 0.
I also wonder if we should sanity-check e_phoff vs PT_PHDR? Right now
Linux ignores PT_PHDR. Should we reject loading when e_phoff != PT_PHDR
file offset? (And I wonder if there are "broken" binaries right now that
have bad PT_PHDR segments that have gone unnoticed...)
I agree that unnoticed broken binaries exist. I checked glibc rtld and
there is no check of e_phoff != PT_PHDR file offset.