* [PATCH v4] of: fdt: fix possible overflow during parsing of fdt
@ 2024-11-14 15:51 Abdelrahman Youssef
2024-11-14 16:39 ` Jules Maselbas
0 siblings, 1 reply; 3+ messages in thread
From: Abdelrahman Youssef @ 2024-11-14 15:51 UTC (permalink / raw)
To: s.hauer; +Cc: barebox, Abdelrahman Youssef
While fuzzing, the name marked by FDT_BEGIN_NODE sometimes extends beyond
the struct block area, causing a heap-overflow.
Since `maxlen` is an unsigned integer representing the length of name,
It can be negative, so it overflows to large numbers, Causing strnlen()
to overflow.
So we can just change the type of maxlen to signed and check if it's a
non-positive value, because name has a minimum length of 1 byte ('\0').
Also in strnlen() we shouldn't check for bytes exceeding maxlen, so we can remove
+ 1 in strnlen(). We also change if (len > maxlen) to >= to count for the null
terminator.
Signed-off-by: Abdelrahman Youssef <abdelrahmanyossef12@gmail.com>
---
v3 -> v4:
- replace maxlen < 0 to maxlen <= 0 (Sascha)
- remove + 1 in strnlen() (Sascha)
v2 -> v3
- changed formatting
v1 -> v2
- the overflow was due to integer overflow not out-of-bounds (Ahmad)
---
drivers/of/fdt.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 2c3ea31394..75af1844f3 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -176,7 +176,7 @@ static struct device_node *__of_unflatten_dtb(const void *infdt, int size,
void *dt_strings;
struct fdt_header f;
int ret;
- unsigned int maxlen;
+ int maxlen;
const struct fdt_header *fdt = infdt;
ret = fdt_parse_header(infdt, size, &f);
@@ -210,8 +210,13 @@ static struct device_node *__of_unflatten_dtb(const void *infdt, int size,
maxlen = (unsigned long)fdt + f.off_dt_struct +
f.size_dt_struct - (unsigned long)name;
- len = strnlen(name, maxlen + 1);
- if (len > maxlen) {
+ if (maxlen <= 0) {
+ ret = -ESPIPE;
+ goto err;
+ }
+
+ len = strnlen(name, maxlen);
+ if (len >= maxlen) {
ret = -ESPIPE;
goto err;
}
--
2.43.0
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH v4] of: fdt: fix possible overflow during parsing of fdt
2024-11-14 15:51 [PATCH v4] of: fdt: fix possible overflow during parsing of fdt Abdelrahman Youssef
@ 2024-11-14 16:39 ` Jules Maselbas
[not found] ` <CABwgSGY3SQGUoc3xY9XVX3aHwRV6s5xFuKABtgCf0vT26-1=_Q@mail.gmail.com>
0 siblings, 1 reply; 3+ messages in thread
From: Jules Maselbas @ 2024-11-14 16:39 UTC (permalink / raw)
To: barebox, Abdelrahman Youssef, s.hauer
Hi Abdelrahman,
just a remark, nothing wrong with your patch
On November 14, 2024 4:51:14 PM GMT+01:00, Abdelrahman Youssef <abdelrahmanyossef12@gmail.com> wrote:
>While fuzzing, the name marked by FDT_BEGIN_NODE sometimes extends beyond
>the struct block area, causing a heap-overflow.
>
>Since `maxlen` is an unsigned integer representing the length of name,
>It can be negative, so it overflows to large numbers, Causing strnlen()
>to overflow.
>
>So we can just change the type of maxlen to signed and check if it's a
>non-positive value, because name has a minimum length of 1 byte ('\0').
>
>Also in strnlen() we shouldn't check for bytes exceeding maxlen, so we can remove
>+ 1 in strnlen(). We also change if (len > maxlen) to >= to count for the null
>terminator.
>
>Signed-off-by: Abdelrahman Youssef <abdelrahmanyossef12@gmail.com>
>
>---
>v3 -> v4:
> - replace maxlen < 0 to maxlen <= 0 (Sascha)
> - remove + 1 in strnlen() (Sascha)
>v2 -> v3
> - changed formatting
>v1 -> v2
> - the overflow was due to integer overflow not out-of-bounds (Ahmad)
>---
> drivers/of/fdt.c | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
>diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
>index 2c3ea31394..75af1844f3 100644
>--- a/drivers/of/fdt.c
>+++ b/drivers/of/fdt.c
>@@ -176,7 +176,7 @@ static struct device_node *__of_unflatten_dtb(const void *infdt, int size,
> void *dt_strings;
> struct fdt_header f;
> int ret;
>- unsigned int maxlen;
>+ int maxlen;
> const struct fdt_header *fdt = infdt;
>
> ret = fdt_parse_header(infdt, size, &f);
>@@ -210,8 +210,13 @@ static struct device_node *__of_unflatten_dtb(const void *infdt, int size,
> maxlen = (unsigned long)fdt + f.off_dt_struct +
> f.size_dt_struct - (unsigned long)name;
>
>- len = strnlen(name, maxlen + 1);
>- if (len > maxlen) {
>+ if (maxlen <= 0) {
>+ ret = -ESPIPE;
>+ goto err;
>+ }
>+
>+ len = strnlen(name, maxlen);
>+ if (len >= maxlen) {
here len cannot exceed maxlen, but if len == maxlen this means that there is not nul-byte in the name array (up to maxlen).
by not passing maxlen + 1 there is a slight behavior change but i don't know if this an issus or not.
in the previous case strnlen could read one past maxlen which is suspicious (maybe a bug)
> ret = -ESPIPE;
> goto err;
> }
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH v4] of: fdt: fix possible overflow during parsing of fdt
[not found] ` <CABwgSGYcFoMncRWoyOjG19K2GiuMjrEomNGvG3E2fEX3wiM=RA@mail.gmail.com>
@ 2024-11-14 17:50 ` AbdelRahman Yossef
0 siblings, 0 replies; 3+ messages in thread
From: AbdelRahman Yossef @ 2024-11-14 17:50 UTC (permalink / raw)
To: barebox, Sascha Hauer
Hi Jules,
I think everything you said is correct, except just the last line
because strnlen
returns the minimum of the length of the string and maxlength + 1 (It
will not access forbidden location).
So in my opinion it's not a bug or suspicious but only unnecessary.
Cheers,
Abdelrahman
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-11-14 17:51 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-11-14 15:51 [PATCH v4] of: fdt: fix possible overflow during parsing of fdt Abdelrahman Youssef
2024-11-14 16:39 ` Jules Maselbas
[not found] ` <CABwgSGY3SQGUoc3xY9XVX3aHwRV6s5xFuKABtgCf0vT26-1=_Q@mail.gmail.com>
[not found] ` <CABwgSGYcFoMncRWoyOjG19K2GiuMjrEomNGvG3E2fEX3wiM=RA@mail.gmail.com>
2024-11-14 17:50 ` AbdelRahman Yossef
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox