* [PATCH 3/7] cifs: invalidate cfid on unlink/rename/rmdir
From: nspmangalore @ 2026-04-14 13:59 UTC (permalink / raw)
To: linux-cifs, smfrench, pc, bharathsm, dhowells, henrique.carvalho,
ematsumiya
Cc: Shyam Prasad N, stable
In-Reply-To: <20260414135918.279802-1-sprasad@microsoft.com>
From: Shyam Prasad N <sprasad@microsoft.com>
Today we do not invalidate the cached_dirent or the entire
parent cfid when a dentry in a dir has been removed/moved.
This change invalidates the parent cfid so that we don't serve
directory contents from the cache.
Cc: <stable@vger.kernel.org>
Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
---
fs/smb/client/inode.c | 40 ++++++++++++++++++++++++++++++++++++++--
1 file changed, 38 insertions(+), 2 deletions(-)
diff --git a/fs/smb/client/inode.c b/fs/smb/client/inode.c
index 888f9e35f14b8..e077df844c819 100644
--- a/fs/smb/client/inode.c
+++ b/fs/smb/client/inode.c
@@ -28,6 +28,23 @@
#include "cached_dir.h"
#include "reparse.h"
+static void cifs_invalidate_cached_dir(struct cifs_tcon *tcon,
+ struct dentry *parent)
+{
+ struct cached_fid *parent_cfid = NULL;
+
+ if (!tcon || !parent)
+ return;
+
+ if (!open_cached_dir_by_dentry(tcon, parent, &parent_cfid)) {
+ mutex_lock(&parent_cfid->dirents.de_mutex);
+ parent_cfid->dirents.is_valid = false;
+ parent_cfid->dirents.is_failed = true;
+ mutex_unlock(&parent_cfid->dirents.de_mutex);
+ close_cached_dir(parent_cfid);
+ }
+}
+
/*
* Set parameters for the netfs library
*/
@@ -322,7 +339,7 @@ cifs_unix_basic_to_fattr(struct cifs_fattr *fattr, FILE_UNIX_BASIC_INFO *info,
fattr->cf_uid = uid;
}
}
-
+
fattr->cf_gid = cifs_sb->ctx->linux_gid;
if (!(sbflags & CIFS_MOUNT_OVERR_GID)) {
u64 id = le64_to_cpu(info->Gid);
@@ -2067,6 +2084,9 @@ static int __cifs_unlink(struct inode *dir, struct dentry *dentry, bool sillyren
cifs_set_file_info(inode, attrs, xid, full_path, origattr);
out_reval:
+ if (!rc && dentry->d_parent)
+ cifs_invalidate_cached_dir(tcon, dentry->d_parent);
+
if (inode) {
cifs_inode = CIFS_I(inode);
cifs_inode->time = 0; /* will force revalidate to get info
@@ -2378,7 +2398,6 @@ int cifs_rmdir(struct inode *inode, struct dentry *direntry)
}
rc = server->ops->rmdir(xid, tcon, full_path, cifs_sb);
- cifs_put_tlink(tlink);
cifsInode = CIFS_I(d_inode(direntry));
@@ -2388,6 +2407,8 @@ int cifs_rmdir(struct inode *inode, struct dentry *direntry)
i_size_write(d_inode(direntry), 0);
clear_nlink(d_inode(direntry));
spin_unlock(&d_inode(direntry)->i_lock);
+ if (direntry->d_parent)
+ cifs_invalidate_cached_dir(tcon, direntry->d_parent);
}
/* force revalidate to go get info when needed */
@@ -2402,6 +2423,7 @@ int cifs_rmdir(struct inode *inode, struct dentry *direntry)
inode_set_ctime_current(d_inode(direntry));
inode_set_mtime_to_ts(inode, inode_set_ctime_current(inode));
+ cifs_put_tlink(tlink);
rmdir_exit:
free_dentry_path(page);
@@ -2501,6 +2523,8 @@ cifs_rename2(struct mnt_idmap *idmap, struct inode *source_dir,
struct cifs_sb_info *cifs_sb;
struct tcon_link *tlink;
struct cifs_tcon *tcon;
+ struct dentry *source_parent;
+ struct dentry *target_parent;
bool rehash = false;
unsigned int xid;
int rc, tmprc;
@@ -2532,6 +2556,8 @@ cifs_rename2(struct mnt_idmap *idmap, struct inode *source_dir,
if (IS_ERR(tlink))
return PTR_ERR(tlink);
tcon = tlink_tcon(tlink);
+ source_parent = source_dentry->d_parent ? dget(source_dentry->d_parent) : NULL;
+ target_parent = target_dentry->d_parent ? dget(target_dentry->d_parent) : NULL;
server = tcon->ses->server;
page1 = alloc_dentry_path();
@@ -2668,11 +2694,21 @@ cifs_rename2(struct mnt_idmap *idmap, struct inode *source_dir,
}
/* force revalidate to go get info when needed */
+ if (!rc) {
+ cifs_invalidate_cached_dir(tcon, source_parent);
+ if (target_parent != source_parent)
+ cifs_invalidate_cached_dir(tcon, target_parent);
+ }
+
CIFS_I(source_dir)->time = CIFS_I(target_dir)->time = 0;
cifs_rename_exit:
if (rehash)
d_rehash(target_dentry);
+ if (target_parent)
+ dput(target_parent);
+ if (source_parent)
+ dput(source_parent);
kfree(info_buf_source);
free_dentry_path(page2);
free_dentry_path(page1);
--
2.43.0
^ permalink raw reply related
* [PATCH 2/7] cifs: abort open_cached_dir if we don't request leases
From: nspmangalore @ 2026-04-14 13:59 UTC (permalink / raw)
To: linux-cifs, smfrench, pc, bharathsm, dhowells, henrique.carvalho,
ematsumiya
Cc: Shyam Prasad N, stable
In-Reply-To: <20260414135918.279802-1-sprasad@microsoft.com>
From: Shyam Prasad N <sprasad@microsoft.com>
It is possible that SMB2_open_init may not set lease context based
on the requested oplock level. This can happen when leases have been
temporarily or permanently disabled. When this happens, we will have
open_cached_dir making an open without lease context and the response
will anyway be rejected by open_cached_dir (thereby forcing a close to
discard this open). That's unnecessary two round-trips to the server.
This change adds a check before making the open request to the server
to make sure that SMB2_open_init did add the expected lease context
to the open in open_cached_dir.
Cc: <stable@vger.kernel.org>
Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
---
fs/smb/client/cached_dir.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/fs/smb/client/cached_dir.c b/fs/smb/client/cached_dir.c
index 04bb95091f498..e9917e5204b00 100644
--- a/fs/smb/client/cached_dir.c
+++ b/fs/smb/client/cached_dir.c
@@ -286,6 +286,13 @@ int open_cached_dir(unsigned int xid, struct cifs_tcon *tcon,
&rqst[0], &oplock, &oparms, utf16_path);
if (rc)
goto oshr_free;
+
+ if (oplock != SMB2_OPLOCK_LEVEL_II) {
+ rc = -EINVAL;
+ cifs_dbg(FYI, "unexpected oplock level %d for cached directory\n", oplock);
+ goto oshr_free;
+ }
+
smb2_set_next_command(tcon, &rqst[0]);
memset(&qi_iov, 0, sizeof(qi_iov));
--
2.43.0
^ permalink raw reply related
* [PATCH 1/7] cifs: change_conf needs to be called for session setup
From: nspmangalore @ 2026-04-14 13:59 UTC (permalink / raw)
To: linux-cifs, smfrench, pc, bharathsm, dhowells, henrique.carvalho,
ematsumiya
Cc: Shyam Prasad N, stable
From: Shyam Prasad N <sprasad@microsoft.com>
Today we skip calling change_conf for negotiates and session setup
requests. This can be a problem for mchan as the immediate next call
after session setup could be due to an I/O that is made on the
mount point. For single channel, this is not a problem as
there will be several calls after setting up session.
This change enforces calling change_conf for the last session setup
response, so that echoes and oplocks are not disabled before the
first request to the server. So if that first request is an open,
it does not need to disable requesting leases.
Cc: <stable@vger.kernel.org>
Signed-off-by: Shyam Prasad N <sprasad@microsoft.com>
---
fs/smb/client/smb2ops.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/fs/smb/client/smb2ops.c b/fs/smb/client/smb2ops.c
index 509fcea28a429..3625030d1912f 100644
--- a/fs/smb/client/smb2ops.c
+++ b/fs/smb/client/smb2ops.c
@@ -111,10 +111,19 @@ smb2_add_credits(struct TCP_Server_Info *server,
cifs_trace_rw_credits_zero_in_flight);
}
server->in_flight--;
+
+ /*
+ * Rebalance credits when an op drains in_flight. For session setup,
+ * do this only when the server actually granted positive credits (>2) so a
+ * newly established secondary channel can reserve echo/oplock credits.
+ */
if (server->in_flight == 0 &&
((optype & CIFS_OP_MASK) != CIFS_NEG_OP) &&
((optype & CIFS_OP_MASK) != CIFS_SESS_OP))
rc = change_conf(server);
+ else if (server->in_flight == 0 &&
+ ((optype & CIFS_OP_MASK) == CIFS_SESS_OP) && add > 2)
+ rc = change_conf(server);
/*
* Sometimes server returns 0 credits on oplock break ack - we need to
* rebalance credits in this case.
--
2.43.0
^ permalink raw reply related
* Re: [regression] Re: Linux 6.12.75
From: Vitaly Chikunov @ 2026-04-14 13:57 UTC (permalink / raw)
To: Thorsten Leemhuis, Sasha Levin
Cc: linux-kernel, stable, gregkh, regressions, Matt Roper,
Rodrigo Vivi
In-Reply-To: <ad2G46EyDs8LBoH_@altlinux.org>
Thorsten, Sasha,
On Tue, Apr 14, 2026 at 03:17:38AM +0300, Vitaly Chikunov wrote:
> On Mon, Apr 13, 2026 at 05:17:30PM +0300, Vitaly Chikunov wrote:
> > On Mon, Apr 13, 2026 at 01:33:18PM +0200, Thorsten Leemhuis wrote:
> > > On 4/2/26 10:44, Vitaly Chikunov wrote:
> > > >
> > > > 1. I cannot find this commit posted on lore.kernel.org to report to
> > > > exact patch.
> > > >
> > > > | From: Matt Roper <matthew.d.roper@intel.com>
> > > > | Date: Tue, 10 Sep 2024 16:47:29 -0700
> > > > | Subject: [PATCH 6.12/sisyphus] drm/xe: Switch MMIO interface to take xe_mmio
> > > > | instead of xe_gt
> > > > |
> > > > | [ Upstream commit a84590c5ceb354d2e9f7f6812cfb3a9709e14afa ]
> > > > |
> > > > | Since much of the MMIO register access done by the driver is to non-GT
> > > > | registers, use of 'xe_gt' in these interfaces has been a long-standing
> > > > | design flaw that's been hard to disentangle.
> > > > [...]
> > > >
> > > > 2. After this patch applied to 6.12.75 there is kernel NULL pointer
> > > > dereference BUG on MSI MAG H670 12th Gen Intel(R) Core(TM) i5-12600K
> > > > with ASRock Intel Arc B580 Challenger [Alchemist], 12GB:
> > > > [...]
> > > > The commit is found not by a git bisect (since it's reported by end
> > > > user and I cannot reproduce it on my hardware) but (by analyzing dmesg)
> > > > with:
> > > > [...]
> > > > Then finding the suspecting commit:
> > > >
> > > > $ git log --oneline -G'XE_LUNARLAKE' v6.12.74..v6.12.75
> > > > 26a40327c25c drm/xe: Switch MMIO interface to take xe_mmio instead of xe_gt
> > > >
> > > > 6.18 and above are not affected by the bug. Also, they have another commit
> > > > modifying the line which is not present in 6.12 branch:
> > > > [...]
> > > > Related drm/xe bug report https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7661
> > > Nobody reacted to this and it seems the gitlab ticket is stalled, too.
> > > So let me ask: can this be resolved by reverting 26a40327c25c in 6.12.y?
>
> It's turned out these two commits are revertible together:
>
> 8f6848b2f6ea ("drm/xe/mmio: Avoid double-adjust in 64-bit reads")
> 26a40327c25c ("drm/xe: Switch MMIO interface to take xe_mmio instead of xe_gt")
>
> I am going to ask the users to test this.
After testing revert of these two commits, users report that regress
does not appear, kernel boots without panic and there is no video artifacts.
So, I kindly ask to revert them from 6.12.y branch if they aren't
critical.
Thanks,
>
> Thanks,
>
> >
> > As of me, this is not easy to revert, as it depends on many other
> > commits, and git does not have tooling to determine all dependant
> > commits for revert. I hope someone from drm subsystem notices this to
> > work on it, or Sasha can pull missing commits or revert this (obviously,
> > he have tooling for this, but I was unable to find it). [I found
> > obsolete references to deps but is seems not used for years and Python
> > git-deps tool seems broken.]
> >
> > What I found is, offending commit is picked due to
> >
> > Stable-dep-of: 4a9b4e1fa52a ("drm/xe/mmio: Avoid double-adjust in 64-bit reads")
> >
> > Which, perhaps, needs to be reverted.
> >
> > Offending commit 26a40327c25c is not tracked in lore.
> > It's part of 9 piece patchset, perhaps they are logically dependent too,
> > so need to be reverted together.
> >
> > The possible fix is part of 6 piece patchset, which does not cherry-pick
> > easily due to conflicts.
> >
> > If someone can produce correct fix we can participate in the tests.
> >
> > Thanks,
> >
> > >
> > > Ciao, Thorsten
^ permalink raw reply
* Re: How to backport (with conflict resolution) CVE-fixing commits to stable releases?
From: Greg Kroah-Hartman @ 2026-04-14 13:52 UTC (permalink / raw)
To: Quentin Schulz
Cc: Jonathan Corbet, Sasha Levin, CVE Assignment Team, workflows,
stable, Heiko Stuebner
In-Reply-To: <ca758574-b32f-4614-88c7-266acf9044c3@cherry.de>
On Tue, Apr 14, 2026 at 01:40:33PM +0200, Quentin Schulz wrote:
> Hi all,
>
> I would like to backport https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a7ac22d53d0990152b108c3f4fe30df45fcb0181
> to linux-6.12.y. It is not a conflict-less cherry-pick as many commits have
> been made to that file between 6.12 and 6.19 when it was fixed, which makes
> git-cherry-pick conflict. I believe I have a patch that implements the same
> logic (moving code around, just that that code is different since it was
> modified after 6.12) in linux-6.12.y that does the original commit in 6.19.
Then backport all of the needed fixes, that's the simplest way, just
send a series of patches.
> My understanding is that this means this patch fits Option 3: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#option-3.
>
> 1) It is not specified there what to do with git trailer tags, e.g.
> Reviewed-by, Acked-by, Tested-by. I'm assuming https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes
You keep them as-is.
See the many backports that are sent to the stable@vger.kernel.org list
for many examples of this.
> 2) I'm also wondering if we should strip the Signed-off-by tags used in the
> original patch's delivery path to Linus. After all, it'll go through a
> different path: to stable "directly". For this specific commit, it doesn't
> matter as the Signed-off-by are for all authors including the maintainer as
> last, but the question remains, I don't believe it's always the case the
> last author Signed-off-by is the same as the maintainers' first and last
> Signed-off-by in the delivery path. What should we do?
Keep the originals please.
> 3) Finally, the last question I have is whether it's required/recommended,
> and if so, how, to tell maintainers of
> https://git.kernel.org/pub/scm/linux/security/vulns.git that this patch is
> for CVE X, in my case https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/cve/published/2026/CVE-2026-22986.dyad.
> Maybe their tooling will automatically pick it up once merged, but I
> couldn't find documentation either in
Maintainers, and stable backports, don't care about CVEs, keep the
wording in the changelog identical and properly mark what the commit id
is that you are backporting. Again, there are many thousands of
examples on the stable mailing list if you want to look in the archives.
By keeping the original git id, the CVE scripts will properly pick this
up when a commit that has been assigned to a CVE in the past is
backported to older kernels, and then the json records will be
automatically updated when the release happens, and pushed out to
cve.org. There's nothing special you need to do here at all.
Hope this helps,
greg k-h
^ permalink raw reply
* [PATCH 6/8] spi: orion: fix controller deregistration
From: Johan Hovold @ 2026-04-14 13:43 UTC (permalink / raw)
To: Mark Brown; +Cc: linux-spi, linux-kernel, Johan Hovold, stable
In-Reply-To: <20260414134319.978196-1-johan@kernel.org>
Make sure to deregister the controller before disabling underlying
resources like clocks during driver unbind.
Fixes: 60cadec9da7b ("spi: new orion_spi driver")
Cc: stable@vger.kernel.org # 2.6.27
Signed-off-by: Johan Hovold <johan@kernel.org>
---
drivers/spi/spi-orion.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-orion.c b/drivers/spi/spi-orion.c
index 7a2186b51b4c..c54cd4ef09bd 100644
--- a/drivers/spi/spi-orion.c
+++ b/drivers/spi/spi-orion.c
@@ -801,10 +801,15 @@ static void orion_spi_remove(struct platform_device *pdev)
struct spi_controller *host = platform_get_drvdata(pdev);
struct orion_spi *spi = spi_controller_get_devdata(host);
+ spi_controller_get(host);
+
+ spi_unregister_controller(host);
+
pm_runtime_get_sync(&pdev->dev);
clk_disable_unprepare(spi->axi_clk);
- spi_unregister_controller(host);
+ spi_controller_put(host);
+
pm_runtime_disable(&pdev->dev);
}
--
2.52.0
^ permalink raw reply related
* [PATCH 7/8] spi: topcliff-pch: fix controller deregistration
From: Johan Hovold @ 2026-04-14 13:43 UTC (permalink / raw)
To: Mark Brown; +Cc: linux-spi, linux-kernel, Johan Hovold, stable, Masayuki Ohtake
In-Reply-To: <20260414134319.978196-1-johan@kernel.org>
Make sure to deregister the controller before disabling and releasing
underlying resources like interrupts and DMA during driver unbind.
Fixes: e8b17b5b3f30 ("spi/topcliff: Add topcliff platform controller hub (PCH) spi bus driver")
Cc: stable@vger.kernel.org # 2.6.37
Cc: Masayuki Ohtake <masa-korg@dsn.okisemi.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
---
drivers/spi/spi-topcliff-pch.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-topcliff-pch.c b/drivers/spi/spi-topcliff-pch.c
index cae2dcefabea..c120436434d0 100644
--- a/drivers/spi/spi-topcliff-pch.c
+++ b/drivers/spi/spi-topcliff-pch.c
@@ -1406,6 +1406,10 @@ static void pch_spi_pd_remove(struct platform_device *plat_dev)
dev_dbg(&plat_dev->dev, "%s:[ch%d] irq=%d\n",
__func__, plat_dev->id, board_dat->pdev->irq);
+ spi_controller_get(data->host);
+
+ spi_unregister_controller(data->host);
+
if (use_dma)
pch_free_dma_buf(board_dat, data);
@@ -1433,7 +1437,8 @@ static void pch_spi_pd_remove(struct platform_device *plat_dev)
}
pci_iounmap(board_dat->pdev, data->io_remap_addr);
- spi_unregister_controller(data->host);
+
+ spi_controller_put(data->host);
}
#ifdef CONFIG_PM
static int pch_spi_pd_suspend(struct platform_device *pd_dev,
--
2.52.0
^ permalink raw reply related
* [PATCH 3/8] spi: mpc52xx: fix controller deregistration
From: Johan Hovold @ 2026-04-14 13:43 UTC (permalink / raw)
To: Mark Brown
Cc: linux-spi, linux-kernel, Johan Hovold, stable, Grant Likely,
Luotao Fu
In-Reply-To: <20260414134319.978196-1-johan@kernel.org>
Make sure to deregister the controller before disabling and releasing
underlying resources like interrupts and gpios during driver unbind.
Fixes: 42bbb70980f3 ("powerpc/5200: Add mpc5200-spi (non-PSC) device driver")
Fixes: b8d4e2ce60b6 ("mpc52xx_spi: add gpio chipselect")
Cc: stable@vger.kernel.org # 2.6.33
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Luotao Fu <l.fu@pengutronix.de>
Signed-off-by: Johan Hovold <johan@kernel.org>
---
drivers/spi/spi-mpc52xx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-mpc52xx.c b/drivers/spi/spi-mpc52xx.c
index 05bbd3795e7d..823b49f8ece2 100644
--- a/drivers/spi/spi-mpc52xx.c
+++ b/drivers/spi/spi-mpc52xx.c
@@ -517,6 +517,8 @@ static void mpc52xx_spi_remove(struct platform_device *op)
struct mpc52xx_spi *ms = spi_controller_get_devdata(host);
int i;
+ spi_unregister_controller(host);
+
cancel_work_sync(&ms->work);
free_irq(ms->irq0, ms);
free_irq(ms->irq1, ms);
@@ -525,7 +527,6 @@ static void mpc52xx_spi_remove(struct platform_device *op)
gpiod_put(ms->gpio_cs[i]);
kfree(ms->gpio_cs);
- spi_unregister_controller(host);
iounmap(ms->regs);
spi_controller_put(host);
}
--
2.52.0
^ permalink raw reply related
* [PATCH 8/8] spi: topcliff-pch: fix use-after-free on unbind
From: Johan Hovold @ 2026-04-14 13:43 UTC (permalink / raw)
To: Mark Brown; +Cc: linux-spi, linux-kernel, Johan Hovold, stable, Tomoya MORINAGA
In-Reply-To: <20260414134319.978196-1-johan@kernel.org>
Give the driver a chance to flush its queue before releasing the DMA
buffers on driver unbind
Fixes: c37f3c2749b5 ("spi/topcliff_pch: DMA support")
Cc: stable@vger.kernel.org # 3.1
Cc: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
---
drivers/spi/spi-topcliff-pch.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-topcliff-pch.c b/drivers/spi/spi-topcliff-pch.c
index c120436434d0..14d11450e86d 100644
--- a/drivers/spi/spi-topcliff-pch.c
+++ b/drivers/spi/spi-topcliff-pch.c
@@ -1410,9 +1410,6 @@ static void pch_spi_pd_remove(struct platform_device *plat_dev)
spi_unregister_controller(data->host);
- if (use_dma)
- pch_free_dma_buf(board_dat, data);
-
/* check for any pending messages; no action is taken if the queue
* is still full; but at least we tried. Unload anyway */
count = 500;
@@ -1436,6 +1433,9 @@ static void pch_spi_pd_remove(struct platform_device *plat_dev)
free_irq(board_dat->pdev->irq, data);
}
+ if (use_dma)
+ pch_free_dma_buf(board_dat, data);
+
pci_iounmap(board_dat->pdev, data->io_remap_addr);
spi_controller_put(data->host);
--
2.52.0
^ permalink raw reply related
* [PATCH 1/8] spi: cadence: fix controller deregistration
From: Johan Hovold @ 2026-04-14 13:43 UTC (permalink / raw)
To: Mark Brown; +Cc: linux-spi, linux-kernel, Johan Hovold, stable, Harini Katakam
In-Reply-To: <20260414134319.978196-1-johan@kernel.org>
Make sure to deregister the controller before disabling underlying
resources like clocks during driver unbind.
Fixes: c474b3866546 ("spi: Add driver for Cadence SPI controller")
Cc: stable@vger.kernel.org # 3.16
Cc: Harini Katakam <harinik@xilinx.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
---
drivers/spi/spi-cadence.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-cadence.c b/drivers/spi/spi-cadence.c
index caa7a57e6d27..08d7dabe818d 100644
--- a/drivers/spi/spi-cadence.c
+++ b/drivers/spi/spi-cadence.c
@@ -777,6 +777,10 @@ static void cdns_spi_remove(struct platform_device *pdev)
struct spi_controller *ctlr = platform_get_drvdata(pdev);
struct cdns_spi *xspi = spi_controller_get_devdata(ctlr);
+ spi_controller_get(ctlr);
+
+ spi_unregister_controller(ctlr);
+
cdns_spi_write(xspi, CDNS_SPI_ER, CDNS_SPI_ER_DISABLE);
if (!spi_controller_is_target(ctlr)) {
@@ -784,7 +788,7 @@ static void cdns_spi_remove(struct platform_device *pdev)
pm_runtime_set_suspended(&pdev->dev);
}
- spi_unregister_controller(ctlr);
+ spi_controller_put(ctlr);
}
/**
--
2.52.0
^ permalink raw reply related
* [PATCH 4/8] spi: mpc52xx: fix use-after-free on unbind
From: Johan Hovold @ 2026-04-14 13:43 UTC (permalink / raw)
To: Mark Brown; +Cc: linux-spi, linux-kernel, Johan Hovold, stable, Pei Xiao
In-Reply-To: <20260414134319.978196-1-johan@kernel.org>
The state machine work is scheduled by the interrupt handler and
therefore needs to be cancelled after disabling interrupts to avoid a
potential use-after-free.
Fixes: 984836621aad ("spi: mpc52xx: Add cancel_work_sync before module remove")
Cc: stable@vger.kernel.org
Cc: Pei Xiao <xiaopei01@kylinos.cn>
Signed-off-by: Johan Hovold <johan@kernel.org>
---
drivers/spi/spi-mpc52xx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-mpc52xx.c b/drivers/spi/spi-mpc52xx.c
index 823b49f8ece2..c8c8e6bdf421 100644
--- a/drivers/spi/spi-mpc52xx.c
+++ b/drivers/spi/spi-mpc52xx.c
@@ -519,10 +519,11 @@ static void mpc52xx_spi_remove(struct platform_device *op)
spi_unregister_controller(host);
- cancel_work_sync(&ms->work);
free_irq(ms->irq0, ms);
free_irq(ms->irq1, ms);
+ cancel_work_sync(&ms->work);
+
for (i = 0; i < ms->gpio_cs_count; i++)
gpiod_put(ms->gpio_cs[i]);
--
2.52.0
^ permalink raw reply related
* [PATCH 2/8] spi: cadence-quadspi: fix controller deregistration
From: Johan Hovold @ 2026-04-14 13:43 UTC (permalink / raw)
To: Mark Brown
Cc: linux-spi, linux-kernel, Johan Hovold, stable,
Khairul Anuar Romli
In-Reply-To: <20260414134319.978196-1-johan@kernel.org>
Make sure to deregister the controller before dropping the reference
count that allows new operations to start to allow SPI drivers to do I/O
during deregistration.
Fixes: 7446284023e8 ("spi: cadence-quadspi: Implement refcount to handle unbind during busy")
Cc: stable@vger.kernel.org # 6.17
Cc: Khairul Anuar Romli <khairul.anuar.romli@altera.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
---
drivers/spi/spi-cadence-quadspi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c
index 2ead419e896e..50ef65fc5ded 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -2020,13 +2020,13 @@ static void cqspi_remove(struct platform_device *pdev)
ddata = of_device_get_match_data(dev);
+ spi_unregister_controller(cqspi->host);
+
refcount_set(&cqspi->refcount, 0);
if (!refcount_dec_and_test(&cqspi->inflight_ops))
cqspi_wait_idle(cqspi);
- spi_unregister_controller(cqspi->host);
-
if (cqspi->rx_chan)
dma_release_channel(cqspi->rx_chan);
--
2.52.0
^ permalink raw reply related
* [PATCH 5/8] spi: mxic: fix controller deregistration
From: Johan Hovold @ 2026-04-14 13:43 UTC (permalink / raw)
To: Mark Brown; +Cc: linux-spi, linux-kernel, Johan Hovold, stable, Mason Yang
In-Reply-To: <20260414134319.978196-1-johan@kernel.org>
Make sure to deregister the controller before disabling underlying
resources like clocks (via runtime pm) during driver unbind.
Fixes: b942d80b0a39 ("spi: Add MXIC controller driver")
Cc: stable@vger.kernel.org # 5.0: cc53711b2191
Cc: stable@vger.kernel.org # 5.0
Cc: Mason Yang <masonccyang@mxic.com.tw>
Signed-off-by: Johan Hovold <johan@kernel.org>
---
drivers/spi/spi-mxic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
index f9369c69911c..b0e7fc828a50 100644
--- a/drivers/spi/spi-mxic.c
+++ b/drivers/spi/spi-mxic.c
@@ -832,9 +832,10 @@ static void mxic_spi_remove(struct platform_device *pdev)
struct spi_controller *host = platform_get_drvdata(pdev);
struct mxic_spi *mxic = spi_controller_get_devdata(host);
+ spi_unregister_controller(host);
+
pm_runtime_disable(&pdev->dev);
mxic_spi_mem_ecc_remove(mxic);
- spi_unregister_controller(host);
}
static const struct of_device_id mxic_spi_of_ids[] = {
--
2.52.0
^ permalink raw reply related
* Re: [PATCH] PCI/IOV: Fix out-of-bounds access in sriov_restore_vf_rebar_state()
From: Michał Winiarski @ 2026-04-14 13:34 UTC (permalink / raw)
To: Marco Nenciarini
Cc: Bjorn Helgaas, Ilpo Järvinen, linux-pci, linux-kernel,
stable
In-Reply-To: <20260408163922.1740497-1-mnencia@kcore.it>
On Wed, Apr 08, 2026 at 06:39:22PM +0200, Marco Nenciarini wrote:
> sriov_restore_vf_rebar_state() extracts bar_idx from the VF Resizable
> BAR control register using a 3-bit field (PCI_VF_REBAR_CTRL_BAR_IDX,
> bits 0-2), which yields values in the range 0-7. This value is then
> used to index into dev->sriov->barsz[], which has PCI_SRIOV_NUM_BARS
> (6) entries.
>
> If the PCI config space read returns garbage data (e.g. 0xffffffff when
> the device is no longer accessible on the bus), bar_idx is 7, causing
> an out-of-bounds array access. UBSAN reports this as:
>
> UBSAN: array-index-out-of-bounds in drivers/pci/iov.c:948:51
> index 7 is out of range for type 'resource_size_t [6]'
>
> This was observed on an NVIDIA RTX PRO 1000 GPU (GB207GLM) that fell
> off the PCIe bus during a failed GC6 power state exit. The subsequent
> pci_restore_state() call triggered the UBSAN splat in
> sriov_restore_vf_rebar_state() since all config space reads returned
> 0xffffffff.
>
> Add a bounds check on bar_idx before using it as an array index to
> prevent the out-of-bounds access.
>
> Fixes: 5a8f77e24a30 ("PCI/IOV: Restore VF resizable BAR state after reset")
> Cc: stable@vger.kernel.org
> Signed-off-by: Marco Nenciarini <mnencia@kcore.it>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
Thanks,
-Michał
> ---
> Cc: Michał Winiarski <michal.winiarski@intel.com>
> Cc: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
>
> drivers/pci/iov.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
> index 00784a60b..521f2cb64 100644
> --- a/drivers/pci/iov.c
> +++ b/drivers/pci/iov.c
> @@ -946,6 +946,8 @@ static void sriov_restore_vf_rebar_state(struct pci_dev *dev)
>
> pci_read_config_dword(dev, pos + PCI_VF_REBAR_CTRL, &ctrl);
> bar_idx = FIELD_GET(PCI_VF_REBAR_CTRL_BAR_IDX, ctrl);
> + if (bar_idx >= PCI_SRIOV_NUM_BARS)
> + continue;
> size = pci_rebar_bytes_to_size(dev->sriov->barsz[bar_idx]);
> ctrl &= ~PCI_VF_REBAR_CTRL_BAR_SIZE;
> ctrl |= FIELD_PREP(PCI_VF_REBAR_CTRL_BAR_SIZE, size);
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH v2] ALSA: control: Validate buf_len before strnlen() in snd_ctl_elem_init_enum_names()
From: Takashi Iwai @ 2026-04-14 13:31 UTC (permalink / raw)
To: Ziqing Chen; +Cc: tiwai, perex, linux-sound, linux-kernel, stable, Ziqing Chen
In-Reply-To: <20260414132437.261304-1-chenziqing@xiaomi.com>
On Tue, 14 Apr 2026 15:24:37 +0200,
Ziqing Chen wrote:
>
> snd_ctl_elem_init_enum_names() advances pointer p through the names
> buffer while decrementing buf_len. If buf_len reaches zero but items
> remain, the next iteration calls strnlen(p, 0).
>
> While strnlen(p, 0) returns 0 and would hit the existing name_len == 0
> error path, CONFIG_FORTIFY_SOURCE's fortified strnlen() first checks
> maxlen against __builtin_dynamic_object_size(). When Clang loses track
> of p's object size inside the loop, this triggers a BRK exception panic
> before the return value is examined.
>
> Add a buf_len == 0 guard at the loop entry to prevent calling fortified
> strnlen() on an exhausted buffer.
>
> Found by kernel fuzz testing through Xiaomi Smartphone.
>
> Fixes: 8d448162bda5 ("ALSA: control: add support for ENUMERATED user space controls")
> Cc: stable@vger.kernel.org
> Signed-off-by: Ziqing Chen <chenziqing@xiaomi.com>
Applied now. Thanks.
Takashi
^ permalink raw reply
* Re: [PATCH 15901/15901] drm/vmwgfx: fix NULL pointer dereference in vmw_validation_bo_fence()
From: Christian König @ 2026-04-14 13:25 UTC (permalink / raw)
To: popov.nkv, Zack Rusin
Cc: bcm-kernel-feedback-list, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Sumit Semwal,
Deepak Rawat, Sinclair Yeh, Thomas Hellstrom, dri-devel,
linux-kernel, linux-media, linaro-mm-sig, lvc-project, stable
In-Reply-To: <20260414105529.9883-1-popov.nkv@gmail.com>
On 4/14/26 12:55, popov.nkv@gmail.com wrote:
> From: Vladimir Popov <popov.nkv@gmail.com>
>
> If vmw_execbuf_fence_commands() call fails in
> vmw_kms_helper_validation_finish(), it sets *p_fence = NULL. If
> ctx->bo_list is not empty, the caller, vmw_kms_helper_validation_finish(),
> passes the fence through a chain of functions to dma_fence_is_array(),
> which causes a NULL pointer dereference in dma_fence_is_array():
>
> vmw_kms_helper_validation_finish() // pass NULL fence
> vmw_validation_done()
> vmw_validation_bo_fence()
> ttm_eu_fence_buffer_objects() // pass NULL fence
> dma_resv_add_fence()
> dma_fence_is_container()
> dma_fence_is_array() // NULL deref
Well good catch, but that is clearly not the right fix.
I'm not an expert for the vmwgfx code but in case of an error vmw_validation_revert() should be called an not vmw_kms_helper_validation_finish().
Regards,
Christian.
>
> Fix this by adding a NULL check in vmw_validation_bo_fence(): if the fence
> is NULL, fall back to ttm_eu_backoff_reservation()to safely release
> the buffer object reservations without attempting to add a NULL fence to
> dma_resv. This is safe because when fence is NULL, vmw_fallback_wait()
> has already been called inside vmw_execbuf_fence_commands() to synchronize
> the GPU.
>
> Found by Linux Verification Center (linuxtesting.org) with SVACE.
>
> Fixes: 038ecc503236 ("drm/vmwgfx: Add a validation module v2")
> Cc: stable@vger.kernel.org
> Signed-off-by: Vladimir Popov <popov.nkv@gmail.com>
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_validation.h | 13 ++++++++++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_validation.h b/drivers/gpu/drm/vmwgfx/vmwgfx_validation.h
> index 353d837907d8..fc04555ca505 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_validation.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_validation.h
> @@ -127,16 +127,23 @@ vmw_validation_bo_reserve(struct vmw_validation_context *ctx,
> * vmw_validation_bo_fence - Unreserve and fence buffer objects registered
> * with a validation context
> * @ctx: The validation context
> + * @fence: Fence with which to fence all buffer objects taking part in the
> + * command submission.
> *
> * This function unreserves the buffer objects previously reserved using
> - * vmw_validation_bo_reserve, and fences them with a fence object.
> + * vmw_validation_bo_reserve, and fences them with a fence object if the
> + * given fence object is not NULL.
> */
> static inline void
> vmw_validation_bo_fence(struct vmw_validation_context *ctx,
> struct vmw_fence_obj *fence)
> {
> - ttm_eu_fence_buffer_objects(&ctx->ticket, &ctx->bo_list,
> - (void *) fence);
> + /* fence is able to be NULL if vmw_execbuf_fence_commands() fails */
> + if (fence)
> + ttm_eu_fence_buffer_objects(&ctx->ticket, &ctx->bo_list,
> + (void *)fence);
> + else
> + ttm_eu_backoff_reservation(&ctx->ticket, &ctx->bo_list);
> }
>
> /**
> --
> 2.43.0
>
^ permalink raw reply
* [PATCH v2] ALSA: control: Validate buf_len before strnlen() in snd_ctl_elem_init_enum_names()
From: Ziqing Chen @ 2026-04-14 13:24 UTC (permalink / raw)
To: tiwai, perex; +Cc: linux-sound, linux-kernel, stable, Ziqing Chen
snd_ctl_elem_init_enum_names() advances pointer p through the names
buffer while decrementing buf_len. If buf_len reaches zero but items
remain, the next iteration calls strnlen(p, 0).
While strnlen(p, 0) returns 0 and would hit the existing name_len == 0
error path, CONFIG_FORTIFY_SOURCE's fortified strnlen() first checks
maxlen against __builtin_dynamic_object_size(). When Clang loses track
of p's object size inside the loop, this triggers a BRK exception panic
before the return value is examined.
Add a buf_len == 0 guard at the loop entry to prevent calling fortified
strnlen() on an exhausted buffer.
Found by kernel fuzz testing through Xiaomi Smartphone.
Fixes: 8d448162bda5 ("ALSA: control: add support for ENUMERATED user space controls")
Cc: stable@vger.kernel.org
Signed-off-by: Ziqing Chen <chenziqing@xiaomi.com>
---
sound/core/control.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/sound/core/control.c b/sound/core/control.c
index 0ddade871b52..6ceb5f977fcd 100644
--- a/sound/core/control.c
+++ b/sound/core/control.c
@@ -1574,6 +1574,10 @@ static int snd_ctl_elem_init_enum_names(struct user_element *ue)
/* check that there are enough valid names */
p = names;
for (i = 0; i < ue->info.value.enumerated.items; ++i) {
+ if (buf_len == 0) {
+ kvfree(names);
+ return -EINVAL;
+ }
name_len = strnlen(p, buf_len);
if (name_len == 0 || name_len >= 64 || name_len == buf_len) {
kvfree(names);
--
2.52.0
^ permalink raw reply related
* Re: [PATCH] net: wwan: t7xx: validate port_count against message length in t7xx_port_enum_msg_handler
From: Willy Tarreau @ 2026-04-14 13:17 UTC (permalink / raw)
To: Paolo Abeni
Cc: Pavitra Jha, chandrashekar.devegowda, linux-wwan, netdev, stable
In-Reply-To: <3b67dedb-3472-4322-9a30-32bf8e3cef99@redhat.com>
On Tue, Apr 14, 2026 at 11:41:54AM +0200, Paolo Abeni wrote:
> On 4/11/26 10:39 AM, Pavitra Jha wrote:
> > t7xx_port_enum_msg_handler() uses the modem-supplied port_count field as
> > a loop bound over port_msg->data[] without checking that the message buffer
> > contains sufficient data. A modem sending port_count=65535 in a 12-byte
> > buffer triggers a slab-out-of-bounds read of up to 262140 bytes.
> >
> > Add a struct_size() check after extracting port_count and before the loop.
> > Pass msg_len from both call sites: skb->len at the DPMAIF path after
> > skb_pull(), and the captured rt_feature->data_len at the handshake path.
> >
> > Fixes: 1e3e8eb9b6e3 ("net: wwan: t7xx: Add control DMA interface")
>
> Wrong fixes tag:
>
> fatal: ambiguous argument '1e3e8eb9b6e3': unknown revision or path not
> in the working tree.
Interesting, there isn't a single digit correct here! The matching one
I'm finding based on the subject is:
39d439047f1d ("net: wwan: t7xx: Add control DMA interface")
Willy
> > diff --git a/drivers/net/wwan/t7xx/t7xx_port_ctrl_msg.c b/drivers/net/wwan/t7xx/t7xx_port_ctrl_msg.c
> > index ae632ef96..d984a688d 100644
> > --- a/drivers/net/wwan/t7xx/t7xx_port_ctrl_msg.c
> > +++ b/drivers/net/wwan/t7xx/t7xx_port_ctrl_msg.c
> > @@ -124,7 +124,7 @@ static int fsm_ee_message_handler(struct t7xx_port *port, struct t7xx_fsm_ctl *c
> > * * 0 - Success.
> > * * -EFAULT - Message check failure.
> > */
> > -int t7xx_port_enum_msg_handler(struct t7xx_modem *md, void *msg)
> > +int t7xx_port_enum_msg_handler(struct t7xx_modem *md, void *msg, size_t msg_len)
>
> Undocumented new argument
>
> /P
^ permalink raw reply
* Re: [PATCH] libperf: fix parallel build race with header install
From: Ian Rogers @ 2026-04-14 13:13 UTC (permalink / raw)
To: Gaurav Sharma
Cc: linux-perf-users, acme, namhyung, stable, linux-kernel,
Gaurav Sharma
In-Reply-To: <20260414071242.95637-1-mgsharm@amazon.com>
On Tue, Apr 14, 2026 at 12:13 AM Gaurav Sharma <sgaurav00719@gmail.com> wrote:
>
> When perf is built with high parallelism (-j128), there is a race
> condition between the install_headers and libperf.a targets in the
> libperf sub-build. Both are invoked as targets of a single make
> invocation from Makefile.perf:
>
> $(MAKE) -C $(LIBPERF_DIR) ... $@ install_headers
>
> The perf tool's exported CFLAGS includes -I$(LIBPERF_OUTPUT)/include
> which points to the header install destination. The coreutils install
> command creates the destination file (truncated) before writing content.
> If the compiler runs between file creation and content write, it
> includes an empty header, causing incomplete type and missing prototype
> errors in the libperf source files.
>
> Fix this by making the libperf compilation target depend on
> install_headers, ensuring all headers are fully installed before any
> source files are compiled.
>
> Fixes: 91009a3a9913 ("perf build: Install libperf locally when building")
> Cc: stable@vger.kernel.org
> Signed-off-by: Gaurav Sharma <mgsharm@amazon.com>
I believe this was addressed by:
https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/commit/tools/lib/perf/Makefile?h=perf-tools-next&id=8c5b40678c63be6b85f1c2dc8c8b89d632faf988
Thanks,
Ian
> ---
> tools/lib/perf/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/lib/perf/Makefile b/tools/lib/perf/Makefile
> index 32301a1d8f0c..8372cd9919b7 100644
> --- a/tools/lib/perf/Makefile
> +++ b/tools/lib/perf/Makefile
> @@ -99,7 +99,7 @@ $(LIBAPI)-clean:
> $(call QUIET_CLEAN, libapi)
> $(Q)$(MAKE) -C $(LIB_DIR) O=$(OUTPUT) clean >/dev/null
>
> -$(LIBPERF_IN): FORCE
> +$(LIBPERF_IN): install_headers FORCE
> $(Q)$(MAKE) $(build)=libperf
>
> $(LIBPERF_A): $(LIBPERF_IN)
> --
> 2.50.1 (Apple Git-155)
>
^ permalink raw reply
* Re: [PATCH] mm/migrate_device: fix double unlock
From: Sunny Patel @ 2026-04-14 13:13 UTC (permalink / raw)
To: david
Cc: akpm, apopple, balbirs, byungchul, gourry, joshua.hahnjy,
linux-kernel, linux-mm, matthew.brost, nueralspacetech, rakie.kim,
stable, ying.huang, ziy
In-Reply-To: <2c0c00aa-7fb2-4d7b-90b3-0309c13468ce@kernel.org>
On 4/14/26 20:03, David Hildenbrand (Arm) wrote:
> As raised by Matthew, the entire code block is dead code:
> https://lore.kernel.org/linux-mm/20260212014611.416695-1-dave@stgolabs.net/
> And I even Ack'ed it /facepalm
> So we should take that (cleanup) patch instead. Thanks!
+1
Thanks for the pointer. I will drop my cleanup patch and defer
to above patch at the above link instead since it already
addresses the same dead code block and has your Ack.
Thanks,
Sunny Patel
^ permalink raw reply
* Re: [PATCH 2/2] drm/radeon: fix integer overflow in radeon_align_pitch()
From: Alex Deucher @ 2026-04-14 13:11 UTC (permalink / raw)
To: Werner Kasselman
Cc: Alex Deucher, Christian König, David Airlie, Simona Vetter,
Thomas Zimmermann, amd-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
In-Reply-To: <20260406225008.2787532-3-werner@verivus.com>
On Tue, Apr 7, 2026 at 3:41 AM Werner Kasselman <werner@verivus.ai> wrote:
>
> radeon_align_pitch() has the same integer overflow as amdgpu's variant:
> 'aligned * cpp' can overflow signed int to 0 when alignment rounding
> pushes the width past INT_MAX/cpp. This produces a 0-byte GEM buffer
> via radeon_mode_dumb_create(), reachable from unprivileged userspace
> via DRM_IOCTL_MODE_CREATE_DUMB on the render node.
>
> Add an overflow check in radeon_align_pitch() and reject zero pitch/size
> in radeon_mode_dumb_create().
>
> Found via AST-based call-graph analysis using sqry.
>
> Fixes: ff72145badb8 ("drm: dumb scanout create/mmap for intel/radeon (v3)")
> Cc: stable@vger.kernel.org
> Signed-off-by: Werner Kasselman <werner@verivus.com>
Can you fix this up similar to the amdgpu patch?
Thanks,
Alex
> ---
> drivers/gpu/drm/radeon/radeon_gem.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c
> index 20fc87409f2e..2cd179fef347 100644
> --- a/drivers/gpu/drm/radeon/radeon_gem.c
> +++ b/drivers/gpu/drm/radeon/radeon_gem.c
> @@ -828,6 +828,11 @@ int radeon_align_pitch(struct radeon_device *rdev, int width, int cpp, bool tile
>
> aligned += pitch_mask;
> aligned &= ~pitch_mask;
> +
> + /* Guard against integer overflow in aligned * cpp. */
> + if (aligned > INT_MAX / (cpp ? cpp : 1) || aligned <= 0)
> + return 0;
> +
> return aligned * cpp;
> }
>
> @@ -842,8 +847,12 @@ int radeon_mode_dumb_create(struct drm_file *file_priv,
>
> args->pitch = radeon_align_pitch(rdev, args->width,
> DIV_ROUND_UP(args->bpp, 8), 0);
> + if (!args->pitch)
> + return -EINVAL;
> args->size = (u64)args->pitch * args->height;
> args->size = ALIGN(args->size, PAGE_SIZE);
> + if (!args->size)
> + return -EINVAL;
>
> r = radeon_gem_object_create(rdev, args->size, 0,
> RADEON_GEM_DOMAIN_VRAM, 0,
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v4 00/11] Add support for the TI BQ25792 battery charger
From: Mark Brown @ 2026-04-14 13:07 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chris Morgan, Liam Girdwood, Sebastian Reichel, Alexey Charkov
Cc: devicetree, linux-kernel, Sebastian Reichel, linux-pm,
Krzysztof Kozlowski, stable
In-Reply-To: <20260311-bq25792-v4-0-7213415d9eec@flipper.net>
On Wed, 11 Mar 2026 15:56:13 +0400, Alexey Charkov wrote:
> This adds support for the TI BQ25792 battery charger, which is similar in
> overall logic to the BQ25703A, but has a different register layout and
> slightly different lower-level programming logic.
>
> The series is organized as follows:
> - Patch 1 adds the new variant to the existing DT binding, including the
> changes in electrical characteristics
> - Patches 2-4 are minor cleanups to the existing BQ25703A OTG regulator
> driver, slimming down the code and making it more reusable for the new
> BQ25792 variant
> - Patch 5 is a logical fix to the BQ25703A clamping logic for VSYSMIN
> (this is a standalone fix which can be applied independently and may be
> backported to stable)
> - Patches 6-8 are slight refactoring of the existing BQ25703A charger
> driver to make it more reusable for the new BQ25792 variant
> - Patch 9 adds platform data to distinguish between the two variants in
> the parent MFD driver, and binds it to the new compatible string
> - Patches 10-11 add variant-specific code to support the new BQ25792
> variant in the regulator part and the charger part respectively,
> selected by the platform data added in patch 9
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
Thanks!
[01/11] dt-bindings: mfd: ti,bq25703a: Expand to include BQ25792
(no commit info)
[02/11] regulator: bq257xx: Remove reference to the parent MFD's dev
https://git.kernel.org/broonie/misc/c/aef4d87f2c1f
[03/11] regulator: bq257xx: Drop the regulator_dev from the driver data
(no commit info)
[04/11] regulator: bq257xx: Make OTG enable GPIO really optional
https://git.kernel.org/broonie/misc/c/de76a763805d
[05/11] power: supply: bq257xx: Fix VSYSMIN clamping logic
(no commit info)
[06/11] power: supply: bq257xx: Make the default current limit a per-chip attribute
(no commit info)
[07/11] power: supply: bq257xx: Consistently use indirect get/set helpers
(no commit info)
[08/11] power: supply: bq257xx: Add fields for 'charging' and 'overvoltage' states
(no commit info)
[09/11] mfd: bq257xx: Add BQ25792 support
(no commit info)
[10/11] regulator: bq257xx: Add support for BQ25792
(no commit info)
[11/11] power: supply: bq257xx: Add support for BQ25792
(no commit info)
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* [RESEND PATCH] ALSA: control: Validate buf_len before strnlen() in snd_ctl_elem_init_enum_names()
From: Ziqing Chen @ 2026-04-14 13:03 UTC (permalink / raw)
To: tiwai, perex; +Cc: linux-sound, linux-kernel, stable, Ziqing Chen
In-Reply-To: <87ik9tsukj.wl-tiwai@suse.de>
snd_ctl_elem_init_enum_names() advances pointer p through the names
buffer while decrementing buf_len. If buf_len reaches zero but items
remain, the next iteration calls strnlen(p, 0).
While strnlen(p, 0) returns 0 and would hit the existing name_len == 0
error path, CONFIG_FORTIFY_SOURCE's fortified strnlen() first checks
maxlen against __builtin_dynamic_object_size(). When Clang loses track
of p's object size inside the loop, this triggers a BRK exception panic
before the return value is examined.
Add a buf_len == 0 guard at the loop entry to prevent calling fortified
strnlen() on an exhausted buffer.
Found by kernel fuzz testing through Xiaomi Smartphone.
Fixes: 8d448162bda5 ("ALSA: control: add support for ENUMERATED user space controls")
Cc: stable@vger.kernel.org
Signed-off-by: Ziqing Chen <chenziqing@xiaomi.com>
---
sound/core/control.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/sound/core/control.c b/sound/core/control.c
index 0ddade871b52..6ceb5f977fcd 100644
--- a/sound/core/control.c
+++ b/sound/core/control.c
@@ -1574,6 +1574,10 @@ static int snd_ctl_elem_init_enum_names(struct user_element *ue)
/* check that there are enough valid names */
p = names;
for (i = 0; i < ue->info.value.enumerated.items; ++i) {
+ if (buf_len == 0) {
+ kvfree(names);
+ return -EINVAL;
+ }
name_len = strnlen(p, buf_len);
if (name_len == 0 || name_len >= 64 || name_len == buf_len) {
kvfree(names);
--
2.52.0
^ permalink raw reply related
* Re: [PATCH] iommu: Fix bypass of IOMMU readiness check for multi-IOMMU devices
From: Tudor Ambarus @ 2026-04-14 13:04 UTC (permalink / raw)
To: Robin Murphy, Jason Gunthorpe
Cc: Joerg Roedel, Will Deacon, Lorenzo Pieralisi, Rob Herring (Arm),
Joerg Roedel, Bjorn Helgaas, iommu, linux-kernel, peter.griffin,
andre.draszik, willmcvicker, jyescas, kernel-team, stable
In-Reply-To: <39d07d46-fee3-48a3-a991-b293e9d498db@arm.com>
[-- Attachment #1: Type: text/plain, Size: 8309 bytes --]
Hi, Robin,
Thanks for the educative answers.
On 4/2/26 5:20 PM, Robin Murphy wrote:
> On 2026-04-02 12:59 pm, Jason Gunthorpe wrote:
>> On Thu, Apr 02, 2026 at 02:25:54PM +0300, Tudor Ambarus wrote:
>>
>>> I can probably track whether all instances are ready, and defer if any
>>> is not ready, but then I'll force the iommu clients to use the sketchy
>>> replay path, which seems like a bad idea, according to Robin's feedback.
>>
>> I didn't think that was sketchy, it is part of the boot ordering
>> system to ensure that the iommu driver(s) is probed before the client
>> devices.
>>
>> Half operating a device is definately going to get things into trouble
>> with broken/incomplete domain attachments at least.
>
> The Exynos driver itself is actually fine, and doing everything right. We'll never have a "half-configured" client device in IOMMU API terms currently - only once both instances are registered such that both of_xlate calls can succeed (one for each specifier in the client device's "iommus" property) will we proceed to calling probe_device, which will then work as normal.
I assume this is true because of core_initcall(exynos_iommu_init);
Or is it something else that guarantees that both the IOMMU instances
are registered at exynos_iommu_of_xlate() time? The instance's drvdata
is set before the instance registers, and the rest of the code in
exynos_iommu_of_xlate constructs the client's list of iommu instances.
>
> The issue here is purely in the race-avoidance scheme within of_iommu_configure() itself, which hasn't accounted for the fact that when it's looping over multiple specifiers, they don't necessarily all target the same IOMMU node. And it's only during a window where the instance targeted by the first specifier happens to be registered already, and the second is currently in the middle of registering.
Allow me to give an example. I added some extra prints to catch things.
I attached a diff if you want to see exactly where. I stripped a bit
the log so that it's easier to follow. I added comments.
19471000.drmdecon describe 19840000.sysmmu and 19c40000.sysmmu in its
"iommus" dt property.
[ 2.308076][ T1] samsung-sysmmu-v9 19840000.sysmmu: tudor: samsung_sysmmu_device_probe: after iommu_device_register
^ first instance registered
[ 2.310095][ T86] platform 19471000.drmdecon: tudor: really_probe: enter for driver exynos-decon
^ client in really_probe()
[ 2.311634][ T1] samsung-sysmmu-v9 19c40000.sysmmu: tudor: samsung_sysmmu_device_probe: before iommu_device_register
^ second instance right before calling iommu_device_register()
[ 2.312358][ T86] exynos-decon 19471000.drmdecon: tudor: really_probe: after setting dev->driver exynos-decon
^ client set dev->driver!
[ 2.348787][ T86] exynos-decon 19471000.drmdecon: tudor: of_iommu_configure: of_iommu_configure_device err = 0, dev_iommu_present = 0
^ of_xlate succeeded for both instances
We're in the client's really_probe() path. Shall of_xlate fail if the iommu instance is not registered yet?
[ 2.349277][ T86] exynos-decon 19471000.drmdecon: tudor: of_iommu_configure: call iommu_probe_device new dev_iommu_present = 1, dev->iommu = 000000007deaca98
^ initial dev->iommu was not set, we prepare to call iommu_probe_device() even if dev->iommu was set in the of_iommu_configure_device() call
The thread is going to sleep now, it can't acquire iommu_probe_device_lock
[ 2.358261][ T1] exynos-decon 19471000.drmdecon: tudor: iommu_init_device: bus->dma_configure not called dev->iommu = 000000007deaca98, dev->iommu_group = 0000000000000000, dev->iommu->fwspec = 00000000896797d4 dev->driver = 000000008821e7b2
^ inside iommu_init_device(), dev->bus->dma_configure(dev) is NOT called. Then it calls ops->probe_device() and ops->device_group(), succeeding.
[ 2.360561][ T1] ------------[ cut here ]------------
[ 2.360729][ T1] exynos-decon 19471000.drmdecon: late IOMMU probe at driver bind, something fishy here!
[ 2.361153][ T1] WARNING: drivers/iommu/iommu.c:650 at __iommu_probe_device+0x3a0/0x608, CPU#7: init/1
[ 2.369032][ T1] CPU: 7 UID: 0 PID: 1 Comm: init Tainted: G S O 6.19.0-mainline-g2887d9327e73-dirty #1 PREEMPT 12ccb00dc0e1a023f9ae52bf43dc85a3c6f0cd0b
[ 2.369592][ T1] Tainted: [S]=CPU_OUT_OF_SPEC, [O]=OOT_MODULE
[ 2.369848][ T1] Hardware name: ZUMA PRO KOMODO EVT 1.0 Broadcom GNSS board based on ZUMA PRO (DT)
[ 2.370205][ T1] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
[ 2.370499][ T1] pc : __iommu_probe_device+0x3a0/0x608
[ 2.370681][ T1] lr : __iommu_probe_device+0x3a0/0x608
[ 2.370915][ T1] sp : ffffc0008005b4c0
[ 2.371043][ T1] x29: ffffc0008005b4c0 x28: ffff80001d791290 x27: 0000000000000000
[ 2.371372][ T1] x26: 000000000000001d x25: ffffc0008005b598 x24: ffffe42571f2dd08
[ 2.371674][ T1] x23: ffff80001e00e490 x22: ffff800005744e00 x21: ffffe4256fd687e0
[ 2.371976][ T1] x20: ffffc0008005b598 x19: ffff800005b79810 x18: ffffe425731e13c0
[ 2.372277][ T1] x17: 000000008c623181 x16: 000000008c623181 x15: 0000000000000000
[ 2.372553][ T1] x14: 0000000000000003 x13: ffff800a7eef8000 x12: 0000000000000003
[ 2.372881][ T1] x11: 0000000000000003 x10: 00000000ffff7fff x9 : 90cf001dbb0ee800
[ 2.373184][ T1] x8 : 90cf001dbb0ee800 x7 : ffffe42571d610b4 x6 : 0000000000000000
[ 2.373486][ T1] x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffffc0008005b210
[ 2.373788][ T1] x2 : 0000000000000dba x1 : 0000000000000000 x0 : 0000000000000056
[ 2.374089][ T1] Call trace:
[ 2.374185][ T1] __iommu_probe_device+0x3a0/0x608 (P)
[ 2.374419][ T1] probe_iommu_group+0x3c/0x68
[ 2.374570][ T1] bus_for_each_dev+0x104/0x160
[ 2.374752][ T1] iommu_device_register+0xe0/0x274
[ 2.374947][ T1] samsung_sysmmu_device_probe+0x720/0x938 [samsung_iommu_v9 756cd85ee7308d7c98df18fc7d1a25a4db1266e9]
[ 2.375392][ T1] platform_probe+0x74/0xb8
[ 2.375533][ T1] really_probe+0x1a4/0x50c
[ 2.375702][ T1] __driver_probe_device+0x98/0xd4
[ 2.375892][ T1] driver_probe_device+0x3c/0x220
[ 2.376080][ T1] __driver_attach+0x118/0x1f8
[ 2.376258][ T1] bus_for_each_dev+0x104/0x160
[ 2.376440][ T1] driver_attach+0x24/0x34
[ 2.376603][ T1] bus_add_driver+0x140/0x2ac
[ 2.376779][ T1] driver_register+0x68/0x104
[ 2.376953][ T1] __platform_driver_register+0x20/0x30
[ 2.377186][ T1] init_module+0x20/0x3fd8 [samsung_iommu_v9 756cd85ee7308d7c98df18fc7d1a25a4db1266e9]
[ 2.377524][ T1] do_one_initcall+0x100/0x3ac
[ 2.377702][ T1] do_init_module+0x58/0x264
[ 2.377872][ T1] load_module+0x1244/0x1290
[ 2.378047][ T1] __arm64_sys_finit_module+0x248/0x334
[ 2.378280][ T1] invoke_syscall+0x58/0xe4
[ 2.378423][ T1] el0_svc_common+0x8c/0xd8
[ 2.378590][ T1] do_el0_svc+0x1c/0x28
[ 2.378745][ T1] el0_svc+0x54/0x1c4
[ 2.378892][ T1] el0t_64_sync_handler+0x84/0x12c
[ 2.379084][ T1] el0t_64_sync+0x1c4/0x1c8
[ 2.379252][ T1] irq event stamp: 822284
[ 2.379413][ T1] hardirqs last enabled at (822283): [<ffffe42570bc7dc0>] __console_unlock+0x64/0xbc
[ 2.379800][ T1] hardirqs last disabled at (822284): [<ffffe42571d52748>] el1_brk64+0x20/0x54
[ 2.380139][ T1] softirqs last enabled at (822092): [<ffffe42570b02efc>] handle_softirqs+0x484/0x504
[ 2.380505][ T1] softirqs last disabled at (822085): [<ffffe42570a10518>] __do_softirq+0x14/0x20
[ 2.380854][ T1] ---[ end trace 0000000000000000 ]---
[ 2.381058][ T1] exynos-decon 19471000.drmdecon: Adding to iommu group 1
[ 2.382126][ T86] exynos-decon 19471000.drmdecon: tudor: __iommu_probe_device: enter
[ 2.382420][ T86] exynos-decon 19471000.drmdecon: tudor: of_iommu_configure: after iommu_probe_device err = 0
[ 2.382734][ T86] exynos-decon 19471000.drmdecon: tudor: iommu_device_use_default_domain: we hit !group->default_domain
^ returns -EPROBE_DEFER
[ 2.383125][ T86] exynos-decon 19471000.drmdecon: tudor: really_probe: after dma_configure exynos-decon ret = -517
[ 2.383445][ T86] exynos-decon 19471000.drmdecon: tudor: really_probe: clear dev->driver exynos-decon
[
[-- Attachment #2: diff --]
[-- Type: text/plain, Size: 6417 bytes --]
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index bea8da5f8a3a..efa1634214e6 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -609,6 +609,9 @@ static int really_probe(struct device *dev, const struct device_driver *drv)
bool test_remove = IS_ENABLED(CONFIG_DEBUG_TEST_DRIVER_REMOVE) &&
!drv->suppress_bind_attrs;
int ret, link_ret;
+ bool is_decon = (dev_name(dev) && strstr(dev_name(dev), "drmdecon"));
+
+ dev_err(dev, "tudor: %s enter for driver %s\n", __func__, drv->name);
if (defer_all_probes) {
/*
@@ -616,11 +619,14 @@ static int really_probe(struct device *dev, const struct device_driver *drv)
* device_block_probing() which, in turn, will call
* wait_for_device_probe() right after that to avoid any races.
*/
- dev_dbg(dev, "Driver %s force probe deferral\n", drv->name);
+ dev_err(dev, "Driver %s force probe deferral\n", drv->name);
return -EPROBE_DEFER;
}
link_ret = device_links_check_suppliers(dev);
+ if (is_decon)
+ dev_err(dev, "tudor: %s device_links_check_suppliers() ret %d\n",
+ __func__, link_ret);
if (link_ret == -EPROBE_DEFER)
return link_ret;
@@ -633,7 +639,13 @@ static int really_probe(struct device *dev, const struct device_driver *drv)
}
re_probe:
+ if (is_decon)
+ dev_err(dev, "tudor: %s before setting dev->driver %s\n",
+ __func__, drv->name);
device_set_driver(dev, drv);
+ if (is_decon)
+ dev_err(dev, "tudor: %s after setting dev->driver %s\n",
+ __func__, drv->name);
/* If using pinctrl, bind pins now before probing */
ret = pinctrl_bind_pins(dev);
@@ -641,7 +653,13 @@ static int really_probe(struct device *dev, const struct device_driver *drv)
goto pinctrl_bind_failed;
if (dev->bus->dma_configure) {
+ if (is_decon)
+ dev_err(dev, "tudor: %s before dma_configure %s\n",
+ __func__, drv->name);
ret = dev->bus->dma_configure(dev);
+ if (is_decon)
+ dev_err(dev, "tudor: %s after dma_configure %s ret = %d\n",
+ __func__, drv->name, ret);
if (ret)
goto pinctrl_bind_failed;
}
@@ -723,6 +741,10 @@ static int really_probe(struct device *dev, const struct device_driver *drv)
if (dev->bus && dev->bus->dma_cleanup)
dev->bus->dma_cleanup(dev);
pinctrl_bind_failed:
+
+ if (is_decon)
+ dev_err(dev, "tudor: %s clear dev->driver %s\n",
+ __func__, drv->name);
device_links_no_driver(dev);
device_unbind_cleanup(dev);
done:
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 4926a43118e6..35042965b0f7 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -450,6 +450,11 @@ static int iommu_init_device(struct device *dev)
struct iommu_device *iommu_dev;
struct iommu_group *group;
int ret;
+ bool is_decon = (dev_name(dev) && strstr(dev_name(dev), "drmdecon"));
+
+ if (is_decon)
+ dev_err(dev, "tudor: %s, dev->iommu = %p, dev->iommu_group = %p\n",
+ __func__, dev->iommu, dev->iommu_group);
if (!dev_iommu_get(dev))
return -ENOMEM;
@@ -464,10 +469,19 @@ static int iommu_init_device(struct device *dev)
mutex_unlock(&iommu_probe_device_lock);
dev->bus->dma_configure(dev);
mutex_lock(&iommu_probe_device_lock);
+ if (is_decon)
+ dev_err(dev, "tudor: %s, after bus->dma_configure(): dev->iommu = %p, dev->iommu_group = %p\n",
+ __func__, dev->iommu, dev->iommu_group);
/* If another instance finished the job for us, skip it */
if (!dev->iommu || dev->iommu_group)
return -ENODEV;
+ } else {
+ if (is_decon)
+ dev_err(dev, "tudor: %s, bus->dma_configure not called dev->iommu = %p, dev->iommu_group = %p, dev->iommu->fwspec = %p dev->driver = %p\n",
+ __func__, dev->iommu, dev->iommu_group, dev->iommu->fwspec, dev->driver);
}
+
+
/*
* At this point, relevant devices either now have a fwspec which will
* match ops registered with a non-NULL fwnode, or we can reasonably
@@ -608,7 +622,10 @@ static int __iommu_probe_device(struct device *dev, struct list_head *group_list
struct iommu_group *group;
struct group_device *gdev;
int ret;
+ bool is_decon = (dev_name(dev) && strstr(dev_name(dev), "drmdecon"));
+ if (is_decon)
+ dev_err(dev, "tudor: %s enter\n", __func__);
/*
* Serialise to avoid races between IOMMU drivers registering in
* parallel and/or the "replay" calls from ACPI/OF code via client
@@ -3241,6 +3258,7 @@ int iommu_device_use_default_domain(struct device *dev)
/* Caller is the driver core during the pre-probe path */
struct iommu_group *group = dev->iommu_group;
int ret = 0;
+ bool is_decon = (dev_name(dev) && strstr(dev_name(dev), "drmdecon"));
if (!group)
return 0;
@@ -3248,6 +3266,9 @@ int iommu_device_use_default_domain(struct device *dev)
mutex_lock(&group->mutex);
/* We may race against bus_iommu_probe() finalising groups here */
if (!group->default_domain) {
+ if (is_decon)
+ dev_err(dev, "tudor: %s, we hit !group->default_domain\n",
+ __func__);
ret = -EPROBE_DEFER;
goto unlock_out;
}
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 6b989a62def2..af89f1c874dc 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -118,6 +118,7 @@ int of_iommu_configure(struct device *dev, struct device_node *master_np,
{
bool dev_iommu_present;
int err;
+ bool is_decon = (dev_name(dev) && strstr(dev_name(dev), "drmdecon"));
if (!master_np)
return -ENODEV;
@@ -155,13 +156,25 @@ int of_iommu_configure(struct device *dev, struct device_node *master_np,
dev_iommu_free(dev);
mutex_unlock(&iommu_probe_device_lock);
+ if (is_decon)
+ dev_err(dev, "tudor: %s: of_iommu_configure_device err = %d, dev_iommu_present = %d\n",
+ __func__, err, dev_iommu_present);
/*
* If we're not on the iommu_probe_device() path (as indicated by the
* initial dev->iommu) then try to simulate it. This should no longer
* happen unless of_dma_configure() is being misused outside bus code.
*/
- if (!err && dev->bus && !dev_iommu_present)
+ if (!err && dev->bus && !dev_iommu_present) {
+ if (is_decon) {
+ dev_iommu_present = dev->iommu;
+ dev_err(dev, "tudor: %s call iommu_probe_device new dev_iommu_present = %d, dev->iommu = %p\n",
+ __func__, dev_iommu_present, dev->iommu);
+ }
err = iommu_probe_device(dev);
+ if (is_decon)
+ dev_err(dev, "tudor: %s after iommu_probe_device err = %d\n",
+ __func__, err);
+ }
if (err && err != -EPROBE_DEFER)
dev_dbg(dev, "Adding to IOMMU failed: %d\n", err);
^ permalink raw reply related
* Re: [PATCH] staging: rtl8723bs: fix frame length underflow in OnAuthClient
From: Dan Carpenter @ 2026-04-14 12:48 UTC (permalink / raw)
To: Alexandru Hossu
Cc: gregkh, linux-staging, linux-kernel, dan.carpenter, hansg, stable
In-Reply-To: <20260414100804.871764-1-hossu.alexandru@gmail.com>
On Tue, Apr 14, 2026 at 12:08:04PM +0200, Alexandru Hossu wrote:
> If pkt_len is less than WLAN_HDR_A3_LEN + offset + 6, the reads of
> the seq and status fields go beyond the frame buffer. Additionally,
> when pkt_len < WLAN_HDR_A3_LEN + _AUTH_IE_OFFSET_ (30 bytes), the
> subtraction passed to rtw_get_ie() wraps around since pkt_len is
> unsigned, causing rtw_get_ie() to scan well past the end of the buffer.
>
> Add a minimum length check after computing offset to reject frames
> that are too short before any fixed field access.
>
> Reported-by: Dan Carpenter <error27@gmail.com>
> Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Alexandru Hossu <hossu.alexandru@gmail.com>
> ---
> drivers/staging/rtl8723bs/core/rtw_mlme_ext.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
> index 90f27665667a..6b0ac54ad3d4 100644
> --- a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
> +++ b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
> @@ -869,6 +869,9 @@ unsigned int OnAuthClient(struct adapter *padapter, union recv_frame *precv_fram
>
> offset = (GetPrivacy(pframe)) ? 4 : 0;
^^^^^^
Do we know for sure that this is within bounds? And there is earlier
code which pokes in pframe as well. This code is quite complicated.
I looked at how to do bounds checking but it all seems pretty
complicated to me and I haven't investigated this enough to know the
right answers.
regards,
dan carpenter
>
> + if (pkt_len < WLAN_HDR_A3_LEN + offset + 6)
> + goto authclnt_fail;
> +
> seq = le16_to_cpu(*(__le16 *)((SIZE_PTR)pframe + WLAN_HDR_A3_LEN + offset + 2));
> status = le16_to_cpu(*(__le16 *)((SIZE_PTR)pframe + WLAN_HDR_A3_LEN + offset + 4));
>
> --
> 2.53.0
^ 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