netdev - Re: [PATCH] fix race in AF

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: <20070618.024807.45712241.davem@davemloft.net>
Date:	Mon, 18 Jun 2007 02:48:07 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	miklos@...redi.hu
Cc:	akpm@...ux-foundation.org, viro@....linux.org.uk,
	alan@...rguk.ukuu.org.uk, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fix race in AF_UNIX

From: Miklos Szeredi <miklos@...redi.hu>
Date: Mon, 18 Jun 2007 11:44:07 +0200

> > Secondarily, this bug has been around for years and nobody noticed.
> > The world will not explode if this bug takes a few more days or
> > even a week to work out.  Let's do it right instead of ramming
> > arbitrary turds into the kernel.
> 
> Fine, but just wishing a bug to get fixed won't accomplish anything.
> I've spent a fair amount of time debugging this thing, and I'm out of
> ideas.  Really.  So unless somebody steps up to look at this, it won't
> _ever_ get fixed.

Somone just needs to find a way to only lock the socket as it is
being operated upon.

The race you are dealing with is rather simple, the queue check
and the state check need to be done atomically.  The only chore
is to find a way to make that happen in the context of what the
garbage allocator is trying to do.

I'm not even convinced that your most recent attempt is deadlock free.
Locking multiple objects the same way all at once like that is
something that needs to be seriously audited.
-
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