linux-kernel - Re: Linux 3.3-rc4

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:	Sun, 19 Feb 2012 10:45:26 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Thomas Meyer <thomas@...3r.de>, Ian Kent <raven@...maw.net>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 3.3-rc4

On Sun, Feb 19, 2012 at 5:42 AM, Thomas Meyer <thomas@...3r.de> wrote:
>
> Theoretically yes, practically (at least with Fedora 15/16) no. I did hit these two bugs:
>
> 1.) autofs4 interface is broken between x86 and x86_64. as systemd uses autofs, this bug hangs the boot process as e.g. binfmt is mounted via autofs. see also http://lists.freedesktop.org/archives/systemd-devel/2011-September/003396.html

Duh.

That is just broken.

The code even *talks* about how the packet layout is the same on
32-bit and 64-bit architectures, and that's largely true.

However, while true, x86-64 has 8-byte alignment for 'long', and
x86-32 has 4-byte alignment. Which means that even though the
structure layout is exactly the same, on x86-64 the *alignment* issue
will push it out to 304 bytes.

That's just stupid. We've had that problem before. It's easy to
overlook, but that packet is just mis-designed.

The attached patch isn't pretty, but this is definitely a kernel bug.
Binary compatibility is *important*, dammit.

Does this fix it?

Sadly, the *right* fix would have been to just mark the structure
packed, or select a maximum name length that padded things out to 8
bytes on all architectures, but we can't change that any more, because
changing the size on native 32-bit would break binaries there.

> 2.) while debugging above issue: I did find an minor bug in sys_poll() - nobody did take care of my proposed patch: https://lkml.org/lkml/2011/9/24/35

Looks correct, and searching my lkml archives shows that it was acked
by Eric. But it never went any further.

Mind re-sending that patch updated for the x86 system call
re-organization? Sure, I could do it myself, but it would be much
better if somebody who then actually *tests* the end result did it
(hpa cc'd, just because he's the one that touched the x86 compat layer
system call table thing. "Tag, you're it")

Anyway, if that, together with the sizeof hack in the attached patch,
makes everything work for you, I'll happily apply both of them.

                          Linus

View attachment "patch.diff" of type "text/x-patch" (1519 bytes)