linux-kernel - Re: [PATCH V1] fuse: Abort the requests under processing queue with a spin

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 1 Jun 2023 15:32:24 +0530
From:   Pradeep Pragallapati <quic_pragalla@...cinc.com>
To:     Miklos Szeredi <miklos@...redi.hu>
CC:     <linux-fsdevel@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V1] fuse: Abort the requests under processing queue with a
 spin_lock


On 5/31/2023 5:22 PM, Miklos Szeredi wrote:
> On Wed, 31 May 2023 at 11:26, Pradeep P V K <quic_pragalla@...cinc.com> wrote:
>> There is a potential race/timing issue while aborting the
>> requests on processing list between fuse_dev_release() and
>> fuse_abort_conn(). This is resulting into below warnings
>> and can even result into UAF issues.
> Okay, but...
>
>> [22809.190255][T31644] refcount_t: underflow; use-after-free.
>> [22809.190266][T31644] WARNING: CPU: 2 PID: 31644 at lib/refcount.c:28
>> refcount_warn_saturate+0x110/0x158
>> ...
>> [22809.190567][T31644] Call trace:
>> [22809.190567][T31644]  refcount_warn_saturate+0x110/0x158
>> [22809.190569][T31644]  fuse_file_put+0xfc/0x104
> ...how can this cause the file refcount to underflow?  That would
> imply that fuse_request_end() will be called for the same request
> twice.  I can't see how that can happen with or without the locking
> change.
Please ignore this patch. i overlooked it as list_splice in 
fuse_dev_release() and made the change.
> Do you have a reproducer?

don't have exact/specific steps but i will try to recreate. This is 
observed during stability testing (involves io, reboot, monkey, e.t.c.) 
for 24hrs. So, far this is seen on both 5.15 and 6.1 kernels. Do you 
have any points or speculations to share ?

Thanks,

Pradeep

> Thanks,
> Miklos