linux-kernel - Re: [PATCH] stmmac: Fix type of local variable in stmmac

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] [day] [month] [year] [list]

Date:	Fri, 04 Mar 2016 14:31:10 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	a.hajda@...sung.com
Cc:	peppe.cavallaro@...com, netdev@...r.kernel.org,
	b.zolnierkie@...sung.com, m.szyprowski@...sung.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] stmmac: Fix type of local variable in stmmac_xmit

From: Andrzej Hajda <a.hajda@...sung.com>
Date: Fri, 04 Mar 2016 08:19:04 +0100

> Variable entry holds result of jumbo_frm callback. It can be negative,
> so the variable should be signed. The patch changes also type of related
> first_entry variable to make code compact and coherent.
> 
> The problem has been detected using patch
> scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci.
> 
> Signed-off-by: Andrzej Hajda <a.hajda@...sung.com>

Actually, this only papers over a much deeper problem.

You cannot mix continually incrementing indexes with negative
return values.

You simply can't.

Because after enough traffic the legitimate indexes will be negative
integer values, so this jumbo index test would alway trigger.

A better fix is needed for this.  ->jumbo_frm() cannot return a value
that is interpreted both as an index as well as an error code.  The
dual signalling between these two values is simply impossible because
one the whole value space of a 32-bit integer is also a valid index.