> 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 rea
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, an
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 5
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 do_handle_to_p
On Mon, Mar 08, 2021 at 10:06:10PM +0530, Palash Oswal wrote:
> I was running syzkaller and I found the following issue :
> Head Commit : 27e543cca13fab05689b2d0d61d200a83cfb00b6 ( v5.11.2 )
> Git Tree : stable
>
> Console Logs:
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x
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 is
10 matches
Mail list logo