linux-kernel - Re: [PATCH] Fix 'flush_old_exec()/setup_new

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: <alpine.LFD.2.00.1002040749390.3707@localhost.localdomain>
Date:	Thu, 4 Feb 2010 07:57:28 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ben Hutchings <ben@...adent.org.uk>
cc:	stable@...nel.org, LKML <linux-kernel@...r.kernel.org>,
	stable-review@...nel.org
Subject: Re: [PATCH] Fix 'flush_old_exec()/setup_new_exec()' split

On Thu, 4 Feb 2010, Ben Hutchings wrote:
> > 
> > So you _should_ have a combination of
> >  - 221af7f87 ("Split 'flush_old_exec' into two functions")
> >  - 05d43ed8a ("x86: get rid of the insane TIF_ABI_PENDING bit")
> >  - 7ab02af42 ("Fix 'flush_old_exec()/setup_new_exec()' split")
> > 
> > (and there are also additional sparc/ppc versions of that TIF_ABI_PENDING 
> > bit removal, but they shouldn't matter on your system)
> 
> Thanks.  If all the necessary patches are all in the stable queue then
> we can pick them from there.

Yeah, they are all there. Please do report if that fixes your 64-bit 
kernel with 32-bit user space issues (I tested that case, but I don't have 
a full 32-bit environment, so I only tested it on a fairly simple 
test-case that showed the pre-patch problem that the series fixes).

Btw, that 221af7f87 commit (even with the fix) is kind of nasty in that it 
changes semantics without then fixing up the users in the same commit. 
Normally we wouldn't accept anything like that, but it was supposed to 
only change semantics for a case that was already broken, and is pretty 
rare (the transition from 32-bit to 64-bit and vice versa).

Splitting them up was supposed to make it clearer what was going on and 
tint he original version the first patch didn't change semantics. And in 
fact, the split-up did indeed then help me chase down the bug that showed 
up on Microblaze, because it broke an architecture that shouldn't have 
been affected at all ;)

But pretty it wasn't. My bad. It would have been much better if we'd have 
fixed this earlier than -rc6, but the bugreport that reported this came in 
around -rc5. Unlucky timing (because the problem has been around for a 
looong time).

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