linux-kernel - Re: Infinite loop in get_file_rcu() in face of a saturated ref count

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] [day] [month] [year] [list]

Message-ID: <20250826-leinen-villa-02f66f98e13e@brauner>
Date: Tue, 26 Aug 2025 11:23:54 +0200
From: Christian Brauner <brauner@...nel.org>
To: Mateusz Guzik <mjguzik@...il.com>
Cc: linux-fsdevel <linux-fsdevel@...r.kernel.org>, 
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Infinite loop in get_file_rcu() in face of a saturated ref count

On Mon, Aug 25, 2025 at 11:43:00PM +0200, Mateusz Guzik wrote:
> __get_file_rcu() bails early:
> 
>         if (unlikely(!file_ref_get(&file->f_ref)))
>                 return ERR_PTR(-EAGAIN);
> 
> But get_file_rcu():
>        for (;;) {
>                 struct file __rcu *file;
> 
>                 file = __get_file_rcu(f);
>                 if (!IS_ERR(file))
>                         return file;
>         }
> 
> So if this encounters a saturated refcount, the loop with never end.
> 
> I don't know what makes the most sense to do here and I'm no position
> to mess with any patches.
> 
> This is not a serious problem either, so I would put this on the back
> burner. Just reporting for interested.

That's like past 2^63 - 1 references. Apart from an odd bug is that
really something to worry about. I mean, we can add a VFS_WARN_ON_ONCE()
in there of course but specifically handling that in the code doesn't
seem sensible to me.