From: Sasha Levin <sashal@kernel.org>
To: Nathan Gao <zcgao@amazon.com>
Cc: stable@vger.kernel.org, regressions@lists.linux.dev,
linux-fsdevel@vger.kernel.org
Subject: Re: [REGRESSION] fs: ERR_PTR dereference in expand_files() on v6.12.43
Date: Mon, 25 Aug 2025 15:56:21 -0400 [thread overview]
Message-ID: <aKy_5bOIZwolisn2@laps> (raw)
In-Reply-To: <20250825152725.43133-1-zcgao@amazon.com>
On Mon, Aug 25, 2025 at 08:27:25AM -0700, Nathan Gao wrote:
>Hi,
>
>I noticed an ERR_PTR dereference issue in expand_files() on kernel 6.12.43
>when allocating large file descriptor tables. The issue occurs when
>alloc_fdtable() returns ERR_PTR(-EMFILE) for large nr input, but
>expand_fdtable() is not properly checking these error returns. dup_fd()
>seems also have the issue, missing proper ERR_PTR handling.
>
>The ERR_PTR return was introduced by d4f9351243c1 ("fs: Prevent file
>descriptor table allocations exceeding INT_MAX") which adds INT_MAX limit
>check in alloc_fdtable().
Ugh, sorry :(
>I was able to trigger this with the unshare_test selftest:
>
>[ 40.283906] BUG: unable to handle page fault for address: ffffffffffffffe8
>...
>[ 40.287436] RIP: 0010:expand_files+0x7e/0x1c0
>...
>[ 40.366211] Kernel panic - not syncing: Fatal exception
>
>Looking at the upstream kernel, this can be addressed by Al Viro's
>fdtable series [1], which added the ERR_PTR handling in this code path.
>Perhaps backporting this series, especially 1d3b4be ("alloc_fdtable():
>change calling conventions.") would help resolve the issue.
I agree. I'll pick up. Thanks for the report!
--
Thanks,
Sasha
prev parent reply other threads:[~2025-08-25 19:56 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-25 15:27 [REGRESSION] fs: ERR_PTR dereference in expand_files() on v6.12.43 Nathan Gao
2025-08-25 19:56 ` Sasha Levin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aKy_5bOIZwolisn2@laps \
--to=sashal@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=regressions@lists.linux.dev \
--cc=stable@vger.kernel.org \
--cc=zcgao@amazon.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.