From: Junjie Cao <junjie.cao@linux.dev>
To: openembedded-core@lists.openembedded.org
Cc: paul@pbarker.dev, randy.macleod@windriver.com,
Venkata.Navuduri@windriver.com
Subject: [OE-core][PATCH v2 07/10] cve-exclusion: set status for CVE-2023-3397
Date: Mon, 3 Aug 2026 01:48:24 -0700 [thread overview]
Message-ID: <20260803084827.1348810-8-junjie.cao@linux.dev> (raw)
In-Reply-To: <20260803084827.1348810-1-junjie.cao@linux.dev>
txEnd() in fs/jfs/jfs_txnmgr.c reads the log pointer from the superblock
info, drops TXN_LOCK and then takes log->gclock, while lmLogClose() can
free that log during umount.
The subsystem in the public CVE data is misleading: the "slub"
association comes from the KASAN slab report, but the affected code is
JFS. Red Hat's own title for the issue is "slab-use-after-free write in
txend due to race condition".
A fix adding a new mutex was posted, reviewed, and then withdrawn by its
author, who wrote "I think my fix method is not a good solution":
https://lore.kernel.org/all/20230515095956.17898-1-zyytlz.wz@163.com/
No other fix has been posted, and the sequence in txEnd() is unchanged
in mainline as of linux-next 20260727. syzkaller was still reporting
"KASAN: slab-use-after-free Write in txEnd" in June 2026.
Ubuntu records "unfixed upstream as of 2023-09-01"; Debian lists
src:linux as vulnerable in every suite:
https://ubuntu.com/security/CVE-2023-3397
https://security-tracker.debian.org/tracker/CVE-2023-3397
CONFIG_JFS_FS=n in both ktypes/standard/standard.cfg and
ktypes/preempt-rt/preempt-rt.cfg in yocto-kernel-cache, and no fragment
there enables it; the only other occurrence is CONFIG_JFS_SECURITY in
the selinux feature, which has no effect without JFS_FS.
CC: Paul Barker <paul@pbarker.dev>
AI-Generated: Uses Claude (claude-opus-5)
Signed-off-by: Junjie Cao <junjie.cao@linux.dev>
---
changes in v2:
- split out of the single combined patch, one CVE per patch as requested
- added primary source links (disclosures, distribution trackers, mailing
list threads, upstream commits) to every commit message
- added the three CVEs with no upstream fix as "unpatched" entries instead
of leaving them undocumented
- disclosed AI assistance per the contributor guide
v1: https://lore.kernel.org/openembedded-core/20260802143444.1178575-1-junjie.cao@linux.dev/
meta/recipes-kernel/linux/cve-exclusion.inc | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/meta/recipes-kernel/linux/cve-exclusion.inc b/meta/recipes-kernel/linux/cve-exclusion.inc
index 3517318e..827a487e 100644
--- a/meta/recipes-kernel/linux/cve-exclusion.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion.inc
@@ -232,3 +232,10 @@ CVE_STATUS[CVE-2022-1247] = "fixed-version: Fixed from version 6.17"
# https://www.willsroot.io/2022/12/entrybleed.html
CVE_STATUS[CVE-2022-4543] = "upstream-wontfix: no fix planned, KASLR is not \
considered a defence against local attackers"
+
+# JFS txEnd()/lmLogClose() use-after-free, not slub as the CVE data says.
+# The only proposed fix was withdrawn by its author; the racy code is
+# unchanged and syzbot still reproduces it as of June 2026.
+# https://lore.kernel.org/all/20230515095956.17898-1-zyytlz.wz@163.com/
+CVE_STATUS[CVE-2023-3397] = "unpatched: no upstream fix, the only proposed \
+patch was withdrawn by its author and the affected fs/jfs code is unchanged"
--
2.43.0
next prev parent reply other threads:[~2026-08-03 8:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-03 8:48 [OE-core][PATCH v2 00/10] cve-exclusion: triage ten kernel CVEs lacking upstream fix data Junjie Cao
2026-08-03 8:48 ` [OE-core][PATCH v2 01/10] cve-exclusion: set status for CVE-2019-14899 Junjie Cao
2026-08-03 8:48 ` [OE-core][PATCH v2 02/10] cve-exclusion: set status for CVE-2021-3714 Junjie Cao
2026-08-03 8:48 ` [OE-core][PATCH v2 03/10] cve-exclusion: set status for CVE-2021-3864 Junjie Cao
2026-08-03 8:48 ` [OE-core][PATCH v2 04/10] cve-exclusion: set status for CVE-2022-0400 Junjie Cao
2026-08-03 8:48 ` [OE-core][PATCH v2 05/10] cve-exclusion: set status for CVE-2022-1247 Junjie Cao
2026-08-03 8:48 ` [OE-core][PATCH v2 06/10] cve-exclusion: set status for CVE-2022-4543 Junjie Cao
2026-08-03 8:48 ` Junjie Cao [this message]
2026-08-03 8:48 ` [OE-core][PATCH v2 08/10] cve-exclusion: set status for CVE-2023-4010 Junjie Cao
2026-08-03 8:48 ` [OE-core][PATCH v2 09/10] cve-exclusion: set status for CVE-2023-6238 Junjie Cao
2026-08-03 8:48 ` [OE-core][PATCH v2 10/10] cve-exclusion: set status for CVE-2023-6240 Junjie Cao
2026-08-06 11:52 ` [OE-core][PATCH v2 00/10] cve-exclusion: triage ten kernel CVEs lacking upstream fix data Paul Barker
2026-08-10 10:19 ` Junjie Cao
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=20260803084827.1348810-8-junjie.cao@linux.dev \
--to=junjie.cao@linux.dev \
--cc=Venkata.Navuduri@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=paul@pbarker.dev \
--cc=randy.macleod@windriver.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.