From: David Howells <dhowells@redhat.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: David Woodhouse <dwmw2@infradead.org>, Greg KH <greg@kroah.com>,
Arjan van de Ven <arjanv@redhat.com>,
Joy Latten <latten@us.ibm.com>,
lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Fw: signed kernel modules?
Date: Thu, 14 Oct 2004 12:02:52 +0100 [thread overview]
Message-ID: <16127.1097751772@redhat.com> (raw)
In-Reply-To: <1097707986.14303.36.camel@localhost.localdomain>
> I'd prefer to see:
> err = module_verify(hdr, len, &gpgsig_ok);
> if (err)
> goto free_hdr;
I've been moaned at for doing this before. Other people have told me they
prefer to see the value returned through the return value since there's enough
scope.
> And then have module_verify for the !CONFIG_MODULE_SIG case (in
> module-verify.h) simply be:
I think it should still check the ELF, even if we're not going to check a
signature. This permits us to drop a few checks later in the module loading
process.
> + tmp = (size_t) hdr->e_shentsize * (size_t) hdr->e_shnum;
> + elfcheck(tmp < size - hdr->e_shoff);
>
> Multiplicative overflow.
Not so in this ELF incarnation. The multiply parameters are both 16-bit values
which I cast to 32-bit values before multiplying. I could, I suppose, put
checks on this.
I've added a check to make sure hdr->e_shnum is less than SHN_LORESERVE.
> Also check that hdr->e_shentsize is sizeof(Elf_Shdr) since you assume that
> below.
Added.
> + mvdata->secsizes = kmalloc(hdr->e_shnum * sizeof(size_t), GFP_KERNEL);
> + memset(mvdata->secsizes, 0, hdr->e_shnum * sizeof(size_t));
>
> Multiplicative overflow again: we could kmalloc 0 bytes and overflow below.
A 16-bit value multiplied by a 32/64-bit value which 4 or 8. Where's the
overflow?
Try compiling and running:
#include <stdio.h>
int main() { printf("%zu\n", sizeof(sizeof(char))); return 0; }
> + secstop = mvdata->sections + mvdata->nsects;
>
> Subtler multiplicative overflow.
There's already a check in to make sure it won't overflow, given the
additional checks to limit e_shnum (which is unsigned 16 bits) and that
e_shentsize is correct.
> + if (section->sh_entsize > 0)
> + seccheck(section->sh_size % section->sh_entsize == 0);
>
> Divide by zero (thanks Alan!).
Not so. Look more closely, particularly at the if-statement.
> I think you have to check (as above) that st_name is nul terminated
> within size.
Added.
> I think you can overflow here. For REL and RELA sections, you don't
> check that sh_size is <= *secsize.
I've added checks that the sh_entsize is what I'm expecting. There's already a
check that the section size divides exactly by the ent-size (you claimed it
had a div-by-0 error above).
> That's all I found,
Thanks.
David
next prev parent reply other threads:[~2004-10-14 11:03 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1096411448.3230.22.camel@localhost.localdomain>
[not found] ` <1092403984.29463.11.camel@bach>
[not found] ` <1092369784.25194.225.camel@bach>
[not found] ` <20040812092029.GA30255@devserv.devel.redhat.com>
[not found] ` <20040811211719.GD21894@kroah.com>
[not found] ` <OF4B7132F5.8BE9D947-ON87256EEB.007192D0-86256EEB.00740B23@us.ibm.com>
[not found] ` <1092097278.20335.51.camel@bach>
[not found] ` <20040810002741.GA7764@kroah.com>
[not found] ` <1092189167.22236.67.camel@bach>
[not found] ` <19388.1092301990@redhat.com>
[not found] ` <30797.1092308768@redhat.com>
[not found] ` <20040812111853.GB25950@devserv.devel.redhat.com>
[not found] ` <20040812200917.GD2952@kroah.com>
[not found] ` <26280.1092388799@redhat.com>
[not found] ` <27175.1095936746@redhat.com>
[not found] ` <30591.1096451074@redhat.com>
[not found] ` <1096544201.8043.816.camel@localhost.localdomain>
2004-10-11 15:11 ` Fw: signed kernel modules? David Howells
2004-10-11 15:15 ` David Woodhouse
2004-10-11 22:34 ` Rusty Russell (IBM)
2004-10-12 8:35 ` David Woodhouse
2004-10-12 19:08 ` Greg KH
2004-10-12 19:16 ` David Howells
2004-10-12 20:43 ` David Howells
2004-10-13 0:20 ` Rusty Russell (IBM)
2004-10-13 8:24 ` David Woodhouse
2004-10-13 0:11 ` Rusty Russell (IBM)
2004-10-13 9:16 ` David Woodhouse
2004-10-13 21:21 ` Rusty Russell (IBM)
2004-10-13 9:24 ` David Howells
2004-10-13 10:42 ` Alan Cox
2004-10-13 22:40 ` Rusty Russell (IBM)
2004-10-14 10:17 ` David Howells
2004-10-15 0:28 ` Rusty Russell (IBM)
2004-10-14 23:44 ` Alan Cox
2004-10-15 1:00 ` Rusty Russell (IBM)
2004-10-13 21:18 ` David Howells
2004-10-13 21:51 ` Roman Zippel
2004-10-14 11:12 ` David Howells
2004-10-14 12:01 ` Roman Zippel
2004-10-14 12:11 ` David Woodhouse
2004-10-14 14:22 ` Roman Zippel
2004-10-14 14:30 ` David Woodhouse
2004-10-14 21:03 ` Roman Zippel
2004-10-14 21:24 ` David Woodhouse
2004-10-14 21:36 ` Roman Zippel
2004-10-14 21:52 ` David Woodhouse
2004-10-14 22:15 ` Roman Zippel
2004-10-14 22:32 ` David Howells
2004-10-14 22:38 ` Roman Zippel
2004-10-14 12:14 ` David Howells
2004-10-14 13:08 ` Richard B. Johnson
2004-10-14 14:18 ` Geert Uytterhoeven
2004-10-14 14:25 ` Richard B. Johnson
2004-10-14 15:40 ` Richard B. Johnson
2004-10-14 15:50 ` Dave Jones
[not found] ` <Pine.LNX.4.61.0410141352590.8479@chaos.analogic.com>
2004-10-14 18:20 ` Dave Jones
2004-10-14 18:30 ` Richard B. Johnson
2004-10-14 18:46 ` Dave Jones
2004-10-14 19:03 ` Richard B. Johnson
2004-10-14 19:41 ` Geert Uytterhoeven
2004-10-14 21:13 ` Dave Jones
2004-10-18 1:56 ` Jon Masters
2004-10-13 23:01 ` Rusty Russell
2004-10-14 11:02 ` David Howells [this message]
2004-10-15 0:47 ` Rusty Russell
2004-10-14 18:09 ` David Howells
2004-10-15 11:12 ` Roman Zippel
2004-10-15 12:10 ` Richard B. Johnson
2004-10-15 12:31 ` Josh Boyer
2004-10-15 15:53 ` Gene Heskett
2004-10-15 16:17 ` Josh Boyer
2004-10-15 16:59 ` Richard B. Johnson
2004-10-15 17:08 ` David Woodhouse
2004-10-15 17:35 ` Richard B. Johnson
2004-10-15 20:56 ` Lee Revell
2004-10-15 21:18 ` Greg KH
2004-10-15 21:34 ` Chris Friesen
2004-10-15 22:08 ` Richard B. Johnson
2004-10-18 12:53 ` Richard B. Johnson
2004-10-18 13:53 ` Matthew Garrett
2004-10-18 14:09 ` Richard B. Johnson
2004-10-18 16:33 ` Greg KH
2004-10-18 17:14 ` Richard B. Johnson
2004-10-18 17:28 ` Richard B. Johnson
2004-10-15 17:46 ` Josh Boyer
2004-10-15 20:11 ` Tonnerre
2004-10-17 20:18 ` Thomas Weber
2004-10-17 20:52 ` Geert Uytterhoeven
2004-10-17 21:25 ` Thomas Weber
2004-10-15 12:48 ` Roman Zippel
2004-10-15 15:51 ` Gene Heskett
2004-10-15 14:01 ` David Woodhouse
2004-10-15 14:28 ` Roman Zippel
2004-10-15 15:54 ` Gene Heskett
2004-10-15 16:33 ` Arjan van de Ven
2004-10-14 18:44 ` Thomas Weber
2004-10-15 15:37 Chuck Ebbert
2004-10-15 16:05 ` Olivier Galibert
[not found] <fa.ghoqtmo.8nqeb0@ifi.uio.no>
[not found] ` <fa.jtpibm5.1l4ki17@ifi.uio.no>
2004-10-17 15:13 ` Bodo Eggert
2004-10-18 11:27 ` Richard B. Johnson
2004-10-23 10:19 ` Bodo Eggert
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=16127.1097751772@redhat.com \
--to=dhowells@redhat.com \
--cc=arjanv@redhat.com \
--cc=dwmw2@infradead.org \
--cc=greg@kroah.com \
--cc=latten@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
/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