> The kernel stack is not very useful in this case, it's a common faulting
> stack.
> Maybe it will shed some light if you install gdb in the image, attach
> it to the systemd process, then trigger the segfault and then unwind
> stack in the systemd process at the time of fault, dump registers,
>
On Wed, Mar 10, 2021 at 10:02 AM Palash Oswal wrote:
>
> On Tue, Mar 9, 2021 at 7:58 PM Al Viro wrote:
> > Lovely. So something in that sequence of syscalls manages to trigger
> > segfault in unrelated process. What happens if you put it to sleep
> > right after open_by_handle_at() (e.g. by
On Tue, Mar 9, 2021 at 7:58 PM Al Viro wrote:
> Lovely. So something in that sequence of syscalls manages to trigger
> segfault in unrelated process. What happens if you put it to sleep
> right after open_by_handle_at() (e.g. by read(2) from fd 0, etc.)?
Added read(2) call in the reproducer,
On Tue, Mar 9, 2021 at 8:36 PM Dmitry Vyukov wrote:
> FWIW the code looks reasonable:
>
> All code
>
>0: 00 00add%al,(%rax)
>2: 00 00add%al,(%rax)
>4: 41 57push %r15
>6: 41 56push %r14
>8: 41
Al Viro writes:
> On Tue, Mar 09, 2021 at 11:29:14AM +0530, Palash Oswal wrote:
>
>> I observe the following result(notice the segfault in systemd):
>> root@sandbox:~# ./repro
>> [9.457767] got to 221
>> [9.457791] got to 183
>> [9.459144] got to 201
>> [9.459471] got to 208
>> [
On Tue, Mar 9, 2021 at 3:31 PM Al Viro wrote:
> > I observe the following result(notice the segfault in systemd):
> > root@sandbox:~# ./repro
> > [9.457767] got to 221
> > [9.457791] got to 183
> > [9.459144] got to 201
> > [9.459471] got to 208
> > [9.459773] got to 210
> > [
On Tue, Mar 09, 2021 at 11:29:14AM +0530, Palash Oswal wrote:
> I observe the following result(notice the segfault in systemd):
> root@sandbox:~# ./repro
> [9.457767] got to 221
> [9.457791] got to 183
> [9.459144] got to 201
> [9.459471] got to 208
> [9.459773] got to 210
> [
On Mon, Mar 8, 2021 at 10:50 PM Al Viro wrote:
> I'd suggest to add printk(KERN_ERR "got to %d", __LINE__); in fs/fhandle.c at
> beginning of do_handle_open()
> right before each copy_from_user() in handle_to_path()
> right before and right after the call of
y((void*)0x2000, "\x0a\x00\x00\x00\x02\x00\x00\x00\x4b\x0d", 10);
> syscall(__NR_open_by_handle_at, r[0], 0x2000ul, 0x2f00ul);
> return 0;
> }
>
> This reproducer only worked on the syzkaller instance disk image that
> I was using. I am adding the syzkaller report from
turn 0;
}
This reproducer only worked on the syzkaller instance disk image that
I was using. I am adding the syzkaller report from a second instance
for the same issue:
Report #2
Syzkaller hit 'kernel panic: Attempted to kill init!' bug.
Kernel panic - not syncing: Attempted to kill init! exitcode=
On Thu, Dec 28, 2017 at 10:20 AM, syzbot
wrote:
> Hello,
>
> syzkaller hit the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC)
On Thu, Dec 28, 2017 at 10:20 AM, syzbot
wrote:
> Hello,
>
> syzkaller hit the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output
12 matches
Mail list logo