linux-kernel - Re: [PATCH] fuse: clear FR_PENDING flag when moving requests out of pending queue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJfpegs10eHA-8wCRh5UXX0P32r3RfHWTa9Gm=hcwMaftqwtUw@mail.gmail.com>
Date:   Fri, 27 Jan 2017 10:35:26 +0100
From:   Miklos Szeredi <miklos@...redi.hu>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Tahsin Erdogan <tahsin@...gle.com>, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fuse: clear FR_PENDING flag when moving requests out of
 pending queue

On Mon, Jan 16, 2017 at 6:57 PM, Borislav Petkov <bp@...en8.de> wrote:
> Hi,
>
> On Fri, Jan 13, 2017 at 12:13:04PM +0100, Miklos Szeredi wrote:
>> On Thu, Jan 12, 2017 at 9:04 PM, Tahsin Erdogan <tahsin@...gle.com> wrote:
>> > fuse_abort_conn() moves requests from pending list to a temporary list
>> > before canceling them. This operation races with request_wait_answer()
>> > which also tries to remove the request after it gets a fatal signal. It
>> > checks FR_PENDING flag to determine whether the request is still in the
>> > pending list.
>> >
>> > Make fuse_abort_conn() clear FR_PENDING flag so that request_wait_answer()
>> > does not remove the request from temporary list.
>> >
>> > This bug manifests itself as a panic that looks like this:
>>
>> Perfect patch; applied and pushed.
>
> I'm seeing something similar here while the grub OS prober checks the
> other partitions. It is not always reproducible, I saw it only twice so
> far.
>
> Related?
>
> [  568.562174] ntfs: driver 2.1.32 [Flags: R/W MODULE].
> [  568.575436] fuse init (API version 7.26)
> [  568.707737] general protection fault: 0000 [#1] PREEMPT SMP


Doesn't look related.

"general protection fault" doesn't tell much about what happened.
Can't even tell which address was guilty.

Do you still have the vmlinux for this?  Or better yet, fs/fuse/dev.o?

Thanks,
Miklos