linux-kernel - [PATCH RFC] jfs: fix KMSAN warning in txLock

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

Message-ID: <CADhLXY7bkhVSLgOaSh5kU=HJBVJ1b7Dnq-Dy77puUaM40qj81Q@mail.gmail.com>
Date: Fri, 23 Jan 2026 14:40:04 +0530
From: Deepanshu Kartikey <kartikey406@...il.com>
To: shaggy@...nel.org, brauner@...nel.org
Cc: jfs-discussion@...ts.sourceforge.net, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, mjguzik@...il.com, b23@...vjti.ac.in
Subject: [PATCH RFC] jfs: fix KMSAN warning in txLock - need guidance

Hi JFS maintainers,

I'm investigating a KMSAN warning reported by syzbot:
https://syzkaller.appspot.com/bug?extid=d3a57c32b9112d7b01ec

The KMSAN trace shows uninitialized memory being read in txLock():

BUG: KMSAN: uninit-value in txLock+0x13a2/0x2900 fs/jfs/jfs_txnmgr.c:659

Uninit was created at:
  vmalloc_noprof+0xce/0x140 mm/vmalloc.c:4146
  txInit+0xb5c/0xfa0 fs/jfs/jfs_txnmgr.c:297

The issue is that txInit() allocates the global TxLock array using
vmalloc(), which doesn't zero the memory. When txLock() later accesses
TxLock[].next fields, it reads uninitialized memory.

I have a simple fix - changing vmalloc() to vzalloc() in txInit():

diff --git a/fs/jfs/jfs_txnmgr.c b/fs/jfs/jfs_txnmgr.c
index c16578af3a77..4c72103a0b46 100644
--- a/fs/jfs/jfs_txnmgr.c
+++ b/fs/jfs/jfs_txnmgr.c
@@ -294,7 +294,7 @@ int txInit(void)
  * tlock id = 0 is reserved.
  */
  size = sizeof(struct tlock) * nTxLock;
- TxLock = vmalloc(size);
+ TxLock = vzalloc(size);
  if (TxLock == NULL) {
  vfree(TxBlock);
  return -ENOMEM;

This fixes the KMSAN warning. However, when testing with the reproducer,
this change exposes a different issue:

[  307.772029][ T6674] BUG at fs/jfs/jfs_txnmgr.c:662 assert(last)

It seems that with zeroed memory, the assert at line 662 now fails
because the code is trying to traverse a transaction lock list starting
from atlhead=0, and TxLock[0].next is now 0 (instead of garbage).

I believe my vzalloc() patch is correct - it fixes undefined behavior.
The assert failure appears to be a separate pre-existing logic bug that
was previously hidden by garbage memory values.

Questions:
1. Is my analysis correct?
2. Should I submit just the vzalloc() patch?
3. Should the assert be replaced with proper error handling?
4. Is there a case where atlhead=0 is valid and the code should handle it?

I'm a kernel newbie and would appreciate guidance on the right approach.

Thanks,
Deepanshu Kartikey