netdev - Re: [BUG] net_cls: Panic occured when net

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: <1243893963.3966.325.camel@dogo.mojatatu.com>
Date:	Mon, 01 Jun 2009 18:06:03 -0400
From:	jamal <hadi@...erus.ca>
To:	Jarek Poplawski <jarkao2@...il.com>
Cc:	Minoru Usui <usui@....nes.nec.co.jp>, netdev@...r.kernel.org,
	containers@...ts.linux-foundation.org
Subject: Re: [BUG] net_cls: Panic occured when net_cls subsystem use

On Mon, 2009-06-01 at 22:49 +0200, Jarek Poplawski wrote:

> 
> Actually, I'd insist with the old rock and handling that other rude
> u32 case, at least until it's fixed in place. So I attach my version
> of your patch (additionally I removed a pair of braces because of
> checkpatch warning).

Sure, it doesnt complicate anything - Minoru, this is the version to go
for.

> Alas, I still think we don't need to change so much in -stable to
> fix the cls_cgroup oops, so I attach a patch which I think is
> enough for -stable and probably -net too. It could be "reverted"
> in -net-next just after applying cls_api patch. Of course, treat
> it only as my humble proposal, and feel free to recommend to David
> your version, no problem (really).

My view is the same - that the second patch doesnt fix the root
cause; and it is not that complicated to fix the root cause. So I humbly
disagree with you.

The issue is that a classifer (cls_group in this example) is being
misconfigured. It rejects the config - but the tp has already been
added. 
It then tries to use the tp in the fast and fails. 

If you look as closely as you did with the patch i posted, youd find
ways to construct similar hostile misconfigs for other classifiers.
You just need to create the scenario where the attributes will fail to
validate. 

I actually suspect the most common scenario for such a failure is not
that head is null (I doubt in Minoru case that allocation will fail);
rather it is some reference to head->something.

cheers,
jamal

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