On Tue, Jan 29, 2019 at 05:40:07PM +0100, Michael Petlan wrote: > On Tue, 29 Jan 2019, Heiko Carstens wrote: > > On Tue, Jan 29, 2019 at 05:32:49PM +0900, Masami Hiramatsu wrote: > > > > > # cat trace > > > > > <...>-18602 [000] d... 288289.847945: do_sys_open: (do_sys_open+0x0/0x238) filename_string=(fault) > > > > > <...>-18602 [000] d... 288289.848586: do_sys_open: (do_sys_open+0x0/0x238) filename_string=(fault) > > > > > <...>-18602 [000] d... 288289.852643: do_sys_open: (do_sys_open+0x0/0x238) filename_string=(fault) > > > > > <...>-18602 [000] d... 288289.853202: do_sys_open: (do_sys_open+0x0/0x238) filename_string=(fault) > > > > > ... > > > > > > > > > > I'm getting this on latest upstream 5.0.0-rc3+ > > > > > > > > > > looks like we call strncpy_from_unsafe -> __get_user, which fails > > > > > in this case.. any idea if this is perhaps some known issue on s390x? > > > > > > > > This looks like the wrong address space is accessed. The "string" type > > > > is supposed to copy a string from _kernel_ space while the filename > > > > argument of do_sys_open() is a user space pointer. > > > > > > Right... since kprobes runs in interrupt(exception) handler, we can not > > > sleep inside it, so accessing user-space can be failed. > > > > Well, this didn't fail because a user space page was not mapped, but > > because a wrong address space with a different page table was used. > > > > If the kernel address space would have something mapped at the same > > address like user space, then garbage would have been returned > > instead. > > Well, good to say here that this scenario happens, practically undefined > "garbage" occurs in the "strings" sometimes too. I am not any expert of > this, but it looks like a data leak from the kernel-space... If I set a > probe with a variable of some address which should be taken as a string > and kernel just gives us back the data from there when the probe is hit, > it doesn't look good. I hope I am wrong here. If you are allowed to set kprobes you can extract any information out of the kernel anyway. I don't see how this would be an additional security issue.
