devicetree-compiler.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>
To: David Gibson
	<david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>,
	devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Subject: [PATCH 0/4] libfdt: Check for integer overflows
Date: Fri, 11 Jun 2021 12:58:19 +0100	[thread overview]
Message-ID: <20210611115823.31583-1-andre.przywara@arm.com> (raw)

Apparently some time ago some kind of audit or review of the Linux kernel
triggered some complaints about potential integer overflows in
libfdt[1][2]. The proposed patches there were not of good quality, and
never found their way into any upstream project anyway. This seemed to
assume fabricated DT blobs to upset libfdt, not sure how feasible this
scenario is in general.

This series tries to address the same issues, but hopefully in a better
way. The focus is on fdt_open_into(), since this operates on user
provided (writable) buffers, and a wrong offset could do some harm here.

I am not sure these patches here are the right solution, or whether we
should pursue a more general approach: Many problems stem from the
redundancy and so potential inconsistency of DTB header fields, namely
the total size, the various offsets and the various size fields.
fdt_check_header() seems to detect some of these issues, but it is not
used at the moment in fdt_open_into(). So we could add a call in
fdt_open_into(), or extend FDT_RO_PROBE() to also check for those issues.
Let me know what you think.

Because it was easy to do, patch 2/4 adds a test for one issue I could
reproduce (fixed by patch 1/4). I have some custom DTBs and tests to
catch the problem that patch 4/4 fixes, but need more time to write a
proper test case for this.

Cheers,
Andre

[1] https://nvd.nist.gov/vuln/detail/CVE-2014-9801
[2] https://nvd.nist.gov/vuln/detail/CVE-2014-9802

Andre Przywara (4):
  libfdt: Check for invalid memreserve block
  tests: Enhance truncated_memrsv to test fdt_open_into()
  libfdt: Check DT struct size for integer overflow
  libfdt: Protect buffer size checks against integer overflow

 libfdt/fdt_rw.c          | 63 +++++++++++++++++++++++++++++-----------
 tests/truncated_memrsv.c | 10 ++++++-
 2 files changed, 55 insertions(+), 18 deletions(-)

-- 
2.17.5


             reply	other threads:[~2021-06-11 11:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-11 11:58 Andre Przywara [this message]
     [not found] ` <20210611115823.31583-1-andre.przywara-5wv7dgnIgG8@public.gmane.org>
2021-06-11 11:58   ` [PATCH 1/4] libfdt: Check for invalid memreserve block Andre Przywara
     [not found]     ` <20210611115823.31583-2-andre.przywara-5wv7dgnIgG8@public.gmane.org>
2021-06-12  2:25       ` David Gibson
2021-06-11 11:58   ` [PATCH 2/4] tests: Enhance truncated_memrsv to test fdt_open_into() Andre Przywara
     [not found]     ` <20210611115823.31583-3-andre.przywara-5wv7dgnIgG8@public.gmane.org>
2021-06-12  2:26       ` David Gibson
2021-06-11 11:58   ` [PATCH 3/4] libfdt: Check DT struct size for integer overflow Andre Przywara
     [not found]     ` <20210611115823.31583-4-andre.przywara-5wv7dgnIgG8@public.gmane.org>
2021-06-12  2:29       ` David Gibson
2021-06-11 11:58   ` [PATCH 4/4] libfdt: Protect buffer size checks against " Andre Przywara
     [not found]     ` <20210611115823.31583-5-andre.przywara-5wv7dgnIgG8@public.gmane.org>
2021-06-15  0:42       ` David Gibson

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=20210611115823.31583-1-andre.przywara@arm.com \
    --to=andre.przywara-5wv7dgnigg8@public.gmane.org \
    --cc=david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org \
    --cc=devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).