Re: BUG: unable to handle kernel paging request from pty_write [was: Linux 4.4.2]

2016-02-26 20:44 GMT+01:00 Linus Torvalds <torva...@linux-foundation.org>: >> I've contacted Robert Święcki (who found the microcode problem) in >> case he wants to weigh in in this thread.. He was talking to some AMD >> people, but I don't know the exactly who. &g

Re: BUG: unable to handle kernel paging request from pty_write [was: Linux 4.4.2]

2016-02-26 20:44 GMT+01:00 Linus Torvalds : >> I've contacted Robert Święcki (who found the microcode problem) in >> case he wants to weigh in in this thread.. He was talking to some AMD >> people, but I don't know the exactly who. > > And since it's looking increasingly l

Re: NULL-ptr deref in irqfd_update (via KVM)

Hm.. I think now it's the same as https://groups.google.com/forum/#!topic/syzkaller/Rg4Y2Z6HbHI - just with a bit different stacktrace, and simpler testcase. 2016-02-20 3:07 GMT+01:00 Robert Święcki <rob...@swiecki.net>: > Works under both AMD and Intel > > [7]kdb> summary

Re: NULL-ptr deref in irqfd_update (via KVM)

Hm.. I think now it's the same as https://groups.google.com/forum/#!topic/syzkaller/Rg4Y2Z6HbHI - just with a bit different stacktrace, and simpler testcase. 2016-02-20 3:07 GMT+01:00 Robert Święcki : > Works under both AMD and Intel > > [7]kdb> summary > sysnameLinux > re

NULL-ptr deref in irqfd_update (via KVM)

ctl (filp=0x8804228c8100, fd=, cmd=, arg=536924143) at fs/ioctl.c:674 #7 0x81232086 in SYSC_ioctl (arg=, cmd=, fd=) at fs/ioctl.c:689 #8 SyS_ioctl (fd=4, cmd=1075883638, arg=536924143) at fs/ioctl.c:680 #9 0xffff81ba70b2 in entry_SYSCALL_64_fastpath () at arch/x86/entry/entry_64.S:185 -- Robert Święcki

NULL-ptr deref in irqfd_update (via KVM)

100, fd=, cmd=, arg=536924143) at fs/ioctl.c:674 #7 0x81232086 in SYSC_ioctl (arg=, cmd=, fd=) at fs/ioctl.c:689 #8 SyS_ioctl (fd=4, cmd=1075883638, arg=536924143) at fs/ioctl.c:680 #9 0xffff81ba70b2 in entry_SYSCALL_64_fastpath () at arch/x86/entry/entry_64.S:185 -- Robert Święcki

Re: NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs

[ 218.733427] [] ? kvm_dev_ioctl+0x11f/0x450 [kvm] [ 218.733432] [] ? do_vfs_ioctl+0x2d5/0x4b0 [ 218.733435] [] ? SyS_ioctl+0x76/0x90 [ 218.733439] [] ? system_call_fast_compare_end+0xc/0x6b [ 218.733460] Code: 00 66 66 66 66 90 55 53 48 89 fd 48 83 ec 10 48 8b 9f a0 02 00 00 65 48 8b 04 25 28 00 00 00 48 89 44 24 08 31 c0 66 66 66 66 90 <48> 83 bb f0 00 00 00 00 75 22 48 8b 44 24 08 65 48 33 04 25 28 -- Robert Święcki

Re: NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs

[ 218.733427] [] ? kvm_dev_ioctl+0x11f/0x450 [kvm] [ 218.733432] [] ? do_vfs_ioctl+0x2d5/0x4b0 [ 218.733435] [] ? SyS_ioctl+0x76/0x90 [ 218.733439] [] ? system_call_fast_compare_end+0xc/0x6b [ 218.733460] Code: 00 66 66 66 66 90 55 53 48 89 fd 48 83 ec 10 48 8b 9f a0 02 00 00 65 48 8b 04 25 28 00 00 00 48 89 44 24 08 31 c0 66 66 66 66 90 <48> 83 bb f0 00 00 00 00 75 22 48 8b 44 24 08 65 48 33 04 25 28 -- Robert Święcki

NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs

100 or so, if this doesn't work) $ for x in `seq 1 10`; do { ./prog & }; done -- Robert Święcki

NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs

100 or so, if this doesn't work) $ for x in `seq 1 10`; do { ./prog & }; done -- Robert Święcki

Re: [PATCH v2] sysctl: allow CLONE_NEWUSER to be disabled

2016-01-28 18:48 GMT+01:00 Eric W. Biederman : > Kees Cook writes: > >> + if (sysctl_userns_restrict && !(capable(CAP_SYS_ADMIN) && >> + capable(CAP_SETUID) && >> + capable(CAP_SETGID))) >> + return -EPERM; >>

Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled

>> The admin of such a machine could have disabled userns months earlier >> and limited the scope of the attack. > > Of course for the paranoid there is already a mechanism to do this. > /sbin/chroot. > > No new user namespaces are allowed to be created inside of a chroot. Another alternative is

Re: [PATCH v2] sysctl: allow CLONE_NEWUSER to be disabled

2016-01-28 18:48 GMT+01:00 Eric W. Biederman : > Kees Cook writes: > >> + if (sysctl_userns_restrict && !(capable(CAP_SYS_ADMIN) && >> + capable(CAP_SETUID) && >> +

Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled

>> The admin of such a machine could have disabled userns months earlier >> and limited the scope of the attack. > > Of course for the paranoid there is already a mechanism to do this. > /sbin/chroot. > > No new user namespaces are allowed to be created inside of a chroot. Another alternative is

Re: [PATCH 2/2] sysctl: allow CLONE_NEWUSER to be disabled

s I checked. On which version did you find > that? $ uname -a Linux bc1 4.3.0-0.bpo.1-amd64 #1 SMP Debian 4.3.3-5~bpo8+1 (2016-01-07) x86_64 GNU/Linux $ cat /etc/debian_version 8.2 IIRC some older kernels delivered with Ubuntu Precise were also using it (but maybe I'm mistaken) -- Robert Święcki

Re: [PATCH 2/2] sysctl: allow CLONE_NEWUSER to be disabled

t; + (sysctl_userns_restrict == 1 && (!capable(CAP_SYS_ADMIN) || > +!capable(CAP_SETUID) || > +!capable(CAP_SETGID > + return -EPERM; > + > ns = kmem_cache_zalloc(user_ns_cachep, GFP_KERNEL); > if (!ns) > return -ENOMEM; > -- > 2.6.3 > -- Robert Święcki

Re: fs: sandboxed process brings host down

ed, a new, big attack surface opens up, reachable from a level of a unprivileged user. So, I guess, it's not about sandboxing but the newly reachable attack surface. -- Robert Święcki

Re: [PATCH 2/2] sysctl: allow CLONE_NEWUSER to be disabled

RM; > > + if (sysctl_userns_restrict == 2 || > + (sysctl_userns_restrict == 1 && (!capable(CAP_SYS_ADMIN) || > +!capable(CAP_SETUID) || > +!capable(CAP_SETGID > + return -EPERM; > + > ns = kmem_cache_zalloc(user_ns_cachep, GFP_KERNEL); > if (!ns) > return -ENOMEM; > -- > 2.6.3 > -- Robert Święcki

Re: [PATCH 2/2] sysctl: allow CLONE_NEWUSER to be disabled

I didn't see that on systems I checked. On which version did you find > that? $ uname -a Linux bc1 4.3.0-0.bpo.1-amd64 #1 SMP Debian 4.3.3-5~bpo8+1 (2016-01-07) x86_64 GNU/Linux $ cat /etc/debian_version 8.2 IIRC some older kernels delivered with Ubuntu Precise were also using it (but maybe I'm mistaken) -- Robert Święcki

Re: fs: sandboxed process brings host down

ERM, but when CLONE_NEW* are used, a new, big attack surface opens up, reachable from a level of a unprivileged user. So, I guess, it's not about sandboxing but the newly reachable attack surface. -- Robert Święcki

[BUG] mem leak (not: info leak) in perf (kernel 4.0.0-rc2)

It seems to be not released after all involved processes have terminated. Will try to debug it more, but others might see some obvious problem here. -- Robert Święcki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org

[BUG] mem leak (not: info leak) in perf (kernel 4.0.0-rc2)

to be not released after all involved processes have terminated. Will try to debug it more, but others might see some obvious problem here. -- Robert Święcki -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info

Re: panic in skb_push via sctp

ecki.net/.ksan/.config-sctp -- Robert Święcki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: panic in skb_push via sctp

ough head room in worst case for possible tunnels. Not sure, but I run it inside a pid/ipc/uts/etc/user-namespaces where it operates with a full set of capabilities, so most of the SOCK_RAW and tunnel-like-creating calls succeed, so maybe.. -- Robert Święcki -- To unsubscribe from this list: send

Re: panic in skb_push via sctp

. 2014-12-01 18:36 GMT+01:00 Daniel Borkmann : > On 12/01/2014 05:49 PM, Robert Święcki wrote: >> >> I don't have much more, cause my kernel is kASLRNized and gdb cannot >> handle that, but pasting output from kdb. Maybe somebody will be able >> to see something obviou

panic in skb_push via sctp

2f2/0x640 [] SyS_sendto+0xe/0x10 [] tracesys_phase2+0xd8/0xdd -- Robert Święcki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please r

panic in skb_push via sctp

[83aaa086] SYSC_sendto+0x166/0x240 [811561d2] ? syscall_trace_enter_phase2+0x2f2/0x640 [83aac57e] SyS_sendto+0xe/0x10 [845cb778] tracesys_phase2+0xd8/0xdd -- Robert Święcki -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body

Re: panic in skb_push via sctp

. 2014-12-01 18:36 GMT+01:00 Daniel Borkmann dbork...@redhat.com: On 12/01/2014 05:49 PM, Robert Święcki wrote: I don't have much more, cause my kernel is kASLRNized and gdb cannot handle that, but pasting output from kdb. Maybe somebody will be able to see something obvious. 0

Re: panic in skb_push via sctp

, but I run it inside a pid/ipc/uts/etc/user-namespaces where it operates with a full set of capabilities, so most of the SOCK_RAW and tunnel-like-creating calls succeed, so maybe.. -- Robert Święcki -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message

Re: panic in skb_push via sctp

Not sure, but I run it inside a pid/ipc/uts/etc/user-namespaces where it operates with a full set of capabilities, so most of the SOCK_RAW and tunnel-like-creating calls succeed, so maybe.. Ok thanks, can you post your .config? Hi, http://alt.swiecki.net/.ksan/.config-sctp -- Robert

Re: Div-by-zero in the 8250 serial driver (3.17-rc5)

2014-09-19 14:56 GMT+02:00 Peter Hurley : > [ +cc Greg Kroah-Hartman, AlanC ] > > On 09/18/2014 10:57 AM, Robert Święcki wrote: >> Hi, >> >> # setserial /dev/ttyS0 spd_hi baud_base 38400 >> >> Entering kdb (current=0x8805ee033200, pid 1798) on proc

Re: Div-by-zero in the 8250 serial driver (3.17-rc5)

2014-09-19 14:56 GMT+02:00 Peter Hurley pe...@hurleysoftware.com: [ +cc Greg Kroah-Hartman, AlanC ] On 09/18/2014 10:57 AM, Robert Święcki wrote: Hi, # setserial /dev/ttyS0 spd_hi baud_base 38400 Entering kdb (current=0x8805ee033200, pid 1798) on processor 9 Oops: (null) due to oops

Div-by-zero in the 8250 serial driver (3.17-rc5)

s/ioctl.c:613 error = #12 SyS_ioctl (fd=3, cmd=21535, arg=140737325927280) at /build/buildd/linux-3.13.0/fs/ioctl.c:604 -- Robert Święcki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More

Div-by-zero in the 8250 serial driver (3.17-rc5)

in SYSC_ioctl (arg=optimized out, cmd=optimized out, fd=optimized out) at /build/buildd/linux-3.13.0/fs/ioctl.c:613 error = optimized out #12 SyS_ioctl (fd=3, cmd=21535, arg=140737325927280) at /build/buildd/linux-3.13.0/fs/ioctl.c:604 -- Robert Święcki -- To unsubscribe from

Deadlock (un-killable processes) in sys_futex

://alt.swiecki.net/linux/20327/13735.kdb.txt kgdb stacktraces displaying rather corrupted data: http://alt.swiecki.net/linux/20327/20327.kgdb.txt http://alt.swiecki.net/linux/20327/13735.kgdb.txt kernel conf: http://alt.swiecki.net/linux/20327/config-3.12-rc4.txt -- Robert Święcki

Deadlock (un-killable processes) in sys_futex

://alt.swiecki.net/linux/20327/13735.kdb.txt kgdb stacktraces displaying rather corrupted data: http://alt.swiecki.net/linux/20327/20327.kgdb.txt http://alt.swiecki.net/linux/20327/13735.kgdb.txt kernel conf: http://alt.swiecki.net/linux/20327/config-3.12-rc4.txt -- Robert Święcki