From hamzamahfooz at linux.microsoft.com  Wed Jul  1 02:39:32 2026
From: hamzamahfooz at linux.microsoft.com (Hamza Mahfooz)
Date: Tue, 30 Jun 2026 19:39:32 -0400
Subject: [lvc-project] [PATCH 6.6 0/4] fix kernel crash for xfs/235 test
In-Reply-To: <20260625183421.GO6070@frogsfrogsfrogs>
References: <aisAxyXVxf4wql2u@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
	<20260612233110.2-1-sashal@kernel.org>
	<ajBQPNuKCruxhkXX@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
	<ajD3Gb-vQkGU0N6b@nidhogg.toxiclabs.cc>
	<ajFQPY2m2A6ltvTH@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
	<ajFabPtI8UGfkyix@nidhogg.toxiclabs.cc>
	<CACzhbgS59uCYhjX80__+nPjEx=N8mKUsYyFS1+aRDpMA-b-VXQ@mail.gmail.com>
	<CAOQ4uxgXqmP49FV3b_cKDD_703bRHz0fjm=k=FmNytsPpnKx3g@mail.gmail.com>
	<ajKSytW_sBFJaBTW@nidhogg.toxiclabs.cc>
	<20260625183421.GO6070@frogsfrogsfrogs>
Message-ID: <akRTtCIZZ0IZ0Omc@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>

On Thu, Jun 25, 2026 at 11:34:21AM -0700, Darrick J. Wong wrote:
> On Wed, Jun 17, 2026 at 02:31:01PM +0200, Carlos Maiolino wrote:
> > On Wed, Jun 17, 2026 at 11:19:25AM +0200, Amir Goldstein wrote:
> > > On Tue, Jun 16, 2026 at 7:33?PM Leah Rumancik <leah.rumancik at gmail.com> wrote:
> > > >
> > > > I have changed teams so I no longer work on kernel and I don't believe
> > > > my xfs maintenance work was backfilled ;(
> > > >
> > > > On Tue, Jun 16, 2026 at 7:19?AM Carlos Maiolino <cem at kernel.org> wrote:
> > > > >
> > > > > On Tue, Jun 16, 2026 at 09:31:41AM -0400, Hamza Mahfooz wrote:
> > > > > > Cc: linux-xfs at vger.kernel.org
> > > > > >
> > > > > > On Tue, Jun 16, 2026 at 09:13:45AM +0200, Carlos Maiolino wrote:
> > > > > > > On Mon, Jun 15, 2026 at 03:19:24PM -0400, Hamza Mahfooz wrote:
> > > > > > > > Cc: Carlos Maiolino <cem at kernel.org>
> > > > > > >
> > > > > > > FWIW I don't maintain the stable trees I really don't have time for
> > > > > > > that. Darrick/Leah have been doing a best effort case for that, but
> > > > > > > again, this is mostly a best effort so we shouldn't expect them to be
> > > > > > > looking/picking up every single possible patch suggested for stable.
> > > > > > >
> > > > > >
> > > > > > Now that you mention it, the xfs-stable mailing list seems to be pretty
> > > > > > much dead (i.e. the last time fixes from it were merged into stable was
> > > > > > almost a year ago). I guess no one is really working on it anymore?
> > > > >
> > > > > IIRC Darrick started it, I personally never worked on it, but I didn't
> > > > > follow the evolution there.
> > > 
> > > I think at this point we can officially declare xfs in stable <= 6.6
> > > unmaintained
> > > maybe need to send patches to LTS MAINTAINERS.
> > > 
> > > The best chance in this case to apply the requested fix to 6.6.y is that the
> > > author (Darrick) approves it.
> > 
> > Unfortunately this might be true. But let's wait for Darrick's input
> > please. He's on vacations this week so will be unfair to make any
> > decisions in this matter without his input.
> > Also he has been still poking people to tag patches with LTS versions
> > so even though he might not me dealing with the xfs-stable, he might still
> > be driving work on LTS trees.
> 
> I've really only been doing QA work on 6.12/6.18 LTS.  Ted Tso might
> still be doing the older ones.  Catherine left Oracle last year.

Any idea on potential paths forward for getting this series in
particular into 6.6.y?

> 
> --D


From kuba at kernel.org  Wed Jul  1 03:16:31 2026
From: kuba at kernel.org (Jakub Kicinski)
Date: Tue, 30 Jun 2026 17:16:31 -0700
Subject: [lvc-project] [PATCH net-next] chelsio: delete the line with
 the pidx initialization
In-Reply-To: <20260629130839.218-1-markov.gi@npc-ksb.ru>
References: <20260629130839.218-1-markov.gi@npc-ksb.ru>
Message-ID: <20260630171631.233056be@kernel.org>

On Mon, 29 Jun 2026 16:08:35 +0300 Markov Gleb wrote:
> The value of pidx is overwritten immediately after exiting the "if" block.
> 
> Remove pidx ptr initialization string from conditional block.

shrug?
-- 
pw-bot: reject


From patchwork-bot+netdevbpf at kernel.org  Wed Jul  1 03:30:06 2026
From: patchwork-bot+netdevbpf at kernel.org (patchwork-bot+netdevbpf at kernel.org)
Date: Wed, 01 Jul 2026 00:30:06 +0000
Subject: [lvc-project] [PATCH net] cxgb4: Fix decode strings dump for T6
	adapters
In-Reply-To: <20260629130856.1168-1-markov.gi@npc-ksb.ru>
References: <20260629130856.1168-1-markov.gi@npc-ksb.ru>
Message-ID: <178286580614.352416.780057618509971566.git-patchwork-notify@kernel.org>

Hello:

This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba at kernel.org>:

On Mon, 29 Jun 2026 16:08:54 +0300 you wrote:
> From: Gleb Markov <markov.gi at npc-ksb.ru>
> 
> Depending on the value of chip_version, the correct decode set is selected.
> However, the subsequent matching with the t4 encoding type in the if-else
> block results in a reassignment, which leads to the loss of support for
> t6_decode as well as reinitializing of values t4_decode and t5_decode.
> 
> [...]

Here is the summary with links:
  - [net] cxgb4: Fix decode strings dump for T6 adapters
    https://git.kernel.org/netdev/net/c/5d6dc22d6268

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




From dmantipov at yandex.ru  Wed Jul  1 10:03:49 2026
From: dmantipov at yandex.ru (Dmitry Antipov)
Date: Wed,  1 Jul 2026 10:03:49 +0300
Subject: [lvc-project] [PATCH RESEND] media: dvb-core: fix dvb device
	instance leak
Message-ID: <20260701070349.2755931-1-dmantipov@yandex.ru>

After 'replace_fops()' trick in 'dvb_device_open()', reference count
of the corresponding 'struct dvb_device' instance can't be managed in
a regular way (e.g. by using 'dvd_device_put()' in '.release' callback
of 'dvb_device_ops'). Since there is a race condition between
'dvb_dmxdev_release()' and 'dvb_demux_release()' (there is no way to
guarantee that the former always sees non-zero 'exit' flag maybe set
by the latter), an extra check for non-zero 'minor' field of 'struct
dvb_device' is used to ensure that the device has passed through
'dvb_register_device()', has reference count more or equal to 2 and
call to 'dvb_device_put()' from 'dvb_demux_release()' never actually
frees the device (with 'dvb_free_device()' called via 'kref_put()').

Reported-by: syzbot+d37184d9d8cc34602616 at syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=d37184d9d8cc34602616
Signed-off-by: Dmitry Antipov <dmantipov at yandex.ru>
---
This is a resend of https://lore.kernel.org/all/20260216154152.2597331-1-dmantipov at yandex.ru/T.
Since 6.12.x looks affected, cc: stable as well.
---
 drivers/media/dvb-core/dmxdev.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/dvb-core/dmxdev.c b/drivers/media/dvb-core/dmxdev.c
index 3c8bc75e4d6c..c33490acba15 100644
--- a/drivers/media/dvb-core/dmxdev.c
+++ b/drivers/media/dvb-core/dmxdev.c
@@ -1256,6 +1256,9 @@ static int dvb_demux_release(struct inode *inode, struct file *file)
 	} else
 		mutex_unlock(&dmxdev->mutex);
 
+	if (dmxdev->dvbdev->minor)
+		dvb_device_put(dmxdev->dvbdev);
+
 	return ret;
 }
 
-- 
2.54.0



From pchelkin at ispras.ru  Wed Jul  1 12:23:36 2026
From: pchelkin at ispras.ru (Fedor Pchelkin)
Date: Wed, 1 Jul 2026 12:23:36 +0300
Subject: [lvc-project] [PATCH] drm/amd/display: Remove unused-but-set
 variable hubp from
In-Reply-To: <18b9c4-6a439a80-17-31eb7d8@70186827>
References: <20260629130907.124-1-markov.gi@npc-ksb.ru>
	<20260629184358-cc591a745094a281e7bda230-pchelkin@ispras>
	<181e79-6a437e80-15-74d25600@146698894>
	<20260630115818-d58228ad8eccdc356357e047-pchelkin@ispras>
	<18eb40-6a439800-7-44afdb80@56120018>
	<18b9c4-6a439a80-17-31eb7d8@70186827>
Message-ID: <20260701122147-b09d2750f04ecec89e40cd0a-pchelkin@ispras>

On Tue, 30. Jun 13:28, ?????? ???? ???????? wrote:
> > ????? ???????? ???? ????-?? ?????????? ?? ???????, ?? ???? ??????????? ?? ????.
> 
> ???????? ???? ????????? ???????? ( be1fb44389ca ), ??? ????????????? ?????? v6.12
> ? ???????? ??????????? ???????????? ?????? ?????????? ?? ?????? ????????????? ????????????.
> ?????? ????

???, ????

? ???????? ??? ???????????? ?????????.  ??????? ???????, ??? ???????
??????? ?????????? ????, ??? ??????? ?????????? ????? ? ??????
?????????? ????? ????.  ??? ????? v6.12, ? ??? ????? v6.12.1 ???
v6.12.88, ????????.

????? ?????? ?? ? ??????? ??????????
https://www.kernel.org/doc/html/latest/process/2.Process.html#the-big-picture


From mdmitrichenko at astralinux.ru  Wed Jul  1 19:01:21 2026
From: mdmitrichenko at astralinux.ru (Mikhail Dmitrichenko)
Date: Wed,  1 Jul 2026 19:01:21 +0300
Subject: [lvc-project] [PATCH 5.10/5.15] crypto: af_alg - Set merge to zero
	early in af_alg_sendmsg
Message-ID: <20260701160121.100720-1-mdmitrichenko@astralinux.ru>

From: Herbert Xu <herbert at gondor.apana.org.au>

commit 9574b2330dbd2b5459b74d3b5e9619d39299fc6f upstream.

If an error causes af_alg_sendmsg to abort, ctx->merge may contain
a garbage value from the previous loop.  This may then trigger a
crash on the next entry into af_alg_sendmsg when it attempts to do
a merge that can't be done.

Fix this by setting ctx->merge to zero near the start of the loop.

Fixes: 8ff590903d5 ("crypto: algif_skcipher - User-space interface for skcipher operations")
Reported-by: Muhammad Alifa Ramdhan <ramdhan at starlabs.sg>
Reported-by: Bing-Jhong Billy Jheng <billy at starlabs.sg>
Signed-off-by: Herbert Xu <herbert at gondor.apana.org.au>
Signed-off-by: Mikhail Dmitrichenko <mdmitrichenko at astralinux.ru>
---
Backport fix for CVE-2025-39931
 crypto/af_alg.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index b66a1681692d6..bbd47d04f89dc 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -892,6 +892,8 @@ int af_alg_sendmsg(struct socket *sock, struct msghdr *msg, size_t size,
 			continue;
 		}
 
+		ctx->merge = 0;
+
 		if (!af_alg_writable(sk)) {
 			err = af_alg_wait_for_wmem(sk, msg->msg_flags);
 			if (err)
-- 
2.47.3


From djwong at kernel.org  Wed Jul  1 19:33:10 2026
From: djwong at kernel.org (Darrick J. Wong)
Date: Wed, 1 Jul 2026 09:33:10 -0700
Subject: [lvc-project] [PATCH 6.6 0/4] fix kernel crash for xfs/235 test
In-Reply-To: <akRTtCIZZ0IZ0Omc@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
References: <20260612233110.2-1-sashal@kernel.org>
	<ajBQPNuKCruxhkXX@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
	<ajD3Gb-vQkGU0N6b@nidhogg.toxiclabs.cc>
	<ajFQPY2m2A6ltvTH@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
	<ajFabPtI8UGfkyix@nidhogg.toxiclabs.cc>
	<CACzhbgS59uCYhjX80__+nPjEx=N8mKUsYyFS1+aRDpMA-b-VXQ@mail.gmail.com>
	<CAOQ4uxgXqmP49FV3b_cKDD_703bRHz0fjm=k=FmNytsPpnKx3g@mail.gmail.com>
	<ajKSytW_sBFJaBTW@nidhogg.toxiclabs.cc>
	<20260625183421.GO6070@frogsfrogsfrogs>
	<akRTtCIZZ0IZ0Omc@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
Message-ID: <20260701163310.GB6517@frogsfrogsfrogs>

On Tue, Jun 30, 2026 at 07:39:32PM -0400, Hamza Mahfooz wrote:
> On Thu, Jun 25, 2026 at 11:34:21AM -0700, Darrick J. Wong wrote:
> > On Wed, Jun 17, 2026 at 02:31:01PM +0200, Carlos Maiolino wrote:
> > > On Wed, Jun 17, 2026 at 11:19:25AM +0200, Amir Goldstein wrote:
> > > > On Tue, Jun 16, 2026 at 7:33?PM Leah Rumancik <leah.rumancik at gmail.com> wrote:
> > > > >
> > > > > I have changed teams so I no longer work on kernel and I don't believe
> > > > > my xfs maintenance work was backfilled ;(
> > > > >
> > > > > On Tue, Jun 16, 2026 at 7:19?AM Carlos Maiolino <cem at kernel.org> wrote:
> > > > > >
> > > > > > On Tue, Jun 16, 2026 at 09:31:41AM -0400, Hamza Mahfooz wrote:
> > > > > > > Cc: linux-xfs at vger.kernel.org
> > > > > > >
> > > > > > > On Tue, Jun 16, 2026 at 09:13:45AM +0200, Carlos Maiolino wrote:
> > > > > > > > On Mon, Jun 15, 2026 at 03:19:24PM -0400, Hamza Mahfooz wrote:
> > > > > > > > > Cc: Carlos Maiolino <cem at kernel.org>
> > > > > > > >
> > > > > > > > FWIW I don't maintain the stable trees I really don't have time for
> > > > > > > > that. Darrick/Leah have been doing a best effort case for that, but
> > > > > > > > again, this is mostly a best effort so we shouldn't expect them to be
> > > > > > > > looking/picking up every single possible patch suggested for stable.
> > > > > > > >
> > > > > > >
> > > > > > > Now that you mention it, the xfs-stable mailing list seems to be pretty
> > > > > > > much dead (i.e. the last time fixes from it were merged into stable was
> > > > > > > almost a year ago). I guess no one is really working on it anymore?
> > > > > >
> > > > > > IIRC Darrick started it, I personally never worked on it, but I didn't
> > > > > > follow the evolution there.
> > > > 
> > > > I think at this point we can officially declare xfs in stable <= 6.6
> > > > unmaintained
> > > > maybe need to send patches to LTS MAINTAINERS.
> > > > 
> > > > The best chance in this case to apply the requested fix to 6.6.y is that the
> > > > author (Darrick) approves it.
> > > 
> > > Unfortunately this might be true. But let's wait for Darrick's input
> > > please. He's on vacations this week so will be unfair to make any
> > > decisions in this matter without his input.
> > > Also he has been still poking people to tag patches with LTS versions
> > > so even though he might not me dealing with the xfs-stable, he might still
> > > be driving work on LTS trees.
> > 
> > I've really only been doing QA work on 6.12/6.18 LTS.  Ted Tso might
> > still be doing the older ones.  Catherine left Oracle last year.
> 
> Any idea on potential paths forward for getting this series in
> particular into 6.6.y?

Run fstests, and if there are no new regressions, ask sasha/greg to
queue it.

--D


From sashal at kernel.org  Thu Jul  2 03:38:27 2026
From: sashal at kernel.org (Sasha Levin)
Date: Wed,  1 Jul 2026 20:38:27 -0400
Subject: [lvc-project] [PATCH 5.10/5.15] crypto: af_alg - Set merge to
	zero early in af_alg_sendmsg
In-Reply-To: <20260701160121.100720-1-mdmitrichenko@astralinux.ru>
References: <20260701160121.100720-1-mdmitrichenko@astralinux.ru>
Message-ID: <stable-reply-af-alg-merge-20260701193800@kernel.org>

> If an error causes af_alg_sendmsg to abort, ctx->merge may contain
> a garbage value from the previous loop.  This may then trigger a
> crash on the next entry into af_alg_sendmsg when it attempts to do
> a merge that can't be done.
>
> Fix this by setting ctx->merge to zero near the start of the loop.

Queued for 5.15.y and 5.10.y, thanks.

-- 
Thanks,
Sasha


From sashal at kernel.org  Thu Jul  2 03:38:31 2026
From: sashal at kernel.org (Sasha Levin)
Date: Wed,  1 Jul 2026 20:38:31 -0400
Subject: [lvc-project] [PATCH 5.10] net: cpsw_new: Fix potential
	unregister of netdev that has not been registered yet
In-Reply-To: <20260630200717.1994713-1-etereshkina@astralinux.ru>
References: <20260630200717.1994713-1-etereshkina@astralinux.ru>
Message-ID: <stable-reply-cpsw-new-510-20260701193800@kernel.org>

> If an error occurs during register_netdev() for the first MAC in
> cpsw_register_ports(), even though cpsw->slaves[0].ndev is set to NULL,
> cpsw->slaves[1].ndev would remain unchanged. This could later cause
> cpsw_unregister_ports() to attempt unregistering the second MAC.

Queued for 5.10.y, thanks.

-- 
Thanks,
Sasha


From mdmitrichenko at astralinux.ru  Thu Jul  2 13:20:17 2026
From: mdmitrichenko at astralinux.ru (Mikhail Dmitrichenko)
Date: Thu,  2 Jul 2026 13:20:17 +0300
Subject: [lvc-project] [PATCH 5.10] usb: cdns3: gadget: fix NULL pointer
	dereference in ep_queue
Message-ID: <20260702102018.48182-1-mdmitrichenko@astralinux.ru>

From: Yongchao Wu <yongchao.wu at autochips.com>

commit 7f6f127b9bc34bed35f56faf7ecb1561d6b39000 upstream.

When the gadget endpoint is disabled or not yet configured, the ep->desc
pointer can be NULL. This leads to a NULL pointer dereference when
__cdns3_gadget_ep_queue() is called, causing a kernel crash.

Add a check to return -ESHUTDOWN if ep->desc is NULL, which is the
standard return code for unconfigured endpoints.

This prevents potential crashes when ep_queue is called on endpoints
that are not ready.

Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver")
Cc: stable <stable at kernel.org>
Signed-off-by: Yongchao Wu <yongchao.wu at autochips.com>
Acked-by: Peter Chen <peter.chen at kernel.org>
Link: https://patch.msgid.link/20260331000407.613298-1-yongchao.wu at autochips.com
Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Signed-off-by: Mikhail Dmitrichenko <mdmitrichenko at astralinux.ru>
---
Backport fix for CVE-2026-31755
 drivers/usb/cdns3/gadget.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c
index 61388e2089f5f..a64302acdfe6d 100644
--- a/drivers/usb/cdns3/gadget.c
+++ b/drivers/usb/cdns3/gadget.c
@@ -2587,6 +2587,9 @@ static int __cdns3_gadget_ep_queue(struct usb_ep *ep,
 	struct cdns3_request *priv_req;
 	int ret = 0;
 
+	if (!ep->desc)
+		return -ESHUTDOWN;
+
 	request->actual = 0;
 	request->status = -EINPROGRESS;
 	priv_req = to_cdns3_request(request);
-- 
2.47.3


From gregkh at linuxfoundation.org  Thu Jul  2 17:33:34 2026
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Thu, 2 Jul 2026 16:33:34 +0200
Subject: [lvc-project] [PATCH v3 5.10/5.15 0/2] Backport RDMA/rxe task
 and timer cleanup fixes
In-Reply-To: <20260605171449.1760-1-vlad102nikolaev@gmail.com>
References: <20260605171449.1760-1-vlad102nikolaev@gmail.com>
Message-ID: <2026070218-playhouse-quicksand-7f7d@gregkh>

On Fri, Jun 05, 2026 at 08:14:41PM +0300, Vladislav Nikolaev wrote:
> This series backports two upstream RDMA/rxe fixes to linux-5.10.y and
> linux-5.15.y.
> 
> The first patch fixes cleanup of RXE tasks that may not have been
> initialized on the rxe_create_qp() error path. The second patch fixes
> the same class of lockdep issue for RC timers by checking that both
> timers were initialized before deleting them.
> 
> In linux-5.10.y and linux-5.15.y the relevant task and timer cleanup
> still lives in rxe_qp_destroy(), so the 1c7eec4d5f3b backport applies
> the timer guard there and keeps del_timer_sync().
> 
> Zhu Yanjun (2):
>   RDMA/rxe: Fix the error "trying to register non-static key in
>     rxe_cleanup_task"
>   RDMA/rxe: Fix "trying to register non-static key in rxe_qp_do_cleanup"
>     bug
> 
>  drivers/infiniband/sw/rxe/rxe_qp.c | 18 ++++++++++++++----
>  1 file changed, 14 insertions(+), 4 deletions(-)
> 
> -- 
> 2.39.5

Would need this for newer kernels first.  Please submit that series
first, then resend these.

thanks,

greg k-h


From pkshih at realtek.com  Fri Jul  3 06:51:47 2026
From: pkshih at realtek.com (Ping-Ke Shih)
Date: Fri, 3 Jul 2026 11:51:47 +0800
Subject: [lvc-project] [PATCH rtw-next v3] wifi: rtw89: check return
	values in rtw89_ops_start_ap()
In-Reply-To: <20260629094452.8709-1-d.morgun@ispras.ru>
References: <20260629094452.8709-1-d.morgun@ispras.ru>
Message-ID: <096ddbd7-652d-4355-8ac4-a91b331c6628@RTKEXHMBS03.realtek.com.tw>

Dmitry Morgun <d.morgun at ispras.ru> wrote:

> Several functions called in rtw89_ops_start_ap() may fail to allocate
> skb or fail to send H2C command to firmware, returning -ENOMEM or an
> error code. Their return values are ignored, so subsequent commands
> are executed with incorrect state.
> 
> Check the return values and propagate errors.
> 
> Found by Linux Verification Center (linuxtesting.org) with SVACE.
> 
> Fixes: a52e4f2ce0f5 ("wifi: rtw89: implement ieee80211_ops::start_ap and stop_ap")
> Signed-off-by: Dmitry Morgun <d.morgun at ispras.ru>
> Acked-by: Ping-Ke Shih <pkshih at realtek.com>

1 patch(es) applied to rtw-next branch of rtw.git, thanks.

a8cddb62c573 wifi: rtw89: check return values in rtw89_ops_start_ap()

---
https://github.com/pkshih/rtw.git



From sashal at kernel.org  Fri Jul  3 07:06:56 2026
From: sashal at kernel.org (Sasha Levin)
Date: Fri,  3 Jul 2026 00:06:56 -0400
Subject: [lvc-project] [PATCH 6.6 0/4] fix kernel crash for xfs/235 test
In-Reply-To: <20260701163310.GB6517@frogsfrogsfrogs>
References: <20260701163310.GB6517@frogsfrogsfrogs>
Message-ID: <stable-reply-xfs-235-fstests-66y-20260702213502@kernel.org>

On Wed, Jul 01, 2026 at 09:33:10AM -0700, Darrick J. Wong wrote:
> On Tue, Jun 30, 2026 at 07:39:32PM -0400, Hamza Mahfooz wrote:
> > Any idea on potential paths forward for getting this series in
> > particular into 6.6.y?
>
> Run fstests, and if there are no new regressions, ask sasha/greg to
> queue it.

Thanks Darrick.

Hamza, could you apply the four patches on top of the current 6.6.y
tree, run fstests, and report the results here? The series was written
against 6.6.84-rc2 about 15 months ago, so a fresh run against today's
6.6.y would both satisfy Darrick's condition and confirm the series
still behaves on the current tree.

Once a clean fstests run is reported I'll queue the series up for 6.6.

-- 
Thanks,
Sasha


From sashal at kernel.org  Fri Jul  3 07:07:00 2026
From: sashal at kernel.org (Sasha Levin)
Date: Fri,  3 Jul 2026 00:07:00 -0400
Subject: [lvc-project] [PATCH 5.10] usb: cdns3: gadget: fix NULL pointer
	dereference in ep_queue
In-Reply-To: <20260702102018.48182-1-mdmitrichenko@astralinux.ru>
References: <20260702102018.48182-1-mdmitrichenko@astralinux.ru>
Message-ID: <stable-reply-usb-cdns3-ep-queue-510-20260702192533@kernel.org>

On Thu, Jul 02, 2026 at 01:20:17PM +0300, Mikhail Dmitrichenko wrote:
> From: Yongchao Wu <yongchao.wu at autochips.com>
>
> commit 7f6f127b9bc34bed35f56faf7ecb1561d6b39000 upstream.
>
> When the gadget endpoint is disabled or not yet configured, the ep->desc
> pointer can be NULL. This leads to a NULL pointer dereference when
> __cdns3_gadget_ep_queue() is called, causing a kernel crash.

Queued up for 5.10.y, thanks!

-- 
Thanks,
Sasha


From baochen.qiang at oss.qualcomm.com  Fri Jul  3 09:45:20 2026
From: baochen.qiang at oss.qualcomm.com (Baochen Qiang)
Date: Fri, 3 Jul 2026 14:45:20 +0800
Subject: [lvc-project] [PATCH] wifi: ath11k: fix potential buffer
 underflow in ath11k_hal_rx_msdu_list_get()
In-Reply-To: <20260530114252.42615-1-d.morgun@ispras.ru>
References: <20260530114252.42615-1-d.morgun@ispras.ru>
Message-ID: <f304041f-c570-4db3-b27b-86d85dd41ec5@oss.qualcomm.com>



On 5/30/2026 7:42 PM, Dmitry Morgun wrote:
> When the first entry in msdu_details has a zero buffer address,
> the code accesses msdu_details[i - 1] with i == 0, causing a
> buffer underflow.
> 
> Fix similarly to ath12k_wifi7_hal_rx_msdu_list_get() by adding
> a separate check for i == 0 before the main condition to prevent
> the out-of-bounds access.
> 
> Found by Linux Verification Center (linuxtesting.org) with SVACE.
> 
> Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
> Signed-off-by: Dmitry Morgun <d.morgun at ispras.ru>

Reviewed-by: Baochen Qiang <baochen.qiang at oss.qualcomm.com>


From rameshkumar.sundaram at oss.qualcomm.com  Fri Jul  3 13:36:17 2026
From: rameshkumar.sundaram at oss.qualcomm.com (Rameshkumar Sundaram)
Date: Fri, 3 Jul 2026 16:06:17 +0530
Subject: [lvc-project] [PATCH] wifi: ath11k: fix potential buffer
 underflow in ath11k_hal_rx_msdu_list_get()
In-Reply-To: <20260530114252.42615-1-d.morgun@ispras.ru>
References: <20260530114252.42615-1-d.morgun@ispras.ru>
Message-ID: <20d52df0-a33c-48da-8f62-9adb7c77eea0@oss.qualcomm.com>

On 5/30/2026 5:12 PM, Dmitry Morgun wrote:
> When the first entry in msdu_details has a zero buffer address,
> the code accesses msdu_details[i - 1] with i == 0, causing a
> buffer underflow.
> 
> Fix similarly to ath12k_wifi7_hal_rx_msdu_list_get() by adding
> a separate check for i == 0 before the main condition to prevent
> the out-of-bounds access.
> 
> Found by Linux Verification Center (linuxtesting.org) with SVACE.
> 
> Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
> Signed-off-by: Dmitry Morgun <d.morgun at ispras.ru>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram at oss.qualcomm.com>


From mdmitrichenko at astralinux.ru  Fri Jul  3 14:48:13 2026
From: mdmitrichenko at astralinux.ru (Mikhail Dmitrichenko)
Date: Fri,  3 Jul 2026 14:48:13 +0300
Subject: [lvc-project] [PATCH 6.12] bcachefs: avoid truncating fiemap extent
	length
Message-ID: <20260703114813.113406-1-mdmitrichenko@astralinux.ru>

No upstream commit exists for this patch.

bkey sizes are stored in sectors as u32, while fiemap reports byte
lengths as u64. Shifting k.k->size before widening performs the
conversion in 32 bits, so an extent of 4 GiB or larger can wrap before
it is passed to fiemap_fill_next_extent().

Compute the byte length after casting the sector count to u64 and reuse
it for all bch2_fill_extent() cases.

The same issue was fixed in bcachefs-tools, but there is no Linux
upstream commit to backport to 6.12. The affected 6.12 implementation lives
in fs/bcachefs/fs.c, while the bcachefs-tools fix touches
fs/bcachefs/vfs/fiemap.c.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Link: https://lore.kernel.org/linux-bcachefs/20260610105547.129545-1-mdmitrichenko at astralinux.ru/
Link: https://evilpiepirate.org/git/bcachefs-tools.git/commit/?id=6d9a895ed00d4b3868312df93253d2a817b0c6a3
Signed-off-by: Mikhail Dmitrichenko <mdmitrichenko at astralinux.ru>
---
 fs/bcachefs/fs.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/fs/bcachefs/fs.c b/fs/bcachefs/fs.c
index a41d0d8a2f7b..0dc2466de3f9 100644
--- a/fs/bcachefs/fs.c
+++ b/fs/bcachefs/fs.c
@@ -1184,6 +1184,8 @@ static int bch2_fill_extent(struct bch_fs *c,
 			    struct fiemap_extent_info *info,
 			    struct bkey_s_c k, unsigned flags)
 {
+	u64 len = (u64)k.k->size << 9;
+
 	if (bkey_extent_is_direct_data(k.k)) {
 		struct bkey_ptrs_c ptrs = bch2_bkey_ptrs_c(k);
 		const union bch_extent_entry *entry;
@@ -1212,7 +1214,7 @@ static int bch2_fill_extent(struct bch_fs *c,
 			ret = fiemap_fill_next_extent(info,
 						bkey_start_offset(k.k) << 9,
 						offset << 9,
-						k.k->size << 9, flags|flags2);
+						len, flags | flags2);
 			if (ret)
 				return ret;
 		}
@@ -1221,13 +1223,13 @@ static int bch2_fill_extent(struct bch_fs *c,
 	} else if (bkey_extent_is_inline_data(k.k)) {
 		return fiemap_fill_next_extent(info,
 					       bkey_start_offset(k.k) << 9,
-					       0, k.k->size << 9,
+					       0, len,
 					       flags|
 					       FIEMAP_EXTENT_DATA_INLINE);
 	} else if (k.k->type == KEY_TYPE_reservation) {
 		return fiemap_fill_next_extent(info,
 					       bkey_start_offset(k.k) << 9,
-					       0, k.k->size << 9,
+					       0, len,
 					       flags|
 					       FIEMAP_EXTENT_DELALLOC|
 					       FIEMAP_EXTENT_UNWRITTEN);
-- 
2.43.0


From heikki.krogerus at linux.intel.com  Fri Jul  3 15:04:48 2026
From: heikki.krogerus at linux.intel.com (Heikki Krogerus)
Date: Fri, 3 Jul 2026 15:04:48 +0300
Subject: [lvc-project] [PATCH] usb: typec: qcom-pmic-typec: avoid uninit
 values in dev_dbg() error paths
In-Reply-To: <20260630120114.185169-1-kovalev@altlinux.org>
References: <20260630120114.185169-1-kovalev@altlinux.org>
Message-ID: <akelYJEXIZmP5Spx@kuha>

On Tue, Jun 30, 2026 at 03:01:14PM +0300, Vasiliy Kovalev wrote:
> Several functions take a 'goto done' shortcut on regmap_read() (or
> switch default) failure before assigning locals that the trailing
> dev_dbg() then formats.
> 
> Initialize the affected locals at declaration.
> 
> Found by Linux Verification Center (linuxtesting.org) with Svace static
> analysis tool.
> 
> Fixes: a4422ff22142 ("usb: typec: qcom: Add Qualcomm PMIC Type-C driver")
> Cc: stable at vger.kernel.org
> Signed-off-by: Vasiliy Kovalev <kovalev at altlinux.org>

Reviewed-by: Heikki Krogerus <heikki.krogerus at linux.intel.com>

> ---
>  drivers/usb/typec/tcpm/qcom/qcom_pmic_typec_port.c | 9 +++++----
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/typec/tcpm/qcom/qcom_pmic_typec_port.c b/drivers/usb/typec/tcpm/qcom/qcom_pmic_typec_port.c
> index bf985efe1cd6..c8379cdcb6da 100644
> --- a/drivers/usb/typec/tcpm/qcom/qcom_pmic_typec_port.c
> +++ b/drivers/usb/typec/tcpm/qcom/qcom_pmic_typec_port.c
> @@ -366,7 +366,7 @@ static int qcom_pmic_typec_port_get_cc(struct tcpc_dev *tcpc,
>  	struct pmic_typec_port *pmic_typec_port = tcpm->pmic_typec_port;
>  	struct device *dev = pmic_typec_port->dev;
>  	unsigned int misc, val;
> -	bool attached;
> +	bool attached = false;
>  	int ret = 0;
>  
>  	ret = regmap_read(pmic_typec_port->regmap,
> @@ -461,8 +461,8 @@ static int qcom_pmic_typec_port_set_cc(struct tcpc_dev *tcpc,
>  	struct pmic_typec *tcpm = tcpc_to_tcpm(tcpc);
>  	struct pmic_typec_port *pmic_typec_port = tcpm->pmic_typec_port;
>  	struct device *dev = pmic_typec_port->dev;
> -	unsigned int mode, currsrc;
> -	unsigned int misc;
> +	unsigned int mode = 0, currsrc = 0;
> +	unsigned int misc = 0;
>  	unsigned long flags;
>  	int ret;
>  
> @@ -535,7 +535,8 @@ static int qcom_pmic_typec_port_set_vconn(struct tcpc_dev *tcpc, bool on)
>  	struct pmic_typec *tcpm = tcpc_to_tcpm(tcpc);
>  	struct pmic_typec_port *pmic_typec_port = tcpm->pmic_typec_port;
>  	struct device *dev = pmic_typec_port->dev;
> -	unsigned int orientation, misc, mask, value;
> +	unsigned int orientation = 0, misc = 0, value = 0;
> +	unsigned int mask;
>  	unsigned long flags;
>  	int ret;
>  
> -- 
> 2.50.1

-- 
heikki


From d.zubov at tssltd.ru  Fri Jul  3 15:08:38 2026
From: d.zubov at tssltd.ru (Denis Zubov)
Date: Fri,  3 Jul 2026 15:08:38 +0300
Subject: [lvc-project] [PATCH 6.1/6.12] netfilter: nft_socket: remove
	WARN_ON_ONCE with huge level value
Message-ID: <20260703120850.1816083-1-d.zubov@tssltd.ru>

From: Pablo Neira Ayuso <pablo at netfilter.org>

commit 1dee968d22eaeb3eede70df513ab3f8dd1712e3e upstream.

syzbot managed to reach this WARN_ON_ONCE by passing a huge level
value, remove it.

Reported-by: syzbot+a225fea35d7baf8dbdc3 at syzkaller.appspotmail.com
Signed-off-by: Pablo Neira Ayuso <pablo at netfilter.org>

Fixes: 7f3287db6543 ("netfilter: nft_socket: make cgroupsv2 matching work with namespaces")
Signed-off-by: Denis Zubov <d.zubov at tssltd.ru>
---
 net/netfilter/nft_socket.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/netfilter/nft_socket.c b/net/netfilter/nft_socket.c
index 2d33674e9e5e..03092c61eda1 100644
--- a/net/netfilter/nft_socket.c
+++ b/net/netfilter/nft_socket.c
@@ -217,7 +217,7 @@ static int nft_socket_init(const struct nft_ctx *ctx,
 
 		level += err;
 		/* Implies a giant cgroup tree */
-		if (WARN_ON_ONCE(level > 255))
+		if (level > 255)
 			return -EOPNOTSUPP;
 
 		priv->level = level;
-- 
2.53.0



From evg28bur at yandex.ru  Fri Jul  3 16:24:12 2026
From: evg28bur at yandex.ru (Evgenii Burenchev)
Date: Fri,  3 Jul 2026 16:24:12 +0300
Subject: [lvc-project] [PATCH v2] drm/radeon/rs780: avoid potential
	divide-by-zero in refresh rate calculation
Message-ID: <20260703132413.22873-1-evg28bur@yandex.ru>

The refresh rate used in rs780 DPM display configuration is derived from
drm_mode_vrefresh(crtc->mode). While connector modes are validated through
drm_mode_validate_driver(), crtc->mode represents runtime display state
and may originate from restore paths or transitional modeset states.

In such cases, drm_mode_vrefresh() may return 0, which is currently used
as a divisor in rs780_program_at(), leading to a potential divide-by-zero
condition.

This issue was found by Linux Verification Center (linuxtesting.org) with SVACE.

Fix this by enforcing a safe fallback refresh rate when the computed value
is zero.

This change ensures robustness of rs780 display power management during
resume and display reconfiguration paths.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Fixes: 9d67006e6ebc ("drm/radeon: rs780 DPM display configuration handling")
Signed-off-by: Evgenii Burenchev <evg28bur at yandex.ru>
---
Changes in v2:
- Add Fixes tag referencing related rs780 DPM display configuration commit
- Clarify that issue is related to runtime crtc->mode state rather than
  connector mode validation path
- Reword commit message to align with DRM state model terminology
---
 drivers/gpu/drm/radeon/rs780_dpm.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/rs780_dpm.c b/drivers/gpu/drm/radeon/rs780_dpm.c
index 64bb4cafb8b5..ad7161972e37 100644
--- a/drivers/gpu/drm/radeon/rs780_dpm.c
+++ b/drivers/gpu/drm/radeon/rs780_dpm.c
@@ -63,8 +63,11 @@ static void rs780_get_pm_mode_parameters(struct radeon_device *rdev)
 		if (crtc && crtc->enabled) {
 			radeon_crtc = to_radeon_crtc(crtc);
 			pi->crtc_id = radeon_crtc->crtc_id;
-			if (crtc->mode.htotal && crtc->mode.vtotal)
+			if (crtc->mode.htotal && crtc->mode.vtotal) {
 				pi->refresh_rate = drm_mode_vrefresh(&crtc->mode);
+				if (!pi->refresh_rate)
+					pi->refresh_rate = 60;
+			}
 			break;
 		}
 	}
-- 
2.43.0



From amir73il at gmail.com  Fri Jul  3 16:46:50 2026
From: amir73il at gmail.com (Amir Goldstein)
Date: Fri, 3 Jul 2026 15:46:50 +0200
Subject: [lvc-project] [PATCH 6.6 0/4] fix kernel crash for xfs/235 test
In-Reply-To: <stable-reply-xfs-235-fstests-66y-20260702213502@kernel.org>
References: <20260701163310.GB6517@frogsfrogsfrogs>
	<stable-reply-xfs-235-fstests-66y-20260702213502@kernel.org>
Message-ID: <CAOQ4uxg8AsBL=hrHY8H+U3gPM8aHg1C2-WDXnCAe3CFCOsBQ9g@mail.gmail.com>

On Fri, Jul 3, 2026 at 6:07?AM Sasha Levin <sashal at kernel.org> wrote:
>
> On Wed, Jul 01, 2026 at 09:33:10AM -0700, Darrick J. Wong wrote:
> > On Tue, Jun 30, 2026 at 07:39:32PM -0400, Hamza Mahfooz wrote:
> > > Any idea on potential paths forward for getting this series in
> > > particular into 6.6.y?
> >
> > Run fstests, and if there are no new regressions, ask sasha/greg to
> > queue it.
>
> Thanks Darrick.
>
> Hamza, could you apply the four patches on top of the current 6.6.y
> tree, run fstests, and report the results here? The series was written
> against 6.6.84-rc2 about 15 months ago, so a fresh run against today's
> 6.6.y would both satisfy Darrick's condition and confirm the series
> still behaves on the current tree.
>
> Once a clean fstests run is reported I'll queue the series up for 6.6.

To be clear, it is not likely to expect a clean run.
What we want to expect is no regression from 6.6.y to patches 6.6.y.
A run of test group auto (-g auto) is the minimal sanity requirement.

TBH, this series is quite subtle, so this bare minimum sanity is not much,
but it's enough to make sure no silly backports mistakes were made and
it's probably better off than leaving the known bug in LTS.

Thanks,
Amir.


From adiupina at astralinux.ru  Fri Jul  3 15:13:38 2026
From: adiupina at astralinux.ru (Alexandra Diupina)
Date: Fri,  3 Jul 2026 15:13:38 +0300
Subject: [lvc-project] [PATCH 5.10/5.15] clk: imx: Add check for kcalloc
Message-ID: <20260703121338.25747-1-adiupina@astralinux.ru>

From: Jiasheng Jiang <jiasheng at iscas.ac.cn>

commit ed713e2bc093239ccd380c2ce8ae9e4162f5c037 upstream.

As the potential failure of the kcalloc(),
it should be better to check it in order to
avoid the dereference of the NULL pointer.

Fixes: 379c9a24cc23 ("clk: imx: Fix reparenting of UARTs not associated with stdout")
Signed-off-by: Jiasheng Jiang <jiasheng at iscas.ac.cn>
Reviewed-by: Abel Vesa <abel.vesa at nxp.com>
Link: https://lore.kernel.org/r/20220310080257.1988412-1-jiasheng at iscas.ac.cn
Signed-off-by: Abel Vesa <abel.vesa at nxp.com>
Signed-off-by: Alexandra Diupina <adiupina at astralinux.ru>
---
Backport fix for CVE-2022-3114
 drivers/clk/imx/clk.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clk/imx/clk.c b/drivers/clk/imx/clk.c
index d4cf0c7045ab2..be0493e5b494e 100644
--- a/drivers/clk/imx/clk.c
+++ b/drivers/clk/imx/clk.c
@@ -173,6 +173,8 @@ void imx_register_uart_clocks(unsigned int clk_count)
 		int i;
 
 		imx_uart_clocks = kcalloc(clk_count, sizeof(struct clk *), GFP_KERNEL);
+		if (!imx_uart_clocks)
+			return;
 
 		if (!of_stdout)
 			return;
-- 
2.47.3


From pchelkin at ispras.ru  Fri Jul  3 17:56:25 2026
From: pchelkin at ispras.ru (Fedor Pchelkin)
Date: Fri, 3 Jul 2026 17:56:25 +0300
Subject: [lvc-project] [PATCH 6.1/6.12] netfilter: nft_socket: remove
 WARN_ON_ONCE with huge level value
In-Reply-To: <20260703120850.1816083-1-d.zubov@tssltd.ru>
References: <20260703120850.1816083-1-d.zubov@tssltd.ru>
Message-ID: <akfNd-uh7FNH9izd@fedora>

On Fri, 03. Jul 15:08, Denis Zubov wrote:
> From: Pablo Neira Ayuso <pablo at netfilter.org>
> 
> commit 1dee968d22eaeb3eede70df513ab3f8dd1712e3e upstream.
> 
> syzbot managed to reach this WARN_ON_ONCE by passing a huge level
> value, remove it.
> 
> Reported-by: syzbot+a225fea35d7baf8dbdc3 at syzkaller.appspotmail.com
> Signed-off-by: Pablo Neira Ayuso <pablo at netfilter.org>
> 

??? ??????? ?????? - ?????? ?????? ????? ???? ?? ??????.  ????????? ???
??????????.

> Fixes: 7f3287db6543 ("netfilter: nft_socket: make cgroupsv2 matching work with namespaces")
> Signed-off-by: Denis Zubov <d.zubov at tssltd.ru>


From d.morgun at ispras.ru  Fri Jul  3 18:53:50 2026
From: d.morgun at ispras.ru (d.morgun at ispras.ru)
Date: Fri, 03 Jul 2026 18:53:50 +0300
Subject: [lvc-project] [PATCH rtw-next v3] wifi: rtw89: check return
 values in rtw89_ops_start_ap()
In-Reply-To: <d58f1e279a0944529669a1e49d96cac6@realtek.com>
References: <20260629094452.8709-1-d.morgun@ispras.ru>
	<d58f1e279a0944529669a1e49d96cac6@realtek.com>
Message-ID: <6754361d578f7418fe85e1aec8a6b618@ispras.ru>

Hi Ping-Ke,

Sorry for the confusion. The v3 suffix was added by mistake during local 
iterations of the patch.

There is no public v1/v2 in the mailing list history. This is the first 
version submitted upstream.

I will resend as v1 if needed.

Best regards,
Dmitry

Ping-Ke Shih ?????(?) 2026-06-30 03:27:
> Dmitry Morgun <d.morgun at ispras.ru> wrote:
>> Subject: [PATCH rtw-next v3] wifi: rtw89: check return values in 
>> rtw89_ops_start_ap()
> 
> Patch is fine. But I don't remember why this is v3. Can you point out
> v1 and v2?
> 
>> Several functions called in rtw89_ops_start_ap() may fail to allocate
>> skb or fail to send H2C command to firmware, returning -ENOMEM or an
>> error code. Their return values are ignored, so subsequent commands
>> are executed with incorrect state.
>> 
>> Check the return values and propagate errors.
>> 
>> Found by Linux Verification Center (linuxtesting.org) with SVACE.
>> 
>> Fixes: a52e4f2ce0f5 ("wifi: rtw89: implement ieee80211_ops::start_ap 
>> and stop_ap")
>> Signed-off-by: Dmitry Morgun <d.morgun at ispras.ru>
> 
> Acked-by: Ping-Ke Shih <pkshih at realtek.com>


From sashal at kernel.org  Sat Jul  4 05:05:22 2026
From: sashal at kernel.org (Sasha Levin)
Date: Fri,  3 Jul 2026 22:05:22 -0400
Subject: [lvc-project] [PATCH 6.12] bcachefs: avoid truncating fiemap
	extent length
In-Reply-To: <20260703114813.113406-1-mdmitrichenko@astralinux.ru>
References: <20260703114813.113406-1-mdmitrichenko@astralinux.ru>
Message-ID: <2026070315-stable-reply-0028@kernel.org>

On Thu, Jul 03, 2026 at 02:48:13PM +0300, Mikhail Dmitrichenko wrote:
> No upstream commit exists for this patch.
>
> bkey sizes are stored in sectors as u32, while fiemap reports byte
> lengths as u64. Shifting k.k->size before widening performs the
> conversion in 32 bits, so an extent of 4 GiB or larger can wrap before
> it is passed to fiemap_fill_next_extent().

Thanks for the patch, happy to take it if we can get an ack from the bcachefs
maintainers.

-- 
Thanks,
Sasha


From kent.overstreet at linux.dev  Sat Jul  4 17:49:11 2026
From: kent.overstreet at linux.dev (Kent Overstreet)
Date: Sat, 4 Jul 2026 09:49:11 -0500
Subject: [lvc-project] [PATCH 6.12] bcachefs: avoid truncating fiemap
	extent length
In-Reply-To: <2026070315-stable-reply-0028@kernel.org>
References: <20260703114813.113406-1-mdmitrichenko@astralinux.ru>
	<2026070315-stable-reply-0028@kernel.org>
Message-ID: <akkdYigsmB8tJf6T@shelob>

On Fri, Jul 03, 2026 at 10:05:22PM -0400, Sasha Levin wrote:
> On Thu, Jul 03, 2026 at 02:48:13PM +0300, Mikhail Dmitrichenko wrote:
> > No upstream commit exists for this patch.
> >
> > bkey sizes are stored in sectors as u32, while fiemap reports byte
> > lengths as u64. Shifting k.k->size before widening performs the
> > conversion in 32 bits, so an extent of 4 GiB or larger can wrap before
> > it is passed to fiemap_fill_next_extent().
> 
> Thanks for the patch, happy to take it if we can get an ack from the bcachefs
> maintainers.
> 
> -- 
> Thanks,
> Sasha

Ack


From sashal at kernel.org  Sat Jul  4 05:05:23 2026
From: sashal at kernel.org (Sasha Levin)
Date: Fri,  3 Jul 2026 22:05:23 -0400
Subject: [lvc-project] [PATCH 5.10/5.15] clk: imx: Add check for kcalloc
In-Reply-To: <20260703121338.25747-1-adiupina@astralinux.ru>
References: <20260703121338.25747-1-adiupina@astralinux.ru>
Message-ID: <2026070315-stable-reply-0029@kernel.org>

On Thu, Jul 03, 2026 at 03:13:38PM +0300, Alexandra Diupina wrote:
> From: Jiasheng Jiang <jiasheng at iscas.ac.cn>
>
> commit ed713e2bc093239ccd380c2ce8ae9e4162f5c037 upstream.
>
> As the potential failure of the kcalloc(),
> it should be better to check it in order to
> avoid the dereference of the NULL pointer.

Queued for 5.15.y and 5.10.y, thanks!

-- 
Thanks,
Sasha


