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]

Date:	Sat, 30 May 2009 14:45:54 +0200
From:	Jarek Poplawski <jarkao2@...il.com>
To:	jamal <hadi@...erus.ca>
Cc:	Minoru Usui <mi.usui@...il.com>,
	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 Sat, May 30, 2009 at 08:31:23AM -0400, jamal wrote:
> On Sat, 2009-05-30 at 14:07 +0200, Jarek Poplawski wrote:
> > On Sat, May 30, 2009 at 07:56:34AM -0400, jamal wrote:
> 
> > > tp_created is the check
> > > n->nlmsg_type == RTM_NEWTFILTER && n->nlmsg_flags&NLM_F_CREATE
> > > replace will be
> > > n->nlmsg_type == RTM_NEWTFILTER && n->nlmsg_flags & NLM_F_EXCL
> > 
> > Hmm... Probably I miss something, but I've just seen this prink during
> > tc filter replace with:
> > 
> > err = tp->ops->change();
> > if (n->nlmsg_type == RTM_NEWTFILTER && (n->nlmsg_flags&NLM_F_CREATE))
> > 	printk(...);
> 
> That sounds right. 
> Remeber, you could have NLM_F_EXCL|NLM_F_CREATE to indicate "create this
> thing if it doesnt exist; if it exists  it is an error"
> If it doesnt exist we will enter that (tp == NULL) path
> also fh will be 0 ==> So you will never enter the code
> path you are refering to.
> If it exists (i.e you found it) and you enter the code path you refer
> to, then you surely dont want to destroy it if NLM_F_EXCL is set.

I mean we don't want to link it again or destroy after ->change() err
if we run replace (n->nlmsg_type == RTM_NEWTFILTER &&
(n->nlmsg_flags&NLM_F_CREATE)).

> 
> > > I think they are two separate issues.
> > > The fact that we dont destroy an allocated tp on failure is an issue
> > > regardless of what cls_group does. In the case of Minoru's issue
> > > it is because he is misconfiguring cls_group.
> > 
> > Sure, but we don't want people to get oops in such a case, I guess.
> > 
> 
> The ops is caused by the code fixed in the patch - did i miss something?

IMHO it could be fixed "old way" in cls_group code too.

Cheers,
Jarek P.
--
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