From: Nick Alcock <nick.alcock@oracle.com>
To: binutils@sourceware.org
Subject: [PATCH 5/8] libctf: don't dereference out-of-bounds locations in the qualifier hashtab
Date: Wed, 24 Mar 2021 01:21:55 +0000 [thread overview]
Message-ID: <20210324012158.35472-5-nick.alcock@oracle.com> (raw)
In-Reply-To: <20210324012158.35472-1-nick.alcock@oracle.com>
isqualifier, which is used by ctf_lookup_by_name to figure out if a
given word in a type name is a qualifier, takes the address of a
possibly out-of-bounds location before checking its bounds.
In any reasonable compiler this will just lead to a harmless address
computation that is then discarded if out-of-bounds, but it's still
undefined behaviour and the sanitizer rightly complains.
libctf/ChangeLog
2021-03-23 Nick Alcock <nick.alcock@oracle.com>
PR libctf/27628
* ctf-lookup.c (isqualifier): Don't dereference out-of-bounds
qhash values.
---
libctf/ctf-lookup.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libctf/ctf-lookup.c b/libctf/ctf-lookup.c
index 9d1e6d8a4a2..e50c868c5b8 100644
--- a/libctf/ctf-lookup.c
+++ b/libctf/ctf-lookup.c
@@ -111,10 +111,13 @@ isqualifier (const char *s, size_t len)
};
int h = s[len - 1] + (int) len - 105;
+
+ if (h < 0 || (size_t) h >= sizeof (qhash) / sizeof (qhash[0]))
+ return 0;
+
const struct qual *qp = &qhash[h];
- return (h >= 0 && (size_t) h < sizeof (qhash) / sizeof (qhash[0])
- && (size_t) len == qp->q_len &&
+ return ((size_t) len == qp->q_len &&
strncmp (qp->q_name, s, qp->q_len) == 0);
}
--
2.31.0.253.gdec51257f3
next prev parent reply other threads:[~2021-03-24 1:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-24 1:21 [PATCH 1/8] libctf, dump: do not emit size or alignment if it would error Nick Alcock
2021-03-24 1:21 ` [PATCH 2/8] include: always do unsigned left-shift in CTF_SET_STID Nick Alcock
2021-03-24 1:21 ` [PATCH 3/8] libctf, serialize: functions with no args have a NULL dtd_vlen Nick Alcock
2021-03-24 1:21 ` [PATCH 4/8] libctf: make ctf_bfdopen_ctfsect a debugger entry point Nick Alcock
2021-03-24 1:21 ` Nick Alcock [this message]
2021-03-25 0:02 ` [PATCH 5/8] libctf: don't dereference out-of-bounds locations in the qualifier hashtab Hans-Peter Nilsson
2021-03-25 15:53 ` Nick Alcock
2021-03-24 1:21 ` [PATCH 6/8] libctf: fix memory leak in a test Nick Alcock
2021-03-24 1:21 ` [PATCH 7/8] libctf: fix ELF-in-BFD checks in the presence of ASAN Nick Alcock
2021-03-24 1:21 ` [PATCH 8/8] ld: do not rely on the exact size of the CTF symtypetabs in test results Nick Alcock
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=20210324012158.35472-5-nick.alcock@oracle.com \
--to=nick.alcock@oracle.com \
--cc=binutils@sourceware.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).