linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Richard Weinberger <richard.weinberger@gmail.com>
To: Liu Song <fishland@aliyun.com>
Cc: Richard Weinberger <richard@nod.at>,
	linux-mtd@lists.infradead.org,
	LKML <linux-kernel@vger.kernel.org>,
	liu.song11@zte.com.cn
Subject: Re: [PATCH] ubifs: Fix potentially out-of-bounds memory access in ubifs_dump_node
Date: Sun, 12 Jan 2020 23:49:13 +0100	[thread overview]
Message-ID: <CAFLxGvyU=zh23vkYiAGRzyd4LGJodLwRRa1S03THAoSaSL=dGA@mail.gmail.com> (raw)
In-Reply-To: <20191216154441.6648-1-fishland@aliyun.com>

On Mon, Dec 16, 2019 at 4:45 PM Liu Song <fishland@aliyun.com> wrote:
>
> From: Liu Song <liu.song11@zte.com.cn>
>
> 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.

If UBIFS dumps data nodes due an error we are already in deep trouble
and having the content of bad data nodes can be helpful.
This feature helped me more than once to debug issues.

-- 
Thanks,
//richard

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

  reply	other threads:[~2020-01-12 22:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-16 15:44 [PATCH] ubifs: Fix potentially out-of-bounds memory access in ubifs_dump_node Liu Song
2020-01-12 22:49 ` Richard Weinberger [this message]
     [not found] <20191216154441.6648-1-fishland@aliyun.com, CAFLxGvyU=zh23vkYiAGRzyd4LGJodLwRRa1S03THAoSaSL=dGA@mail.gmail.com>
     [not found] ` <202001131229371470661@zte.com.cn>
2020-01-13  7:54   ` Richard Weinberger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFLxGvyU=zh23vkYiAGRzyd4LGJodLwRRa1S03THAoSaSL=dGA@mail.gmail.com' \
    --to=richard.weinberger@gmail.com \
    --cc=fishland@aliyun.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=liu.song11@zte.com.cn \
    --cc=richard@nod.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).