* [PATCH] ubifs: Fix out-of-bounds memory access caused by abnormal value of node_len
@ 2020-01-16 15:36 Liu Song
2020-03-30 21:31 ` Richard Weinberger
0 siblings, 1 reply; 2+ messages in thread
From: Liu Song @ 2020-01-16 15:36 UTC (permalink / raw)
To: richard; +Cc: linux-mtd, linux-kernel, liu.song11
From: Liu Song <liu.song11@zte.com.cn>
In “ubifs_check_node”, when the value of "node_len" is abnormal,
the code will goto label of "out_len" for execution. Then, in the
following "ubifs_dump_node", if inode type is "UBIFS_DATA_NODE",
in "print_hex_dump", an out-of-bounds access may occur due to the
wrong "ch->len".
Therefore, when the value of "node_len" is abnormal, data length
should to be adjusted to a reasonable safe range. At this time,
structured data is not credible, so dump the corrupted data directly
for analysis.
Signed-off-by: Liu Song <liu.song11@zte.com.cn>
---
fs/ubifs/io.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/fs/ubifs/io.c b/fs/ubifs/io.c
index 8ceb51478800..7e4bfaf2871f 100644
--- a/fs/ubifs/io.c
+++ b/fs/ubifs/io.c
@@ -225,7 +225,7 @@ int ubifs_is_mapped(const struct ubifs_info *c, int lnum)
int ubifs_check_node(const struct ubifs_info *c, const void *buf, int lnum,
int offs, int quiet, int must_chk_crc)
{
- int err = -EINVAL, type, node_len;
+ int err = -EINVAL, type, node_len, dump_node = 1;
uint32_t crc, node_crc, magic;
const struct ubifs_ch *ch = buf;
@@ -278,10 +278,22 @@ int ubifs_check_node(const struct ubifs_info *c, const void *buf, int lnum,
out_len:
if (!quiet)
ubifs_err(c, "bad node length %d", node_len);
+ if (type == UBIFS_DATA_NODE && node_len > UBIFS_DATA_NODE_SZ)
+ dump_node = 0;
out:
if (!quiet) {
ubifs_err(c, "bad node at LEB %d:%d", lnum, offs);
- ubifs_dump_node(c, buf);
+ if (dump_node) {
+ ubifs_dump_node(c, buf);
+ } else {
+ int safe_len = min3(node_len, c->leb_size - offs,
+ (int)UBIFS_MAX_DATA_NODE_SZ);
+ pr_err("\tprevent out-of-bounds memory access\n");
+ pr_err("\ttruncated data node length %d\n", safe_len);
+ pr_err("\tcorrupted data node:\n");
+ print_hex_dump(KERN_ERR, "\t", DUMP_PREFIX_OFFSET, 32, 1,
+ buf, safe_len, 0);
+ }
dump_stack();
}
return err;
--
2.20.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH] ubifs: Fix out-of-bounds memory access caused by abnormal value of node_len
2020-01-16 15:36 [PATCH] ubifs: Fix out-of-bounds memory access caused by abnormal value of node_len Liu Song
@ 2020-03-30 21:31 ` Richard Weinberger
0 siblings, 0 replies; 2+ messages in thread
From: Richard Weinberger @ 2020-03-30 21:31 UTC (permalink / raw)
To: Liu Song; +Cc: Richard Weinberger, linux-mtd, LKML, liu.song11
On Thu, Jan 16, 2020 at 4:37 PM Liu Song <fishland@aliyun.com> wrote:
>
> From: Liu Song <liu.song11@zte.com.cn>
>
> In “ubifs_check_node”, when the value of "node_len" is abnormal,
> the code will goto label of "out_len" for execution. Then, in the
> following "ubifs_dump_node", if inode type is "UBIFS_DATA_NODE",
> in "print_hex_dump", an out-of-bounds access may occur due to the
> wrong "ch->len".
>
> Therefore, when the value of "node_len" is abnormal, data length
> should to be adjusted to a reasonable safe range. At this time,
> structured data is not credible, so dump the corrupted data directly
> for analysis.
>
> Signed-off-by: Liu Song <liu.song11@zte.com.cn>
Applied, thanks!
--
Thanks,
//richard
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2020-03-30 21:31 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-16 15:36 [PATCH] ubifs: Fix out-of-bounds memory access caused by abnormal value of node_len Liu Song
2020-03-30 21:31 ` Richard Weinberger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).