netdev - Re: [patch] isdn: avm: potential signedness issue in loading firmware

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20140509.132403.531379541580867189.davem@davemloft.net>
Date:	Fri, 09 May 2014 13:24:03 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	dan.carpenter@...cle.com
Cc:	isdn@...ux-pingi.de, netdev@...r.kernel.org, security@...nel.org,
	henry@...ryhoggard.co.uk
Subject: Re: [patch] isdn: avm: potential signedness issue in loading
 firmware

From: Dan Carpenter <dan.carpenter@...cle.com>
Date: Fri, 9 May 2014 14:54:37 +0300

> The concern here is that a negative value for "len" could lead underflow
> the "while (left > FWBUF_SIZE) {" test and lead to memory corruption.
> I do not believe this is possible because we test for negatives in
> old_capi_manufacturer(), "if (ldef.t4file.len <= 0) {".
> 
> But it sort of makes the code nicer to only deal with positive lengths
> so I have made it unsigned.  The length is still not capped and so if we
> get a too large value, we keep on writing it out to the firmware byte by
> byte until the writes start failing.
> 
> Loading the firmware requires CAP_SYS_ADMIN.
> 
> Reported-by: Henry Hoggard <henry@...ryhoggard.co.uk>
> Signed-off-by: Dan Carpenter <dan.carpenter@...cle.com>
> 
> diff --git a/drivers/isdn/hardware/avm/b1.c b/drivers/isdn/hardware/avm/b1.c
> index 4d9b195..7f2ed49 100644
> --- a/drivers/isdn/hardware/avm/b1.c
> +++ b/drivers/isdn/hardware/avm/b1.c
> @@ -153,7 +153,8 @@ int b1_load_t4file(avmcard *card, capiloaddatapart *t4file)
>  {
>  	unsigned char buf[FWBUF_SIZE];
>  	unsigned char *dp;
> -	int i, left;
> +	unsigned int left;
> +	int i;
>  	unsigned int base = card->port;

Are you sure this is an improvement?

As you say, if we get a negative length, we'll run that "while (left >
FWBUF_SIZE)" loop a LOT.

Whereas if you keep the signedness, it won't run even one time if we somehow
were given a negative t4file->len.

To me, the only real option is to make this function itself guard against
negative lengths, and return -EINVAL if it sees one.

Then you can perhaps also kill such checks from the callers.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html