* [PATCH] erofs-utils: fsck: check symlink size before allocation
@ 2026-03-21 18:36 Vansh Choudhary
2026-03-23 3:32 ` Nithurshen
0 siblings, 1 reply; 3+ messages in thread
From: Vansh Choudhary @ 2026-03-21 18:36 UTC (permalink / raw)
To: linux-erofs; +Cc: Vansh Choudhary
erofs_extract_symlink() uses inode->i_size to allocate a buffer for
the symlink target and then appends a trailing NUL byte.
Reject symlink sizes larger than SIZE_MAX - 1 before allocating the
buffer so malformed images cannot overflow the allocation size.
Return -EOVERFLOW for this case and keep the existing extraction flow
unchanged otherwise.
Signed-off-by: Vansh Choudhary <ch@vnsh.in>
---
fsck/main.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/fsck/main.c b/fsck/main.c
index 16a354f..1254112 100644
--- a/fsck/main.c
+++ b/fsck/main.c
@@ -4,6 +4,7 @@
* Author: Daeho Jeong <daehojeong@google.com>
*/
#include <stdlib.h>
+#include <stdint.h>
#include <getopt.h>
#include <time.h>
#include <utime.h>
@@ -794,6 +795,13 @@ static inline int erofs_extract_symlink(struct erofs_inode *inode)
if (ret)
return ret;
+ if (inode->i_size > SIZE_MAX - 1) {
+ erofs_err("symlink size %" PRIu64 " is too large @ nid %llu",
+ inode->i_size, inode->nid | 0ULL);
+ ret = -EOVERFLOW;
+ goto out;
+ }
+
buf = malloc(inode->i_size + 1);
if (!buf) {
ret = -ENOMEM;
--
2.43.0
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] erofs-utils: fsck: check symlink size before allocation
2026-03-21 18:36 [PATCH] erofs-utils: fsck: check symlink size before allocation Vansh Choudhary
@ 2026-03-23 3:32 ` Nithurshen
2026-03-23 3:36 ` Gao Xiang
0 siblings, 1 reply; 3+ messages in thread
From: Nithurshen @ 2026-03-23 3:32 UTC (permalink / raw)
To: ch; +Cc: linux-erofs, xiang, Nithurshen
Hi Xiang,
This patch LGTM.
I manually verified this by compiling with `-O0 -g` on macOS (arm64)
and using lldb for fault injection. I stepped through
erofs_extract_symlink() and allowed erofs_verify_inode_data() to pass
with normal metadata. Right before the buffer allocation, I artificially
inflated inode->i_size to 0xffffffffffffffff (SIZE_MAX).
Without the patch, bypassing the OS read limits with this size causes
a predictable heap buffer overflow and an EXC_BAD_ACCESS crash. With
the patch applied, the bounds check successfully catches the malformed
size, gracefully bails out with -EOVERFLOW, and prevents the memory
corruption.
Tested-by: Nithurshen <nithurshen.dev@gmail.com>
Reviewed-by: Nithurshen <nithurshen.dev@gmail.com>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] erofs-utils: fsck: check symlink size before allocation
2026-03-23 3:32 ` Nithurshen
@ 2026-03-23 3:36 ` Gao Xiang
0 siblings, 0 replies; 3+ messages in thread
From: Gao Xiang @ 2026-03-23 3:36 UTC (permalink / raw)
To: Nithurshen, ch; +Cc: linux-erofs, xiang
On 2026/3/23 11:32, Nithurshen wrote:
> Hi Xiang,
>
> This patch LGTM.
>
> I manually verified this by compiling with `-O0 -g` on macOS (arm64)
> and using lldb for fault injection. I stepped through
> erofs_extract_symlink() and allowed erofs_verify_inode_data() to pass
> with normal metadata. Right before the buffer allocation, I artificially
> inflated inode->i_size to 0xffffffffffffffff (SIZE_MAX).
>
> Without the patch, bypassing the OS read limits with this size causes
> a predictable heap buffer overflow and an EXC_BAD_ACCESS crash. With
> the patch applied, the bounds check successfully catches the malformed
> size, gracefully bails out with -EOVERFLOW, and prevents the memory
> corruption.
This patch doesn't look good to me.
I will submit another patch instead.
>
> Tested-by: Nithurshen <nithurshen.dev@gmail.com>
> Reviewed-by: Nithurshen <nithurshen.dev@gmail.com>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-03-23 3:36 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-03-21 18:36 [PATCH] erofs-utils: fsck: check symlink size before allocation Vansh Choudhary
2026-03-23 3:32 ` Nithurshen
2026-03-23 3:36 ` Gao Xiang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox