linux-kernel - Re: [PATCH] wireless: fix 64K kernel heap content leak via ioctl

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: <20100830174018.GA3639@bougret.hpl.hp.com>
Date:	Mon, 30 Aug 2010 10:40:19 -0700
From:	Jean Tourrilhes <jt@....hp.com>
To:	Johannes Berg <johannes@...solutions.net>
Cc:	Kees Cook <kees.cook@...onical.com>, linux-kernel@...r.kernel.org,
	"John W. Linville" <linville@...driver.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Joe Perches <joe@...ches.com>, Tejun Heo <tj@...nel.org>,
	linux-wireless@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH] wireless: fix 64K kernel heap content leak via ioctl

On Mon, Aug 30, 2010 at 11:59:01AM +0200, Johannes Berg wrote:
> 
> Ok I finally fully understood the issue.
> 
> This will fix the problem, but the comment is completely bogus, which I
> guess means you didn't actually understand the problem.

	Correct, Kees pointed out that my comment was bogus and the
e-mail I sent after the patch corrected myself on that point :

------------------------------------
> The comment should probably be clarified -- it's the caller's iwp->length
> that may be causing problems

        Ha ! I see. It would be for regular iwpoint queries, not for
extended NOMAX queries (scan is a extended NOMAX query).
------------------------------------

> My patch also didn't fix the problem, I didn't understand the problem
> correctly and was continuously wondering how drivers would ever fill the
> buffer with more than max_tokens (which would be a more serious bug,
> since they'd overwrite a slab object after "extra").

	Yes, I had arrived at the same conclusion (not that my patch
did fix the issue).

> What really fixes the problem is the patch below though. Had to realise
> that the path where the driver didn't do ANYTHING AT ALL was the
> problem....

	I actually like your patch better than mine, it's closer to
the original intent of the API. Go for it ;-)

> johannes

	Thanks a lot for the second pair of eyes.

	Jean
--
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/