Messages in this thread | | | From | Andy Lutomirski <> | Date | Fri, 17 Mar 2017 11:20:51 -0700 | Subject | Re: [x86] 45fc8757d1: BUG:unable_to_handle_kernel |
| |
On Fri, Mar 17, 2017 at 11:07 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Fri, Mar 17, 2017 at 11:00 AM, Linus Torvalds > <torvalds@linux-foundation.org> wrote: >> On Fri, Mar 17, 2017 at 10:49 AM, Linus Torvalds >> <torvalds@linux-foundation.org> wrote: >>> >>> The linear address can be used to look up which entry it is. I assume >>> the GDT starts at ffffffffff577000, and that this is at offset 0x60 >>> from that. Whatever descriptor that would be.. >> >> Hmm. That should be gdt index 12, aka GDT_ENTRY_TLS_MIN. >> >> I guess user space can set almost anything there. Including setting a >> segment type that isn't accessed, and that the CPU will change on the >> first actual access. >> >> We do have code to verify the limits and types etc iirc, I guess we >> can make sure to set the accessed bit too. > > Hmm. "fill_ldt()" does this: > > desc->type = (info->read_exec_only ^ 1) << 1; > desc->type |= info->contents << 2; > > which always leaves bit #0 of ->type clear. That's the A bit. > > Does the problem go away if we just add a > > desc->type |= 1; > > to the end there?
I can easily imagine that breaking WINE or DOSEMU because it'll affect the LDT, too.
How about this:
https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/fixes&id=df8110544c6e899897e1b2ec3ab53d9e4ee40f65
I'll see why selftests didn't catch this, too.
| |