linux-kernel - Re: [PATCH] xen/blkback: Check for insane amounts of request on the ring.

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: <51B6126302000078000DCC1C@nat28.tlf.novell.com>
Date:	Mon, 10 Jun 2013 16:52:35 +0100
From:	"Jan Beulich" <JBeulich@...e.com>
To:	"Konrad Rzeszutek Wilk" <konrad.wilk@...cle.com>
Cc:	<david.vrabel@...rix.com>, <roger.pau@...rix.com>,
	"xen-devel" <xen-devel@...ts.xen.org>,
	<linux-kernel@...r.kernel.org>, <stable@...r.kernel.org>
Subject: Re: [PATCH] xen/blkback: Check for insane amounts of request
 on the ring.

>>> On 07.06.13 at 22:11, Konrad Rzeszutek Wilk <konrad.wilk@...cle.com> wrote:
> On Tue, Jun 04, 2013 at 03:57:06PM -0400, Konrad Rzeszutek Wilk wrote:
>> +	/* N.B. 'rp', not 'rc'. */
>> +	if (RING_REQUEST_CONS_OVERFLOW(&blk_rings->common, rp)) {
>> +		pr_warn(DRV_PFX "Frontend provided bogus ring requests (%d - %d = %d). 
> Halting ring processing on dev=%04x\n",
>> +			rp, rc, rp - rc, blkif->vbd.pdevice);
> 
> Hm, I seem to be able to get:
> 
> [  189.398095] xen-blkback:Frontend provided bogus ring requests (125 - 115 = 
> 10). Halting ring processing on dev=800011
> or:
> [  478.558699] xen-blkback:Frontend provided bogus ring requests (95 - 94 = 
> 1). Halting ring processing on dev=800011
> 
> Which is clearly wrong. Piggybacking on the rsp_prod_pvt does not seem to 
> cut it.

We see that too, but not very frequently. One thing is that
rsp_prod_pvt doesn't get printed along with rc and rp, thus
making it not immediately obvious how this can be off in any way.

Among the instance there are cases where the printed
difference is 32, which makes me wonder whether part of the
problem is the >= in the macro (we may want > here).

And then we might have been living with some sort of issue in the
past, because the existing use of the macro just causes the loop
to be exited, with it getting re-entered subsequently (i.e. at worst
causing performance issues).

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/