* [PATCH v6 0/2] iio: frequency: ad9832: cleanups
From: Joshua Crofts @ 2026-04-17 10:16 UTC (permalink / raw)
To: lars, Michael.Hennerich, jic23, gregkh
Cc: dlechner, nuno.sa, andy, linux-iio, linux-staging, linux-kernel,
Joshua Crofts
This series cleans up issues in the AD9832 driver, including proxy
header removal and bit math simplification.
v2:
- PATCH 1: removed redundant bits.h include as it is implied in
bitops.h
- PATCH 2: changed ull to u64 type
v3:
- PATCH 2: remove rogue vim typo
v4:
- PATCH 1: removed slab.h based on IWYU recommendation, header
reordering
v5:
- PATCH 1: commit message stylistic changes
v6:
- PATCH 1: add additional headers per kernel.h removal, commit message
edit
- PATCH 2: commit message edit
Joshua Crofts (2):
iio: frequency: ad9832: remove kernel.h proxy header
iio: frequency: ad9832: simplify bitwise math
drivers/staging/iio/frequency/ad9832.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
--
2.47.3
^ permalink raw reply
* Re: [PATCH 2/2] media: i2c: imx471: Add Sony IMX471 image sensor driver
From: Hans de Goede @ 2026-04-17 10:16 UTC (permalink / raw)
To: Kate Hsuan, Mauro Carvalho Chehab, Hans Verkuil, Sakari Ailus,
Serin Yeh
Cc: linux-media, linux-kernel
In-Reply-To: <20260417083214.222189-3-hpa@redhat.com>
Hi Kate,
On 17-Apr-26 10:32, Kate Hsuan wrote:
> Add a new driver for Sony imx471 camera sensor. It is based on
> Jimmy Su <jimmy.su@intel.com> implementation and the driver can be found
> in the following URL.
> https://github.com/intel/ipu6-drivers/commits/master/drivers/media/i2c/imx471.c
>
> This sensor can be found on Lenovo X9-14 and X9-15 laptop and it is a part
> of IPU7 solution. The driver was tested on Lenovo X9-14 and X9-15 laptops.
>
> Link: https://github.com/intel/ipu6-drivers/blob/master/drivers/media/i2c/imx471.c
> Link: https://bugzilla.redhat.com/show_bug.cgi?id=2454119
> Signed-off-by: Kate Hsuan <hpa@redhat.com>
<snip>
> diff --git a/drivers/media/i2c/imx471.c b/drivers/media/i2c/imx471.c
> new file mode 100644
> index 000000000000..32a105a60731
> --- /dev/null
> +++ b/drivers/media/i2c/imx471.c
> @@ -0,0 +1,1047 @@
<snip>
> +static int imx471_update_flip(struct imx471_data *sensor, u32 value,
> + u8 flip_bit)
> +{
> + int ret;
> + u64 val = value ? flip_bit : 0;
> +
> + if (sensor->streaming)
> + return -EBUSY;
I see no reason why this could not be updated while streaming,
since the h/y offsets get adjusted the bayer pattern stays
the same so changing while streaming should be fine.
> +
> + /* hflip */
> + /*
> + * Some manufacturers mount the sensor upside-down (rotation == 180).
> + * V4L2 sets both h/vflip to 1 for 180-degree rotation, but only the
> + * vflip should actually be applied. Skip the initial hflip write to
> + * preserve correct orientation.
> + */
I was answering your off-list email about this, but now I see that you've
added this workaround here. I believe that this workaround is wrong, so
let me move answer things here instead of off-list:
> I filled in the DMI information in the table and I found v4l2 sets up
> both hflip=1 and vflip=1 when the rotation is 180.
Yes that is correct, note this is actually done by libcamera, in response
to the rotation property reporting 180 degrees rotation after adding the
laptop to the DMI table.
> In my case, I only
> need to set vflip then I can get a correct image.
First of all are you sure that you only need to set vflip? A camera is not
a mirror! If you say raise your right hand in front of the camera then on
the screen you should be seen raising the hand which is on the left for
"the you" looking at the screen because if you were to look at you from
the pov of the camera your right hand is on the left.
The easiest way to check this is to have something with some written text
on it. In a mirror you cannot (easily) read e.g. the text printed on
a T-shirt but with a camera you should be able to read this without
problems.
Also make sure you use qcam to test because qcam does not mirror/hflip.
Some apps hflip the image for you (esp. things like google meet) because
people are so used to seeing themselves in a mirror that they adjust
the view for you. Note e.g. google meet only mirrors your own preview
it sends out an unmirrored image to the people on the call (IIRC).
If after this long mansplaining (sorry) writeup about the difference
between a mirror and a camera you still think you only need vflip,
then that means that either the hflip ot the vflip control of
the sensor is inverted and the driver needs to invert it.
Are we sure the camera module is upside down? Maybe vflip is the one
which we need to invert and the module is not upside-down at all ?
Hmm, looking at other imx sensor drivers, unlike ov sensors where
sometimes hflip is inverted it seems the 2 flip controls are sofar
always straight forward on imx. Although some drivers only implement
vflip and have no hflip at all.
As you mention in the cover letter this is a cleaned up version of:
https://github.com/intel/ipu6-drivers/tree/master/drivers/media/i2c/imx471.c
Note that we've seen issues with mirroring / flipping from various
other drivers originating from Intel, they have not always got this
correct, especially when it comes to mirroring by default (when
the hflip control's value is 0) but also with vflipping by default
when the driver was developed on a laptop which had the module
upside-down, see e.g. :
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/media/i2c/ov02c10.c
where we needed to do quite a few flipping related fixes.
> + if (flip_bit == IMX471_HFLIP_BIT) {
> + if (sensor->rotation == 180 && !sensor->hflip_initialized) {
> + sensor->hflip_initialized = true;
> + return 0;
> + }
This looks like you skip writing the hflip on the first start stream,
but what about subsequent streams ?
Also see my next comment below, I think this skipping only once
does point us in the right direction.
> +
> + cci_update_bits(sensor->regmap, IMX471_REG_ORIENTATION,
> + flip_bit, val, &ret);
> +
> + return ret;
> + }
> +
> + /* vflip */
> + cci_update_bits(sensor->regmap, IMX471_REG_ORIENTATION,
> + flip_bit, val, &ret);
> + if (ret)
> + return ret;
Hmm, I wonder if the problem here is you doing 2 subsequent
cci_update_bits(). If the flip control registered is double-buffered
and the new value is latched as the actual value on the start
of the next frame; and this is combined with reading back
reading the active value, not the last written value then
the first time you do this the setting of the hflip bit will
be overwritten by the second cci_update_bits.
I think it would be better to do something similar to what
imx219.c and replace these 2 cci_update_bits() calls with:
cci_write(imx471->regmap, IMX471_REG_ORIENTATION,
imx471->hflip->val | imx471->vflip->val << 1, &ret);
I believe this should work here too.
> +
> + cci_write(sensor->regmap, IMX471_REG_V_WIN_OFFSET,
> + value ? 0xe0 : 0xeb, &ret);
> + if (ret)
> + return ret;
> +
> + cci_update_bits(sensor->regmap, IMX471_REG_H_WIN_OFFSET, 1,
> + value ? 0x01 : 0x00, &ret);
No need for cci_update_bits() here, the register is always
initialized to 0xc8 so this can just use hardcoded values
like the V_WIN_OFFSET path:
cci_write(sensor->regmap, IMX471_REG_H_WIN_OFFSET,
value ? 0xc9 : 0xc8, &ret);
> + return ret;
Updating both offsets here is wrong when hflip != vflip, you
should only update V_WIN_OFFSET when changing vflip and
H_WIN_OFFSET when changing hflip.
I suggest dropping this function and instead in set_ctrl()
do this:
case V4L2_CID_HFLIP:
cci_write(imx471->regmap, IMX471_REG_ORIENTATION,
imx471->hflip->val | imx471->vflip->val << 1, &ret);
cci_write(sensor->regmap, IMX471_REG_H_WIN_OFFSET,
value ? 0xc9 : 0xc8, &ret);
break;
case V4L2_CID_VFLIP:
cci_write(imx471->regmap, IMX471_REG_ORIENTATION,
imx471->hflip->val | imx471->vflip->val << 1, &ret);
cci_write(sensor->regmap, IMX471_REG_V_WIN_OFFSET,
value ? 0xe0 : 0xeb, &ret);
break;
Regards,
Hans
^ permalink raw reply
* Re: [PATCH] PCI: eswin: Fix resource leak on dw_pcie_host_init() failure
From: Felix Gu @ 2026-04-17 10:14 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Senchuan Zhang, Lorenzo Pieralisi, Krzysztof Wilczyński,
Rob Herring, Bjorn Helgaas, Yanghui Ou, Yu Ning, linux-pci,
linux-kernel
In-Reply-To: <gs3kbuwifduoa3gdhyxpg25tl5kifmlxdavgjgyxmihyt4hmr4@bcwz36emppw6>
On Fri, Apr 17, 2026 at 5:35 PM Manivannan Sadhasivam <mani@kernel.org> wrote:
>
> Error path is really messed up. On pm_runtime_get_sync() failure, it should
> go to 'err_free_ports' and on dw_pcie_host_init() failure, it should go to
> err_pm_runtime_put.
>
> - Mani
>
> --
> மணிவண்ணன் சதாசிவம்
Hi Mani,
For pm_runtime_get_sync() failure, it still needs a pm_runtime_put().
So it doesn't need two labels here.
Best regards,
Felix Gu
^ permalink raw reply
* Re: [PATCH] xfs: zero roundoff padding in xlog_sync to prevent
From: syzbot @ 2026-04-17 10:12 UTC (permalink / raw)
To: tristmd; +Cc: tristmd, linux-kernel, syzkaller-bugs
In-Reply-To: <20260417101250.2492247-1-tristmd@gmail.com>
> From: Tristan Madani <tristan@talencesecurity.com>
>
> #syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
This crash does not have a reproducer. I cannot test it.
>
> stale data exposure
>
> xlog_sync() rounds up the in-core log (iclog) write size to the log
> stripe unit or sector size. The roundoff padding bytes between
> iclog->ic_offset and the rounded-up boundary come from the iclog data
> buffer, which is allocated once at mount time with kvzalloc but is
> reused across log writes without re-zeroing.
>
> When an iclog is reused, the padding region may contain stale data
> from a previous log write. xlog_pack_data() and xlog_cksum() then
> process these stale bytes, which KMSAN flags as use of uninitialized
> memory. While the stale data is overwritten on disk during log
> recovery, the KMSAN report indicates a real information hygiene issue.
>
> Zero the roundoff padding bytes before calling xlog_pack_data() to
> ensure deterministic log content regardless of prior iclog state.
>
> Reported-by: syzbot+97f2c05378c5d68dcb8c@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=97f2c05378c5d68dcb8c
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: stable@vger.kernel.org
> Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
> ---
> fs/xfs/xfs_log.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c
> index XXXXXXX..XXXXXXX 100644
> --- a/fs/xfs/xfs_log.c
> +++ b/fs/xfs/xfs_log.c
> @@ -1731,6 +1731,10 @@ xlog_sync(
> xlog_grant_add_space(&log->l_write_head, roundoff);
> }
>
> + /* Zero roundoff padding to avoid writing stale data to the log */
> + if (roundoff)
> + memset(iclog->ic_datap + iclog->ic_offset, 0, roundoff);
> +
> /* put cycle number in every block */
> xlog_pack_data(log, iclog, roundoff);
> --
> 2.43.0
^ permalink raw reply
* Re: [PATCH v1] arm64: dts: qcom: qcs6490-rb3gen2: Add WCD headset playback and record for qcs6490-rb3gen2 industrial mezzanine
From: Krzysztof Kozlowski @ 2026-04-17 10:12 UTC (permalink / raw)
To: Karthik S, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <b6600312-3667-472b-9b76-c9977355115a@kernel.org>
On 17/04/2026 11:42, Krzysztof Kozlowski wrote:
>
> And finally:
>
> Please run scripts/checkpatch.pl on the patches and fix reported
> warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
> patches and (probably) fix more warnings. Some warnings can be ignored,
> especially from --strict run, but the code here looks like it needs a
> fix. Feel free to get in touch if the warning is not clear.
As you pointed correctly after offline talk, checkpatch does not report
undocumented compatible for the sound card qcs6490-rb3gen2-ia-snd-card.
Unfortunately this patch did not go through internal toolset fully
(PatchWise), which could have flag the issue. Let's discuss it
internally next week.
>
> Undocumented ABI (without any reference in changelog where to find
> posted patch).
You still need to solve the undocumented sound card ABI - new
compatible. If it is already sent to mailing lists, then provide link in
patch changelog (---).
Best regards,
Krzysztof
^ permalink raw reply
* Forwarded: [PATCH] jffs2: replace BUG_ON with warning in
From: syzbot @ 2026-04-17 10:12 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
In-Reply-To: <0000000000008bbf19061531d31a@google.com>
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH] jffs2: replace BUG_ON with warning in
Author: tristmd@gmail.com
From: Tristan Madani <tristan@talencesecurity.com>
#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
jffs2_del_ino_cache
jffs2_del_ino_cache() panics the kernel via BUG_ON if the inode cache
entry still has xattr references:
BUG_ON(old->xref);
This can be triggered by a crafted JFFS2 image where the CRC check
path calls jffs2_do_clear_inode() while pino_nlink is non-zero.
jffs2_xattr_delete_inode() skips cleanup when pino_nlink > 0, so the
xref list survives into jffs2_del_ino_cache(), hitting the BUG_ON.
Replace the BUG_ON with WARN_ON_ONCE to report the inconsistency
without crashing the kernel. The leaked xrefs will be cleaned up
when the filesystem is unmounted via jffs2_free_ino_caches().
Reported-by: syzbot+44664704c1494ad5f7a0@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=44664704c1494ad5f7a0
Fixes: aa98d7cf59b5 ("[JFFS2][XATTR] XATTR support on JFFS2 (version 5)")
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
---
fs/jffs2/nodelist.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/jffs2/nodelist.c b/fs/jffs2/nodelist.c
index XXXXXXX..XXXXXXX 100644
--- a/fs/jffs2/nodelist.c
+++ b/fs/jffs2/nodelist.c
@@ -459,7 +459,7 @@ void jffs2_del_ino_cache(struct jffs2_sb_info *c, struct jffs2_inode_cache *old)
struct jffs2_inode_cache **prev;
#ifdef CONFIG_JFFS2_FS_XATTR
- BUG_ON(old->xref);
+ WARN_ON_ONCE(old->xref);
#endif
dbg_inocache("del %p (ino #%u)\n", old, old->ino);
spin_lock(&c->inocache_lock);
--
2.43.0
^ permalink raw reply
* Forwarded: [PATCH] gfs2: remove WARN_ON_ONCE in gfs2_check_blk_type
From: syzbot @ 2026-04-17 10:12 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
In-Reply-To: <000000000000ca86690612e7cacd@google.com>
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH] gfs2: remove WARN_ON_ONCE in gfs2_check_blk_type
Author: tristmd@gmail.com
From: Tristan Madani <tristan@talencesecurity.com>
#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
gfs2_check_blk_type() calls gfs2_rbm_from_block() and wraps the error
check in WARN_ON_ONCE():
error = gfs2_rbm_from_block(&rbm, no_addr);
if (!WARN_ON_ONCE(error)) {
When the block address falls outside the resource group (which happens
with corrupted on-disk metadata), gfs2_rbm_from_block() returns an
error and the WARN_ON_ONCE fires, producing a kernel stack trace.
The error is already handled correctly by the function -- the block
type test is skipped and the error code propagates to the caller.
Only the WARNING itself is problematic.
Replace the WARN_ON_ONCE with a plain error check and map the error
to -ESTALE for the caller (gfs2_fh_to_dentry).
Reported-by: syzbot+26e96d7e92eed8a21405@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=26e96d7e92eed8a21405
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
---
fs/gfs2/rgrp.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c
index XXXXXXX..XXXXXXX 100644
--- a/fs/gfs2/rgrp.c
+++ b/fs/gfs2/rgrp.c
@@ -2627,7 +2627,10 @@ int gfs2_check_blk_type(struct gfs2_sbd *sdp, u64 no_addr, unsigned int type)
rbm.rgd = rgd;
error = gfs2_rbm_from_block(&rbm, no_addr);
- if (!WARN_ON_ONCE(error)) {
+ if (error) {
+ error = -ESTALE;
+ } else {
/*
* No need to take the local resource group lock here; the
* inode glock of @no_addr provides the necessary
--
2.43.0
^ permalink raw reply
* Re: [PATCH] ntfs3: zero-initialize trailing VBN slot in index entry
From: syzbot @ 2026-04-17 10:12 UTC (permalink / raw)
To: tristmd; +Cc: tristmd, linux-kernel, syzkaller-bugs
In-Reply-To: <20260417101240.2491632-1-tristmd@gmail.com>
> From: Tristan Madani <tristan@talencesecurity.com>
>
> #syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
This crash does not have a reproducer. I cannot test it.
>
> allocations
>
> indx_insert_into_buffer() and indx_delete_entry() each allocate an
> index entry buffer with room for a trailing VBN (virtual block number)
> sub-node pointer:
>
> up_e = kmalloc(sp_size + sizeof(u64), GFP_NOFS);
> memcpy(up_e, sp, sp_size);
>
> re = kmalloc(le16_to_cpu(te->size) + sizeof(u64), GFP_NOFS);
> memcpy(re, te, le16_to_cpu(te->size));
>
> The extra sizeof(u64) bytes reserved for the VBN are left
> uninitialized. When the entry is a leaf node (no sub-nodes), the VBN
> slot is never written, and the uninitialized bytes are eventually
> written to the index buffer on disk. When the index is later read
> back, ntfs_read_hdr() processes these uninitialized bytes, which KMSAN
> flags as a use of uninitialized memory.
>
> Fix this by using kzalloc() instead of kmalloc(), ensuring the VBN
> slot defaults to zero when not explicitly set.
>
> Reported-by: syzbot+2472d48b2d3b2a23a570@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=2472d48b2d3b2a23a570
> Fixes: 522e010b5837 ("fs/ntfs3: Add file operations and implementation")
> Cc: stable@vger.kernel.org
> Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
> ---
> fs/ntfs3/index.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/ntfs3/index.c b/fs/ntfs3/index.c
> index XXXXXXX..XXXXXXX 100644
> --- a/fs/ntfs3/index.c
> +++ b/fs/ntfs3/index.c
> @@ -1838,7 +1838,7 @@ static int indx_insert_into_buffer(struct ntfs_index *indx,
>
> sp_size = le16_to_cpu(sp->size);
> - up_e = kmalloc(sp_size + sizeof(u64), GFP_NOFS);
> + up_e = kzalloc(sp_size + sizeof(u64), GFP_NOFS);
> if (!up_e)
> return -ENOMEM;
> memcpy(up_e, sp, sp_size);
> @@ -2228,7 +2228,7 @@ int indx_delete_entry(struct ntfs_index *indx, struct ntfs_inode *ni,
> }
>
> /* Copy the candidate entry into the replacement entry buffer. */
> - re = kmalloc(le16_to_cpu(te->size) + sizeof(u64), GFP_NOFS);
> + re = kzalloc(le16_to_cpu(te->size) + sizeof(u64), GFP_NOFS);
> if (!re) {
> err = -ENOMEM;
> goto out;
> --
> 2.43.0
^ permalink raw reply
* Forwarded: [PATCH] hfs: return error when bnode already hashed in
From: syzbot @ 2026-04-17 10:12 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
In-Reply-To: <001a11c1461c14bf9e0568fd0cd6@google.com>
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH] hfs: return error when bnode already hashed in
Author: tristmd@gmail.com
From: Tristan Madani <tristan@talencesecurity.com>
#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
hfs_bnode_create
hfs_bnode_create() checks if the requested node number is already
present in the B-tree hash table. If it is, the function emits a
WARN_ON(1) and returns the existing node:
if (node) {
pr_crit("new node %u already hashed?\n", num);
WARN_ON(1);
return node;
}
On crafted HFS images with inconsistent B-tree bitmap data, the
allocator can repeatedly request creation of node 0 which is
already hashed, triggering this WARNING reliably on every mkdir.
Replace the WARN_ON with an error return. The node being already
hashed when creation is requested indicates filesystem corruption
-- returning ERR_PTR(-EIO) allows the caller to handle this
gracefully rather than generating a kernel stack trace.
Reported-by: syzbot+a19ca73b21fe8bc69101@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=a19ca73b21fe8bc69101
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
---
fs/hfs/bnode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/hfs/bnode.c b/fs/hfs/bnode.c
index XXXXXXX..XXXXXXX 100644
--- a/fs/hfs/bnode.c
+++ b/fs/hfs/bnode.c
@@ -517,8 +517,8 @@ struct hfs_bnode *hfs_bnode_create(struct hfs_btree *tree, u32 num)
spin_unlock(&tree->hash_lock);
if (node) {
pr_crit("new node %u already hashed?\n", num);
- WARN_ON(1);
- return node;
+ return ERR_PTR(-EIO);
}
node = __hfs_bnode_create(tree, num);
if (!node)
--
2.43.0
^ permalink raw reply
* Forwarded: [PATCH] gfs2: replace WARN_ON_ONCE with error message in
From: syzbot @ 2026-04-17 10:12 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
In-Reply-To: <69651807.050a0220.eaf7.00b2.GAE@google.com>
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH] gfs2: replace WARN_ON_ONCE with error message in
Author: tristmd@gmail.com
From: Tristan Madani <tristan@talencesecurity.com>
#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
rgblk_free
rgblk_free() uses WARN_ON_ONCE to report when gfs2_rbm_from_block()
fails to map the starting block to a valid resource group position:
if (WARN_ON_ONCE(gfs2_rbm_from_block(&rbm, bstart)))
return;
On crafted GFS2 images with corrupted resource group metadata, this
WARNING fires reliably, producing a full kernel stack trace on every
mount attempt. The function already returns early on failure, so the
error is handled -- only the WARNING itself is problematic.
Replace WARN_ON_ONCE with an fs_warn() message that logs the invalid
block number without triggering a kernel WARNING.
Reported-by: syzbot+3e2c95229d1ab81a0bfd@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=3e2c95229d1ab81a0bfd
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
---
fs/gfs2/rgrp.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c
index XXXXXXX..XXXXXXX 100644
--- a/fs/gfs2/rgrp.c
+++ b/fs/gfs2/rgrp.c
@@ -2265,7 +2265,10 @@ static void rgblk_free(struct gfs2_sbd *sdp, struct gfs2_rgrpd *rgd,
struct gfs2_bitmap *bi, *bi_prev = NULL;
rbm.rgd = rgd;
- if (WARN_ON_ONCE(gfs2_rbm_from_block(&rbm, bstart)))
+ if (gfs2_rbm_from_block(&rbm, bstart)) {
+ fs_warn(sdp, "rgblk_free: block %llu outside rgrp\n",
+ (unsigned long long)bstart);
return;
+ }
while (blen--) {
bi = rbm_bi(&rbm);
--
2.43.0
^ permalink raw reply
* Re: [PATCH] ocfs2: handle RESTART_META gracefully in
From: syzbot @ 2026-04-17 10:12 UTC (permalink / raw)
To: tristmd; +Cc: tristmd, linux-kernel, syzkaller-bugs
In-Reply-To: <20260417101230.2491138-1-tristmd@gmail.com>
> From: Tristan Madani <tristan@talencesecurity.com>
>
> #syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
This crash does not have a reproducer. I cannot test it.
>
> ocfs2_xattr_extend_allocation
>
> ocfs2_xattr_extend_allocation() contains:
>
> BUG_ON(why == RESTART_META);
>
> under the assumption that a metadata-driven allocation restart cannot
> happen for xattr value extents. However, on corrupted filesystem
> images this assumption does not hold, and the BUG_ON crashes the
> kernel.
>
> Replace the BUG_ON with a graceful error return. This lets the
> filesystem report corruption via -EIO rather than panicking.
>
> Reported-by: syzbot+e538032956b1157914a3@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=e538032956b1157914a3
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: stable@vger.kernel.org
> Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
> ---
> fs/ocfs2/xattr.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/fs/ocfs2/xattr.c b/fs/ocfs2/xattr.c
> index XXXXXXX..XXXXXXX 100644
> --- a/fs/ocfs2/xattr.c
> +++ b/fs/ocfs2/xattr.c
> @@ -744,8 +744,12 @@ static int ocfs2_xattr_extend_allocation(struct inode *inode,
> /*
> * We can only fail in case the alloc file doesn't give
> * up enough clusters.
> */
> - BUG_ON(why == RESTART_META);
> + if (why == RESTART_META) {
> + status = -EIO;
> + mlog_errno(status);
> + break;
> + }
>
> credits = ocfs2_calc_extend_credits(inode->i_sb,
> &vb->vb_xv->xr_list);
> --
> 2.43.0
^ permalink raw reply
* Re: [PATCH] ocfs2: replace BUG_ON with error return in
From: syzbot @ 2026-04-17 10:12 UTC (permalink / raw)
To: tristmd; +Cc: tristmd, linux-kernel, syzkaller-bugs
In-Reply-To: <20260417101227.2490949-1-tristmd@gmail.com>
> From: Tristan Madani <tristan@talencesecurity.com>
>
> #syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
This crash does not have a reproducer. I cannot test it.
>
> __ocfs2_page_mkwrite
>
> __ocfs2_page_mkwrite() calls ocfs2_write_end_nolock() and panics the
> kernel via BUG_ON if the return value is not equal to the requested
> length:
>
> err = ocfs2_write_end_nolock(mapping, pos, len, len, fsdata);
> BUG_ON(err != len);
>
> When the filesystem encounters I/O errors or on-disk corruption
> (e.g. from a crafted image), ocfs2_write_end_nolock() can return
> a negative error code or a short write count. This crashes the
> kernel instead of returning an error to userspace.
>
> Replace the BUG_ON with a proper error return path that converts
> the failure to a VM_FAULT_SIGBUS, which gracefully reports the
> fault to the application.
>
> Reported-by: syzbot+ea5aff81e35d189b9335@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=ea5aff81e35d189b9335
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: stable@vger.kernel.org
> Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
> ---
> fs/ocfs2/mmap.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/fs/ocfs2/mmap.c b/fs/ocfs2/mmap.c
> index XXXXXXX..XXXXXXX 100644
> --- a/fs/ocfs2/mmap.c
> +++ b/fs/ocfs2/mmap.c
> @@ -105,7 +105,12 @@ static vm_fault_t __ocfs2_page_mkwrite(struct vm_fault *vmf,
> goto out;
> }
> err = ocfs2_write_end_nolock(mapping, pos, len, len, fsdata);
> - BUG_ON(err != len);
> + if (unlikely(err != len)) {
> + if (err >= 0)
> + err = -EIO;
> + ret = vmf_error(err);
> + goto out;
> + }
> ret = VM_FAULT_LOCKED;
> out:
> return ret;
> --
> 2.43.0
^ permalink raw reply
* Forwarded: [PATCH] ocfs2: zero-initialize quota recovery bitmap allocation
From: syzbot @ 2026-04-17 10:12 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
In-Reply-To: <67ddd191.050a0220.25ae54.006a.GAE@google.com>
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH] ocfs2: zero-initialize quota recovery bitmap allocation
Author: tristmd@gmail.com
From: Tristan Madani <tristan@talencesecurity.com>
#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
ocfs2_add_recovery_chunk() allocates a full block-sized buffer for the
recovery bitmap with kmalloc(), but only copies the meaningful portion
of the on-disk bitmap:
rc->rc_bitmap = kmalloc(sb->s_blocksize, GFP_NOFS);
memcpy(rc->rc_bitmap, dchunk->dqc_bitmap,
(ol_chunk_entries(sb) + 7) >> 3);
The remaining bytes beyond the copied region are left uninitialized.
When ocfs2_recover_local_quota_file() later passes this bitmap to
find_next_bit(), it reads the uninitialized tail bytes, which KMSAN
flags as a use of uninitialized memory.
Fix this by using kzalloc() to ensure the entire buffer is zeroed,
so that find_next_bit() sees zero bits (no recovery needed) for
entries beyond the valid bitmap portion.
Reported-by: syzbot+7ea0b96c4ddb49fd1a70@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=7ea0b96c4ddb49fd1a70
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
---
fs/ocfs2/quota_local.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ocfs2/quota_local.c b/fs/ocfs2/quota_local.c
index XXXXXXX..XXXXXXX 100644
--- a/fs/ocfs2/quota_local.c
+++ b/fs/ocfs2/quota_local.c
@@ -305,7 +305,7 @@ static int ocfs2_add_recovery_chunk(struct super_block *sb,
if (!rc)
return -ENOMEM;
rc->rc_chunk = chunk;
- rc->rc_bitmap = kmalloc(sb->s_blocksize, GFP_NOFS);
+ rc->rc_bitmap = kzalloc(sb->s_blocksize, GFP_NOFS);
if (!rc->rc_bitmap) {
kfree(rc);
return -ENOMEM;
--
2.43.0
^ permalink raw reply
* Forwarded: [PATCH] jfs: validate db_maxfreebud in extBalloc to prevent
From: syzbot @ 2026-04-17 10:12 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
In-Reply-To: <0000000000002e9eb506178cdd71@google.com>
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH] jfs: validate db_maxfreebud in extBalloc to prevent
Author: tristmd@gmail.com
From: Tristan Madani <tristan@talencesecurity.com>
#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
shift-out-of-bounds
extBalloc() computes the maximum allocation size using:
max = (s64) 1 << bmp->db_maxfreebud;
where db_maxfreebud is an s8 read from the on-disk bmap structure.
A crafted JFS image can provide a value of 108, which exceeds the
maximum valid shift exponent for a 64-bit signed integer (63),
triggering a UBSAN shift-out-of-bounds error.
The value -1 is already handled as a sentinel for "no free space",
but no upper bound check exists. Add a validation check to return
-EIO when db_maxfreebud contains an out-of-range value, indicating
on-disk corruption.
Reported-by: syzbot+13e8cd4926977f8337b6@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=13e8cd4926977f8337b6
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
---
fs/jfs/jfs_extent.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/fs/jfs/jfs_extent.c b/fs/jfs/jfs_extent.c
index XXXXXXX..XXXXXXX 100644
--- a/fs/jfs/jfs_extent.c
+++ b/fs/jfs/jfs_extent.c
@@ -326,6 +326,12 @@ extBalloc(struct inode *ip, s64 hint, s64 * nblocks, s64 * blkno)
if (bmp->db_maxfreebud == -1)
return -ENOSPC;
+ if (bmp->db_maxfreebud < 0 || bmp->db_maxfreebud > 63) {
+ jfs_error(ip->i_sb,
+ "invalid db_maxfreebud: %d\n", bmp->db_maxfreebud);
+ return -EIO;
+ }
+
max = (s64) 1 << bmp->db_maxfreebud;
if (*nblocks >= max && *nblocks > nbperpage)
nb = nblks = (max > nbperpage) ? max : nbperpage;
--
2.43.0
^ permalink raw reply
* Forwarded: [PATCH] hfsplus: initialize data in hfs_bnode_read_u16 and
From: syzbot @ 2026-04-17 10:12 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
In-Reply-To: <69decbd0.a00a0220.468cb.006b.GAE@google.com>
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH] hfsplus: initialize data in hfs_bnode_read_u16 and
Author: tristmd@gmail.com
From: Tristan Madani <tristan@talencesecurity.com>
#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
hfs_bnode_read_u8
hfs_bnode_read_u16() and hfs_bnode_read_u8() declare a local variable
on the stack and pass it to hfs_bnode_read() to be filled. However,
when the requested offset is invalid (e.g. from a corrupted filesystem
image), hfs_bnode_read() returns early via the is_bnode_offset_valid()
check without writing to the buffer, leaving the local variable
uninitialized.
The callers then use the uninitialized value via be16_to_cpu() or
directly, which KMSAN flags as a use of uninitialized memory.
This is triggered during hfsplus_bnode_find() when mounting a crafted
HFS+ image with node_size=1 and invalid offsets.
Fix this by zero-initializing the local variables so that an invalid
read returns 0 rather than stack garbage.
Reported-by: syzbot+217eb327242d08197efb@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=217eb327242d08197efb
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
---
fs/hfsplus/bnode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/hfsplus/bnode.c b/fs/hfsplus/bnode.c
index XXXXXXX..XXXXXXX 100644
--- a/fs/hfsplus/bnode.c
+++ b/fs/hfsplus/bnode.c
@@ -98,14 +98,14 @@ void hfs_bnode_read(struct hfs_bnode *node, void *buf, int off, int len)
u16 hfs_bnode_read_u16(struct hfs_bnode *node, int off)
{
- __be16 data;
+ __be16 data = 0;
/* TODO: optimize later... */
hfs_bnode_read(node, &data, off, 2);
return be16_to_cpu(data);
}
u8 hfs_bnode_read_u8(struct hfs_bnode *node, int off)
{
- u8 data;
+ u8 data = 0;
/* TODO: optimize later... */
hfs_bnode_read(node, &data, off, 1);
return data;
--
2.43.0
^ permalink raw reply
* [PATCH 1/2] drm/imagination: Fix segfault when updating ftrace mask
From: Brajesh Gupta @ 2026-04-17 9:42 UTC (permalink / raw)
To: Frank Binns, Matt Coster, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Alessio Belle,
Alexandru Dadu
Cc: dri-devel, linux-kernel, Brajesh Gupta
In-Reply-To: <20260417-ftrace_fix-v1-0-9fefe194592a@imgtec.com>
Fix invalid data access by passing right data for debugfs entry.
[ 171.549793] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[ 171.559248] Mem abort info:
[ 171.562173] ESR = 0x0000000096000044
[ 171.566227] EC = 0x25: DABT (current EL), IL = 32 bits
[ 171.573108] SET = 0, FnV = 0
[ 171.576448] EA = 0, S1PTW = 0
[ 171.579745] FSC = 0x04: level 0 translation fault
[ 171.584760] Data abort info:
[ 171.588012] ISV = 0, ISS = 0x00000044, ISS2 = 0x00000000
[ 171.593734] CM = 0, WnR = 1, TnD = 0, TagAccess = 0
[ 171.598962] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 171.604471] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000083837000
[ 171.611358] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
[ 171.618500] Internal error: Oops: 0000000096000044 [#1] SMP
[ 171.624222] Modules linked in: powervr drm_shmem_helper drm_gpuvm...
[ 171.656580] CPU: 0 UID: 0 PID: 549 Comm: bash Not tainted 7.0.0-rc2-g730b257ba723-dirty #13 PREEMPT
[ 171.665773] Hardware name: BeagleBoard.org BeaglePlay (DT)
[ 171.671296] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 171.678306] pc : pvr_fw_trace_mask_set+0x78/0x154 [powervr]
[ 171.683959] lr : pvr_fw_trace_mask_set+0x4c/0x154 [powervr]
[ 171.689593] sp : ffff8000835ebb90
[ 171.692929] x29: ffff8000835ebc00 x28: ffff000005c60f80 x27: 0000000000000000
[ 171.700130] x26: 0000000000000000 x25: ffff00000504af28 x24: 0000000000000000
[ 171.707324] x23: ffff00000504af50 x22: 0000000000000203 x21: 0000000000000000
[ 171.714518] x20: ffff000005c44a80 x19: ffff000005c457b8 x18: 0000000000000000
[ 171.721715] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaae8887580
[ 171.728908] x14: 0000000000000000 x13: 0000000000000000 x12: ffff8000835ebc30
[ 171.736095] x11: ffff00000504af2a x10: ffff00008504af29 x9 : 0fffffffffffffff
[ 171.743286] x8 : ffff8000835ebbf8 x7 : 0000000000000000 x6 : 000000000000002a
[ 171.750479] x5 : ffff00000504af2e x4 : 0000000000000000 x3 : 0000000000000010
[ 171.757674] x2 : 0000000000000203 x1 : 0000000000000000 x0 : ffff8000835ebba0
[ 171.764871] Call trace:
[ 171.767342] pvr_fw_trace_mask_set+0x78/0x154 [powervr] (P)
[ 171.772984] simple_attr_write_xsigned.isra.0+0xe0/0x19c
[ 171.778341] simple_attr_write+0x18/0x24
[ 171.782296] debugfs_attr_write+0x50/0x98
[ 171.786341] full_proxy_write+0x6c/0xa8
[ 171.790208] vfs_write+0xd4/0x350
[ 171.793561] ksys_write+0x70/0x108
[ 171.796995] __arm64_sys_write+0x1c/0x28
[ 171.800952] invoke_syscall+0x48/0x10c
[ 171.804740] el0_svc_common.constprop.0+0x40/0xe0
[ 171.809487] do_el0_svc+0x1c/0x28
[ 171.812834] el0_svc+0x34/0x108
[ 171.816013] el0t_64_sync_handler+0xa0/0xe4
[ 171.820237] el0t_64_sync+0x198/0x19c
[ 171.823939] Code: 32000262 b90ac293 1a931056 9134e293 (b9000036)
[ 171.830073] ---[ end trace 0000000000000000 ]---
Fixes: a331631496a0 ("drm/imagination: Simplify module parameters")
Signed-off-by: Brajesh Gupta <brajesh.gupta@imgtec.com>
---
drivers/gpu/drm/imagination/pvr_fw_trace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/imagination/pvr_fw_trace.c b/drivers/gpu/drm/imagination/pvr_fw_trace.c
index e154cb35f604..6193811ef7be 100644
--- a/drivers/gpu/drm/imagination/pvr_fw_trace.c
+++ b/drivers/gpu/drm/imagination/pvr_fw_trace.c
@@ -558,6 +558,6 @@ pvr_fw_trace_debugfs_init(struct pvr_device *pvr_dev, struct dentry *dir)
&pvr_fw_trace_fops);
}
- debugfs_create_file("trace_mask", 0600, dir, fw_trace,
+ debugfs_create_file("trace_mask", 0600, dir, pvr_dev,
&pvr_fw_trace_mask_fops);
}
--
2.43.0
^ permalink raw reply related
* Forwarded: [PATCH] udf: propagate iteration error from udf_expand_dir_adinicb()
From: syzbot @ 2026-04-17 10:12 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
In-Reply-To: <683ea90b.a00a0220.d8eae.0060.GAE@google.com>
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH] udf: propagate iteration error from udf_expand_dir_adinicb()
Author: tristmd@gmail.com
From: Tristan Madani <tristan@talencesecurity.com>
#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
udf_expand_dir_adinicb() copies inline directory data into a newly
allocated block and then re-iterates the directory entries to fixup tag
locations. If the iteration fails (e.g. due to I/O error reading the
new block or corrupted on-disk data), the function hits a WARN_ON_ONCE()
and silently returns success.
On a crafted UDF image this WARNING fires reliably because the
underlying block read fails, causing udf_fiiter_init() or
udf_fiiter_advance() to return -EFSCORRUPTED.
Fix this by removing the WARN_ON_ONCE() and propagating the error code
to the caller instead, so that filesystem corruption is handled
gracefully rather than triggering a kernel warning.
Fixes: a27b2923de7e ("udf: Move udf_expand_dir_adinicb() to its callsite")
Reported-by: syzbot+969e250fc7983fc7417c@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=969e250fc7983fc7417c
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
---
fs/udf/namei.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/fs/udf/namei.c b/fs/udf/namei.c
--- a/fs/udf/namei.c
+++ b/fs/udf/namei.c
@@ -206,15 +206,11 @@ static int udf_expand_dir_adinicb(struct inode *inode, udf_pblk_t *block)
else
impuse = NULL;
udf_fiiter_write_fi(&iter, impuse);
}
brelse(dbh);
- /*
- * We don't expect the iteration to fail as the directory has been
- * already verified to be correct
- */
- WARN_ON_ONCE(ret);
udf_fiiter_release(&iter);
- return 0;
+ return ret;
}
static int udf_fiiter_add_entry(struct inode *dir, struct dentry *dentry,
--
2.39.5
^ permalink raw reply
* Forwarded: [PATCH] hfsplus: initialize subfolders field when HAS_FOLDER_COUNT is
From: syzbot @ 2026-04-17 10:12 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
In-Reply-To: <0000000000001db56d06076f6861@google.com>
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH] hfsplus: initialize subfolders field when HAS_FOLDER_COUNT is
Author: tristmd@gmail.com
From: Tristan Madani <tristan@talencesecurity.com>
#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
not set
When reading a folder inode from disk, the subfolders field is only
initialized if the on-disk entry has the HFSPLUS_HAS_FOLDER_COUNT flag
set:
if (folder->flags & cpu_to_be16(HFSPLUS_HAS_FOLDER_COUNT)) {
HFSPLUS_I(inode)->subfolders =
be32_to_cpu(folder->subfolders);
}
If the flag is not set, subfolders is left with stale data from the
slab allocator. The slab constructor (hfsplus_init_once) does set
subfolders = 0, but slab constructors only run on first allocation from
a fresh page -- they do not run on slab object reuse.
This uninitialized field is later read by hfsplus_subfolders_inc() and
hfsplus_subfolders_dec() during directory operations, which KMSAN flags
as a use of uninitialized memory.
Fix this by explicitly setting subfolders to 0 when the folder count
flag is not present on the on-disk entry.
Reported-by: syzbot+93f4402297a457fc6895@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=93f4402297a457fc6895
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
---
fs/hfsplus/inode.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/hfsplus/inode.c b/fs/hfsplus/inode.c
index XXXXXXX..XXXXXXX 100644
--- a/fs/hfsplus/inode.c
+++ b/fs/hfsplus/inode.c
@@ -530,6 +530,8 @@ int hfsplus_cat_read_inode(struct inode *inode, struct hfs_find_data *fd)
if (folder->flags & cpu_to_be16(HFSPLUS_HAS_FOLDER_COUNT)) {
HFSPLUS_I(inode)->subfolders =
be32_to_cpu(folder->subfolders);
+ } else {
+ HFSPLUS_I(inode)->subfolders = 0;
}
inode->i_op = &hfsplus_dir_inode_operations;
inode->i_fop = &hfsplus_dir_operations;
--
2.43.0
^ permalink raw reply
* Forwarded: [PATCH] ntfs3: fix array-index-out-of-bounds in decompress_lznt
From: syzbot @ 2026-04-17 10:12 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
In-Reply-To: <00000000000077d29606186c5e99@google.com>
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH] ntfs3: fix array-index-out-of-bounds in decompress_lznt
Author: tristmd@gmail.com
From: Tristan Madani <tristan@talencesecurity.com>
#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
The index correction loop in decompress_chunk() increments the index
variable without checking against the s_max_off[] array size:
while (unc + s_max_off[index] < up)
index += 1;
When a crafted NTFS image causes the decompressed output pointer (up) to
advance beyond unc + s_max_off[8] (0x1000), the loop reads s_max_off[9]
which is past the end of the 9-element array, triggering UBSAN:
UBSAN: array-index-out-of-bounds in fs/ntfs3/lznt.c:243:16
index 9 is out of range for type 'const size_t[9]'
Commit 9931122d04c6 ("fs/ntfs3: Check if more than chunk-size bytes are
written") partially addressed this by adding a check for up - unc >
LZNT_CHUNK_SIZE before the loop. However, this relies on the implicit
invariant that LZNT_CHUNK_SIZE equals s_max_off[ARRAY_SIZE(s_max_off)-1],
and the check uses strict greater-than which still allows index to reach
the boundary value in edge cases with concurrent modifications to the
unc_end bound.
Add a direct bounds check on index within the while loop condition to
make the code robust regardless of the relationship between
LZNT_CHUNK_SIZE and s_max_off[] values. If index reaches the maximum,
break out of the correction loop -- the entry at s_max_off[8] (0x1000)
already covers the full chunk range.
Found by syzbot.
Reported-by: syzbot+39b2fb0f2638669008ec@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=39b2fb0f2638669008ec
Fixes: 522e010b5837 ("fs/ntfs3: Add compression")
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
---
fs/ntfs3/lznt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ntfs3/lznt.c b/fs/ntfs3/lznt.c
index XXXXXXX..XXXXXXX 100644
--- a/fs/ntfs3/lznt.c
+++ b/fs/ntfs3/lznt.c
@@ -240,7 +240,7 @@ static inline ssize_t decompress_chunk(u8 *unc, u8 *unc_end, const u8 *cmpr,
if (up - unc > LZNT_CHUNK_SIZE)
return -EINVAL;
/* Correct index */
- while (unc + s_max_off[index] < up)
+ while (index < ARRAY_SIZE(s_max_off) - 1 && unc + s_max_off[index] < up)
index += 1;
/* Check the current flag for zero. */
--
2.39.5
^ permalink raw reply
* Forwarded: [PATCH] jfs: validate budmin from dmapctl to prevent shift-out-of-bounds
From: syzbot @ 2026-04-17 10:12 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
In-Reply-To: <68f1c794.a00a0220.361615.000f.GAE@google.com>
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH] jfs: validate budmin from dmapctl to prevent shift-out-of-bounds
Author: tristmd@gmail.com
From: Tristan Madani <tristan@talencesecurity.com>
#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
dbAllocAG() reads budmin directly from an on-disk dmapctl page and uses
it as a shift amount:
blkno += ((s64)(ti - le32_to_cpu(dcp->leafidx))) << budmin;
When the filesystem image is corrupted, budmin (an s8) can be negative,
causing a UBSAN shift-out-of-bounds splat with "shift exponent -1 is
negative".
The existing mount-time validation in dbMount() (commit 7c4af96b24a6)
covers db_agheight/db_agwidth/db_agstart but not budmin in individual
dmapctl pages, since those are read at allocation time, not at mount.
Fix this by validating budmin immediately after reading it from the
dmapctl page. A valid budmin for a dmapctl page must be in the range
[L2BPERDMAP, L2MAXL2SIZE] (i.e. [13, 43]). Reject pages outside this
range as corrupt.
The same pattern exists in dbFindCtl() which also reads budmin from
dmapctl pages and uses it as a shift; add the validation there too.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: syzbot+4b717071f1eecb2972df@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=4b717071f1eecb2972df
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
---
fs/jfs/jfs_dmap.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
index 35e063c9f3a4..a1b2c3d4e5f6 100644
--- a/fs/jfs/jfs_dmap.c
+++ b/fs/jfs/jfs_dmap.c
@@ -1373,6 +1373,13 @@ dbAllocAG(struct bmap * bmp, int agno, s64 nblocks, int l2nb, s64 * results)
dcp = (struct dmapctl *) mp->data;
budmin = dcp->budmin;
+ if (budmin < L2BPERDMAP || budmin > L2MAXL2SIZE) {
+ jfs_error(bmp->db_ipbmap->i_sb,
+ "Corrupt dmapctl budmin %d\n", budmin);
+ release_metapage(mp);
+ return -EIO;
+ }
+
if (dcp->leafidx != cpu_to_le32(CTLLEAFIND)) {
jfs_error(bmp->db_ipbmap->i_sb, "Corrupt dmapctl page\n");
release_metapage(mp);
@@ -1703,6 +1710,13 @@ static int dbFindCtl(struct bmap * bmp, int l2nb, int level, s64 * blkno)
dcp = (struct dmapctl *) mp->data;
budmin = dcp->budmin;
+ if (budmin < L2BPERDMAP || budmin > L2MAXL2SIZE) {
+ jfs_error(bmp->db_ipbmap->i_sb,
+ "Corrupt dmapctl budmin %d\n", budmin);
+ release_metapage(mp);
+ return -EIO;
+ }
+
if (dcp->leafidx != cpu_to_le32(CTLLEAFIND)) {
jfs_error(bmp->db_ipbmap->i_sb,
"Corrupt dmapctl page\n");
--
2.39.2
^ permalink raw reply related
* Forwarded: [PATCH] jfs: zero-initialize btstack to fix KMSAN uninit-value in BT_STACK_DUMP
From: syzbot @ 2026-04-17 10:12 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
In-Reply-To: <68197d2b.050a0220.23d401.2859.GAE@google.com>
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH] jfs: zero-initialize btstack to fix KMSAN uninit-value in BT_STACK_DUMP
Author: tristmd@gmail.com
From: Tristan Madani <tristan@talencesecurity.com>
#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
BT_STACK_DUMP() unconditionally prints all MAXTREEHEIGHT entries of the
btstack->stack[] array. However, only entries between stack[0] and *top
have been written by BT_PUSH(); the rest contain uninitialized stack
data.
When dtSearch() or dtReadFirst() detect a corrupted B-tree that exceeds
MAXTREEHEIGHT, they call BT_STACK_DUMP() for diagnostic output. Reading
the uninitialized entries triggers a KMSAN uninit-value report.
Fix this by only iterating over the entries that were actually pushed
onto the stack (from stack[0] up to but not including top), rather than
blindly dumping all MAXTREEHEIGHT slots.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: syzbot+ba5f49027aace342d24d@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=ba5f49027aace342d24d
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
---
fs/jfs/jfs_btree.h | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/jfs/jfs_btree.h b/fs/jfs/jfs_btree.h
index a1312322..b6737db2 100644
--- a/fs/jfs/jfs_btree.h
+++ b/fs/jfs/jfs_btree.h
@@ -130,10 +130,12 @@ struct btstack {
static inline void BT_STACK_DUMP(struct btstack *btstack)
{
int i;
+ int depth = btstack->top - btstack->stack;
+
printk("btstack dump:\n");
- for (i = 0; i < MAXTREEHEIGHT; i++)
+ for (i = 0; i < depth; i++)
printk(KERN_ERR "bn = %Lx, index = %d\n",
(long long)btstack->stack[i].bn,
btstack->stack[i].index);
}
--
2.39.2
^ permalink raw reply related
* Forwarded: [PATCH] jfs: fix shift-out-of-bounds in dbJoin
From: syzbot @ 2026-04-17 10:11 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
In-Reply-To: <69345a63.a70a0220.38f243.0031.GAE@google.com>
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH] jfs: fix shift-out-of-bounds in dbJoin
Author: tristmd@gmail.com
From: Tristan Madani <tristan@talencesecurity.com>
#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
dbJoin() computes a buddy size via BUDSIZE(newval, budmin), which
expands to 1 << (newval - budmin). If the on-disk tree metadata is
corrupted such that the leaf values or free counts are inconsistent,
newval can exceed budmin + 31, causing a shift-out-of-bounds:
UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:2882:11
shift exponent 132 is too large for 32-bit type 'int'
The maximum meaningful newval for a given tree is budmin + l2nleafs,
since BUDSIZE at that point equals nleafs and the while loop would not
execute. Any value beyond that indicates corrupted metadata.
Add a sanity check before the BUDSIZE call: if newval exceeds
budmin + l2nleafs, return -EIO.
Reported-by: syzbot+fa603ae6b02658401ca7@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=fa603ae6b02658401ca7
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
---
fs/jfs/jfs_dmap.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
index XXXXXXX..XXXXXXX 100644
--- a/fs/jfs/jfs_dmap.c
+++ b/fs/jfs/jfs_dmap.c
@@ -2864,6 +2864,14 @@ static int dbJoin(dmtree_t *tp, int leafno, int newval, bool is_ctl)
if (newval >= tp->dmt_budmin) {
/* pickup a pointer to the leaves of the tree.
*/
+
+ /* Validate newval to prevent shift-out-of-bounds in
+ * BUDSIZE. The maximum meaningful value is budmin +
+ * l2nleafs; anything beyond indicates corrupted metadata.
+ */
+ if (newval > tp->dmt_budmin +
+ le32_to_cpu(tp->dmt_l2nleafs))
+ return -EIO;
leaf = tp->dmt_stree + le32_to_cpu(tp->dmt_leafidx);
/* try to join the specified leaf into a large binary
--
2.39.5
^ permalink raw reply
* Forwarded: [PATCH] jfs: fix off-by-one in dbFindLeaf tree bounds check
From: syzbot @ 2026-04-17 10:11 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
In-Reply-To: <695faa63.050a0220.1c677c.039a.GAE@google.com>
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH] jfs: fix off-by-one in dbFindLeaf tree bounds check
Author: tristmd@gmail.com
From: Tristan Madani <tristan@talencesecurity.com>
#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
The bounds check in dbFindLeaf() uses a strict greater-than comparison
(x + n > max_size) to guard access to the dmt_stree[] array. However,
max_size is set to the array size itself (TREESIZE or CTLTREESIZE), so
valid indices are 0 through max_size-1. When x + n equals max_size, the
check passes but the subsequent array access tp->dmt_stree[x + n] reads
one element past the end of the array.
This is reached when a corrupted filesystem image has an invalid
dmt_height value that causes the tree walk loop to descend beyond the
actual tree depth, pushing the starting index ti to exactly max_size.
For the dmapctl case (CTLTREESIZE = 1365), a height of 6 instead of the
valid maximum of 5 produces: ti = 1 -> 5 -> 21 -> 85 -> 341 -> 1365,
and the access at stree[1365] is one past the s8[1365] array.
UBSAN reports:
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:2976:16
index 1365 is out of range for type 's8[1365]' (aka 'signed char[1365]')
Fix the off-by-one by changing '>' to '>=' so that the boundary index is
correctly treated as out-of-bounds.
Reported-by: syzbot+1afe7ef2d0062e19eeb3@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=1afe7ef2d0062e19eeb3
Fixes: 22cad8bc1d36 ("jfs: fix array-index-out-of-bounds in dbFindLeaf")
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
---
fs/jfs/jfs_dmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
index XXXXXXX..XXXXXXX 100644
--- a/fs/jfs/jfs_dmap.c
+++ b/fs/jfs/jfs_dmap.c
@@ -3058,7 +3058,7 @@ static int dbFindLeaf(dmtree_t *tp, int l2nb, int *leafidx, bool is_ctl)
/* sufficient free space found. move to the next
* level (or quit if this is the last level).
*/
- if (x + n > max_size)
+ if (x + n >= max_size)
return -ENOSPC;
if (l2nb <= tp->dmt_stree[x + n])
break;
--
2.43.0
^ permalink raw reply
* Forwarded: [PATCH] jfs: fix uninit-value in txLock
From: syzbot @ 2026-04-17 10:11 UTC (permalink / raw)
To: linux-kernel, syzkaller-bugs
In-Reply-To: <69727142.050a0220.706b.0027.GAE@google.com>
For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.
***
Subject: [PATCH] jfs: fix uninit-value in txLock
Author: tristmd@gmail.com
From: Tristan Madani <tristan@talencesecurity.com>
#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
txInit() allocates the TxLock array with vmalloc(), which does not zero
memory. The initialization loop only sets the .next field of each tlock
entry to chain them on the freelist. All other fields, including .tid,
.flag, .type, .mp, .ip, and the .lock[] overlay area, remain
uninitialized.
When txLock() looks up a tlock via lid_to_tlock(lid), it reads
tlck->tid to determine whether the page is already locked by the
requesting transaction. If this tlock entry was never previously
allocated and freed (txLockFree only sets .tid and .next), the .tid
field contains uninitialized vmalloc data, which KMSAN flags as a
use of uninitialized memory.
Fix this by replacing vmalloc() with vzalloc() so that all tlock fields
are zero-initialized at allocation time. This ensures .tid == 0 (the
anonymous/free state) for every tlock entry from the start, consistent
with what txLockFree() sets on deallocation.
Reported-by: syzbot+d3a57c32b9112d7b01ec@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=d3a57c32b9112d7b01ec
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
---
fs/jfs/jfs_txnmgr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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
@@ -295,7 +295,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;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH bpf v3 1/2] bpf: Reject TCP_NODELAY in TCP header option callbacks
From: bot+bpf-ci @ 2026-04-17 10:10 UTC (permalink / raw)
To: kafai.wan, martin.lau, daniel, john.fastabend, sdf, ast, andrii,
eddyz87, memxor, song, yonghong.song, jolsa, davem, edumazet,
kuba, pabeni, horms, shuah, jiayuan.chen, kafai.wan, bpf, netdev,
linux-kernel, linux-kselftest
Cc: 2022090917019, dddddd, M202472210, ast, andrii, daniel,
martin.lau, eddyz87, yonghong.song, clm, ihor.solodrai
In-Reply-To: <20260417092035.2299913-2-kafai.wan@linux.dev>
[-- Attachment #1: Type: text/plain, Size: 1997 bytes --]
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 5fa9189eb772..96849f4c1fbc 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -5833,6 +5833,12 @@ BPF_CALL_5(bpf_sock_ops_setsockopt, struct bpf_sock_ops_kern *, bpf_sock,
> if (!is_locked_tcp_sock_ops(bpf_sock))
> return -EOPNOTSUPP;
>
> + /* TCP_NODELAY triggers tcp_push_pending_frames() and re-enters these callbacks. */
> + if ((bpf_sock->op == BPF_SOCK_OPS_HDR_OPT_LEN_CB ||
> + bpf_sock->op == BPF_SOCK_OPS_WRITE_HDR_OPT_CB) &&
> + level == SOL_TCP && optname == TCP_NODELAY)
> + return -EOPNOTSUPP;
> +
Does this fix also need to block TCP_CORK? When bpf_setsockopt() is called
with SOL_TCP and TCP_CORK where the value is 0 (disabling cork), the call
path goes through:
bpf_sock_ops_setsockopt()
-> _bpf_setsockopt()
-> __bpf_setsockopt()
-> sol_tcp_sockopt()
-> do_tcp_setsockopt()
-> __tcp_sock_set_cork(sk, false)
In __tcp_sock_set_cork() at net/ipv4/tcp.c, when cork is disabled, it
unconditionally calls tcp_push_pending_frames(sk):
net/ipv4/tcp.c:__tcp_sock_set_cork() {
...
tcp->nonagle |= TCP_NAGLE_OFF|TCP_NAGLE_PUSH;
tcp_push_pending_frames(sk);
}
This triggers the same recursion chain described in the commit message:
tcp_push_pending_frames()
-> tcp_current_mss()
-> tcp_established_options()
-> bpf_skops_hdr_opt_len()
-> BPF_CGROUP_RUN_PROG_SOCK_OPS_SK (re-enters with
op=BPF_SOCK_OPS_HDR_OPT_LEN_CB)
causing unbounded recursion and kernel stack overflow. Note that enabling
TCP_CORK (val=1) is safe since it doesn't call tcp_push_pending_frames(),
only disabling it (val=0) does.
> return _bpf_setsockopt(bpf_sock->sk, level, optname, optval, optlen);
> }
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/24558395229
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox