From: Greg KH <gregkh@linuxfoundation.org>
To: Jiasheng Jiang <jiashengjiangcool@gmail.com>
Cc: markus.elfring@web.de, jlbec@evilplan.org,
joseph.qi@linux.alibaba.com, linux-kernel@vger.kernel.org,
mark@fasheh.com, ocfs2-devel@lists.linux.dev,
stable@vger.kernel.org
Subject: Re: [PATCH v2] ocfs2: fix NULL pointer dereference in ocfs2_get_refcount_rec
Date: Mon, 19 Jan 2026 07:37:29 +0100 [thread overview]
Message-ID: <2026011925-canon-helium-65c6@gregkh> (raw)
In-Reply-To: <20260118190523.42581-1-jiashengjiangcool@gmail.com>
On Sun, Jan 18, 2026 at 07:05:23PM +0000, Jiasheng Jiang wrote:
> In ocfs2_get_refcount_rec(), the 'rec' pointer is initialized to NULL.
> If the extent list is empty (el->l_next_free_rec == 0), the loop skips
> assignment, leaving 'rec' as NULL and 'found' as 0.
>
> Currently, the code skips the 'if (found)' block but proceeds directly to
> dereference 'rec' at line 767 (le64_to_cpu(rec->e_blkno)), causing a
> NULL pointer dereference panic.
>
> This patch adds an 'else' branch to the 'if (found)' check. If no valid
> record is found, it reports a filesystem error and exits, preventing
> the invalid memory access.
>
> Fixes: e73a819db9c2 ("ocfs2: Add support for incrementing refcount in the tree.")
> Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
> ---
> Changelog:
>
> v1 -> v2:
>
> 1. Add a Fixes tag.
> ---
> fs/ocfs2/refcounttree.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/fs/ocfs2/refcounttree.c b/fs/ocfs2/refcounttree.c
> index c92e0ea85bca..464bdd6e0a8e 100644
> --- a/fs/ocfs2/refcounttree.c
> +++ b/fs/ocfs2/refcounttree.c
> @@ -1122,6 +1122,11 @@ static int ocfs2_get_refcount_rec(struct ocfs2_caching_info *ci,
>
> if (cpos_end < low_cpos + len)
> len = cpos_end - low_cpos;
> + } else {
> + ret = ocfs2_error(sb, "Refcount tree %llu has no extent record covering cpos %u\n",
> + (unsigned long long)ocfs2_metadata_cache_owner(ci),
> + low_cpos);
> + goto out;
> }
>
> ret = ocfs2_read_refcount_block(ci, le64_to_cpu(rec->e_blkno),
> --
> 2.25.1
>
>
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
</formletter>
next prev parent reply other threads:[~2026-01-19 6:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cfd0e0eb-894e-48c7-948e-9300a19b9db7@web.de>
2026-01-18 19:05 ` [PATCH v2] ocfs2: fix NULL pointer dereference in ocfs2_get_refcount_rec Jiasheng Jiang
2026-01-19 6:37 ` Greg KH [this message]
2026-01-19 9:42 ` Markus Elfring
2026-01-19 9:49 ` Greg KH
2026-01-19 14:43 ` Heming Zhao
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=2026011925-canon-helium-65c6@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=jiashengjiangcool@gmail.com \
--cc=jlbec@evilplan.org \
--cc=joseph.qi@linux.alibaba.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark@fasheh.com \
--cc=markus.elfring@web.de \
--cc=ocfs2-devel@lists.linux.dev \
--cc=stable@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox