[PATCH] ubifs: Fix potentially out-of-bounds memory access in ubifs_dump_node

[Liu Song <fishland@xxxxxxxxxx>]

From: Liu Song <liu.song11@xxxxxxxxxx>

In “ubifs_check_node”, when “node_len + offs> c-> leb_size”, then
goto label of "out_len". 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".
We encountered this problem in our environment. If "ch-> len" is
very large, it may even cause the kernel to crash.

There are three reasons to choose to remove "print_hex_dump".
1) As mentioned earlier, the exception "ch-> len" may cause an
exception in "print_hex_dump";
2) Data nodes are often large. When printing data content in
"print_hex_dump", a large amount of output will bring a high load
on the system, and may even cause a watchdog reset;
3) Even if there is a CRC check error, the stuff of file is difficult
to identify, and difficult to find the problem from a large amount of
output. We have already output the LEB and offset of the node. So we
can take the initiative to view the data of interest, instead of
printing it directly.

Signed-off-by: Liu Song <liu.song11@xxxxxxxxxx>
---
 fs/ubifs/debug.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/fs/ubifs/debug.c b/fs/ubifs/debug.c
index 0f5a480fe264..e9fc6f0daec8 100644
--- a/fs/ubifs/debug.c
+++ b/fs/ubifs/debug.c
@@ -476,9 +476,6 @@ void ubifs_dump_node(const struct ubifs_info *c, const void *node)
 		pr_err("\tcompr_typ      %d\n",
 		       (int)le16_to_cpu(dn->compr_type));
 		pr_err("\tdata size      %d\n", dlen);
-		pr_err("\tdata:\n");
-		print_hex_dump(KERN_ERR, "\t", DUMP_PREFIX_OFFSET, 32, 1,
-			       (void *)&dn->data, dlen, 0);
 		break;
 	}
 	case UBIFS_TRUN_NODE:
-- 
2.20.1


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/