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: 11+ 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
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox