* Re: Bug#1135514: [6.1.y regresssion] 9a95ec9144ee ("xfrm: fix ip_rt_bug race in icmp_route_lookup reverse path") causes log spam on ping to unreachable host
From: Jiayuan Chen @ 2026-05-06 9:47 UTC (permalink / raw)
To: Jiayuan Chen, 1135514, Paolo Abeni, Sasha Levin, regressions,
stable, podorski, Brad Barnett, David S. Miller, David Ahern,
Eric Dumazet, Jakub Kicinski, Simon Horman
In-Reply-To: <afsMUZa99G_gsve1@eldamar.lan>
On Wed, May 6, 2026 at 5:39 PM Salvatore Bonaccorso <carnil@debian.org> wrote:
>
> Hi Jiayuan,
>
> On Wed, May 06, 2026 at 09:04:24AM +0800, Jiayuan Chen wrote:
> > I think it because we failed to backport this patch before:
> > https://lore.kernel.org/stable/20250207161555-b1a8749027831a1a@stable.kernel.org/T/#m0c880c1f04f7211aea9b7f6b4de0b64aa1726417
>
> Which won't apply cleanly, I assume this was the reason it got not
> backported to 6.1.y. Do you have a backport of that, or should the
> original commit introducing the issue be reverted from 6.1.y?
>
> Regards,
> Salvtore
I tried to backport this patch to stable. Hope these patches apply successfully.
https://lore.kernel.org/stable/20260506012057.285743-1-jiayuan.chen@linux.dev/T/#u
https://lore.kernel.org/stable/20260506012115.286204-1-jiayuan.chen@linux.dev/T/#u
^ permalink raw reply
* Re: [PATCH v6 1/1] block/blk-mq: use atomic_t for quiesce_depth to avoid lock contention on RT
From: Bart Van Assche @ 2026-05-06 9:43 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Ionut Nechita (Wind River), axboe, linux-block, clrkwllms,
rostedt, ming.lei, muchun.song, mkhalfella, chris.friesen,
linux-kernel, linux-rt-devel, linux-rt-users, stable, ionut_n2001,
sunlightlinux
In-Reply-To: <20260506074758.8zEg1ZBh@linutronix.de>
On 5/6/26 9:47 AM, Sebastian Andrzej Siewior wrote:
> On 2026-05-06 09:14:33 [+0200], Bart Van Assche wrote:
>> If the atomic_inc() in blk_mq_quiesce_queue_nowait() is protected by
>> hctx->queue->queue_lock then the above code doesn't have to be modified.
>
> But wouldn't the atomic_inc + barrier avoid the need to have the lock?
> Isn't this a normal pattern? If the lock is kept, we could use
> non-atomic ops here then. But this avoids having the lock.
I strongly prefer a spinlock + non-atomic variables rather than using an
atomic variable and barriers because algorithms that use a spinlock are
easier to verify.
Thanks,
Bart.
^ permalink raw reply
* Re: Bug#1135514: [6.1.y regresssion] 9a95ec9144ee ("xfrm: fix ip_rt_bug race in icmp_route_lookup reverse path") causes log spam on ping to unreachable host
From: Salvatore Bonaccorso @ 2026-05-06 9:39 UTC (permalink / raw)
To: Jiayuan Chen, 1135514
Cc: Paolo Abeni, Sasha Levin, regressions, stable, podorski,
Brad Barnett, David S. Miller, David Ahern, Eric Dumazet,
Jakub Kicinski, Simon Horman
In-Reply-To: <CAL3Ev5070_=K9F9+03GrE2+4tgr=j_CO19=m4ZPTd17YSwmokQ@mail.gmail.com>
Hi Jiayuan,
On Wed, May 06, 2026 at 09:04:24AM +0800, Jiayuan Chen wrote:
> I think it because we failed to backport this patch before:
> https://lore.kernel.org/stable/20250207161555-b1a8749027831a1a@stable.kernel.org/T/#m0c880c1f04f7211aea9b7f6b4de0b64aa1726417
Which won't apply cleanly, I assume this was the reason it got not
backported to 6.1.y. Do you have a backport of that, or should the
original commit introducing the issue be reverted from 6.1.y?
Regards,
Salvtore
^ permalink raw reply
* Re: [PATCH v4 0/2] firmware_loader/ALSA: Fix TAS2781 async firmware teardown
From: Danilo Krummrich @ 2026-05-06 9:34 UTC (permalink / raw)
To: Takashi Iwai
Cc: Cássio Gabriel, Luis Chamberlain, Russ Weight,
Greg Kroah-Hartman, Rafael J. Wysocki, Takashi Iwai,
Shenghao Ding, Kevin Lu, Baojun Xu, Jaroslav Kysela, driver-core,
linux-kernel, linux-sound, stable
In-Reply-To: <874iklt12t.wl-tiwai@suse.de>
On Wed May 6, 2026 at 10:05 AM CEST, Takashi Iwai wrote:
> On Tue, 05 May 2026 13:18:15 +0200,
> Cássio Gabriel wrote:
>> Cássio Gabriel (2):
>> firmware_loader: Add cancel helper for async requests
>> ALSA: hda/tas2781: Cancel async firmware request at unbind
Looks good to me now.
> I guess this could go via driver tree? Or I can take both if I get an
> ack, too.
Sure, I can pick it up via the driver-core tree, but please also feel free to
take it through the sounds tree.
Acked-by: Danilo Krummrich <dakr@kernel.org>
> In anyway, for the series:
>
> Reviewed-by: Takashi Iwai <tiwai@suse.de>
^ permalink raw reply
* [PATCH RFC] USB: cdc-acm: Fix bit overlap and move quirk definitions to header
From: Wentao Guan @ 2026-05-06 9:32 UTC (permalink / raw)
To: oneukum; +Cc: carvsdriver, gregkh, linux-usb, linux-kernel, Wentao Guan, stable
The VENDOR_CLASS_DATA_IFACE and ALWAYS_POLL_CTRL quirk flags added in
commit f58752ebcb35 ("USB: cdc-acm: Add quirks for Yoga Book 9 14IAH10
INGENIC touchscreen") were placed inside the acm_ctrl_msg() function
rather than in the header with the other quirk flags. Then, their
values (BIT(9) and BIT(10)) collided with NO_UNION_12 which is already
BIT(9).
Move the definitions to drivers/usb/class/cdc-acm.h where they belong
and shift them to BIT(10) and BIT(11) to avoid the overlap.
Fixes: f58752ebcb35 ("USB: cdc-acm: Add quirks for Yoga Book 9 14IAH10 INGENIC touchscreen")
Cc: stable@vger.kernel.org
Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
---
drivers/usb/class/cdc-acm.c | 2 --
drivers/usb/class/cdc-acm.h | 2 ++
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index c024011dc336a..d64751c42c2bc 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -114,8 +114,6 @@ static int acm_ctrl_msg(struct acm *acm, int request, int value,
int retval;
retval = usb_autopm_get_interface(acm->control);
-#define VENDOR_CLASS_DATA_IFACE BIT(9) /* data interface uses vendor-specific class */
-#define ALWAYS_POLL_CTRL BIT(10) /* keep ctrl URB active even without an open TTY */
if (retval)
return retval;
diff --git a/drivers/usb/class/cdc-acm.h b/drivers/usb/class/cdc-acm.h
index 25fd5329a8781..01f448a783c03 100644
--- a/drivers/usb/class/cdc-acm.h
+++ b/drivers/usb/class/cdc-acm.h
@@ -115,3 +115,5 @@ struct acm {
#define DISABLE_ECHO BIT(7)
#define MISSING_CAP_BRK BIT(8)
#define NO_UNION_12 BIT(9)
+#define VENDOR_CLASS_DATA_IFACE BIT(10) /* data interface uses vendor-specific class */
+#define ALWAYS_POLL_CTRL BIT(11) /* keep ctrl URB active even without an open TTY */
--
2.30.2
^ permalink raw reply related
* Re: [PATCH v1] media: i2c: alvium: Fix controls for WB/AWB
From: Sakari Ailus @ 2026-05-06 9:28 UTC (permalink / raw)
To: Martin Hecht
Cc: martin.hecht, michael.roeder, stable, Tommaso Merciai,
Mauro Carvalho Chehab, Hans Verkuil, linux-media, linux-kernel
In-Reply-To: <20260505142513.1551721-1-mhecht73@gmail.com>
Hi Martin,
Thanks for the patch.
On Tue, May 05, 2026 at 04:25:10PM +0200, Martin Hecht wrote:
> With that patch the controls for red-balance and blue-balance were created
> only if the particular camera supports that. Otherwise the pointers on
> the control variable are initialized with NULL to prevent side effects for
> clustering with AWB control.
>
> Fixes: 0a7af872915e ("media: i2c: Add support for alvium camera")
> Signed-off-by: Martin Hecht <mhecht73@gmail.com>
> ---
> drivers/media/i2c/alvium-csi2.c | 37 ++++++++++++++++++++-------------
> 1 file changed, 22 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/media/i2c/alvium-csi2.c b/drivers/media/i2c/alvium-csi2.c
> index b62b45a4f2fc..4c6934e9e177 100644
> --- a/drivers/media/i2c/alvium-csi2.c
> +++ b/drivers/media/i2c/alvium-csi2.c
> @@ -2108,26 +2108,33 @@ static int alvium_ctrl_init(struct alvium_dev *alvium)
> 0, 0, &alvium->link_freq);
> ctrls->link_freq->flags |= V4L2_CTRL_FLAG_READ_ONLY;
This is a problem. Can you move setting the flags after checking the
handler's error status? The functions adding controls may fail and this is
simply a missing error check.
Can you submit a fix, with a Fixes: tag and this patch should be rebased on
the fix, please?
>
> + if (alvium->avail_ft.whiteb) {
> + ctrls->blue_balance = v4l2_ctrl_new_std(hdl, ops,
> + V4L2_CID_BLUE_BALANCE,
> + alvium->min_bbalance,
> + alvium->max_bbalance,
> + alvium->inc_bbalance,
> + alvium->dft_bbalance);
> + ctrls->red_balance = v4l2_ctrl_new_std(hdl, ops,
> + V4L2_CID_RED_BALANCE,
> + alvium->min_rbalance,
> + alvium->max_rbalance,
> + alvium->inc_rbalance,
> + alvium->dft_rbalance);
> + } else {
> + /* set to NULL for v4l2_ctrl_auto_cluster if not existing */
> + ctrls->blue_balance = NULL;
> + ctrls->red_balance = NULL;
Aren't the two NULL already before this?
> + }
> +
> /* Auto/manual white balance */
> if (alvium->avail_ft.auto_whiteb) {
> ctrls->auto_wb = v4l2_ctrl_new_std(hdl, ops,
> V4L2_CID_AUTO_WHITE_BALANCE,
> 0, 1, 1, 1);
> - v4l2_ctrl_auto_cluster(3, &ctrls->auto_wb, 0, false);
> - }
> -
> - ctrls->blue_balance = v4l2_ctrl_new_std(hdl, ops,
> - V4L2_CID_BLUE_BALANCE,
> - alvium->min_bbalance,
> - alvium->max_bbalance,
> - alvium->inc_bbalance,
> - alvium->dft_bbalance);
> - ctrls->red_balance = v4l2_ctrl_new_std(hdl, ops,
> - V4L2_CID_RED_BALANCE,
> - alvium->min_rbalance,
> - alvium->max_rbalance,
> - alvium->inc_rbalance,
> - alvium->dft_rbalance);
> +
> + v4l2_ctrl_auto_cluster(3, &ctrls->auto_wb, 0, true);
> + }
>
> /* Auto/manual exposure */
> if (alvium->avail_ft.auto_exp) {
--
Kind regards,
Sakari Ailus
^ permalink raw reply
* Re: [PATCH] usb: cdns3: gadget: fix request skipping after clearing halt
From: Yongchao Wu @ 2026-05-06 9:27 UTC (permalink / raw)
To: Pawel Laszczak, Peter Chen (CIX)
Cc: rogerq@kernel.org, gregkh@linuxfoundation.org,
linux-usb@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <PH7PR07MB95384829A877906E69145C76DD312@PH7PR07MB9538.namprd07.prod.outlook.com>
On 5/4/2026 5:15 PM, Pawel Laszczak wrote:
>>>
>>>>
>>>> On 26-04-27 09:01:47, Pawel Laszczak wrote:
>>>>>>
>>>>>>
>>>>>> On 26-04-24 00:06:01, Yongchao Wu wrote:
>>>>>>> According to the cdns3 datasheet, the EPRST (Endpoint Reset)
>>>>>>> command causes the DMA engine to reposition its internal pointer
>>>>>>> to the next Transfer Descriptor (TD) if it was already processing one.
>>>>>>>
>>>>>>> This issue is consistently observed during the ADB identification
>>>>>>> process on macOS hosts, where the host issues a Clear_Halt. Although
>>>>>>> commit 4bf2dd65135a ("usb: cdns3: gadget: toggle cycle bit before
>> reset
>>>>>>> reset endpoint") attempted to avoid DMA advance by toggling the
>>>>>>> cycle bit, trace logs show that on certain hosts like macOS, the
>>>>>>> DMA pointer
>>>>>>> (EP_TRADDR) still shifts after EPRST:
>>>>>>>
>>>>>>> cdns3_ctrl_req: Clear Endpoint Feature(Halt ep1out)
>>>>>>> cdns3_doorbell_epx: ep1out, ep_trbaddr f9c04030 <- Should be
>> f9c04000
>>>>>>> cdns3_gadget_giveback: ep1out: req: ... length: 16384/16384
>>>>>>>
>>>>>>> As shown above, the DMA pointer jumped to index 3 (offset 0x30),
>>>>>>> causing the controller to skip the initial TRBs of the request.
>>>>>>> This leads to data misalignment and ADB protocol hangs on macOS.
>>>>>>
>>>>>> Pawel, Is it a hardware issue? The cycle bit has already been
>>>>>> toggled before the endpoint has been reset, why the DMA pointer still
>> advances?
>>>>>
>>>>> Yongchao, could you confirm if the TD consists of three TRBs?
>>>> In our case, each TD consists of 4 TRBs.
>>>> The DMA pointer appears to advance within the same TD after EPRST.
>>>>
>>>> Each 16KB request is split into 4 TRBs (4KB each):
>>>> - TRB0 - TRB2: CHAIN
>>>> - TRB3: IOC (last TRB of the TD)
>>>>
>>>> After enqueue, the initial EP_TRADDR points to the first TRB:
>>>> EP_TRADDR = 0xf9c04000 (TRB0)
>>>>
>>>> After Clear_Halt (EPRST), it becomes:
>>>> EP_TRADDR = 0xf9c04030 (TRB3)
>>>>
>>>> Since each TRB is 12 bytes, the offset 0x30 corresponds to 4 TRBs.
>>>> This indicates that after EPRST, the DMA pointer skipped the entire
>>>> current Request and jumped directly to the start of the next Request
>>>> at 0xf9c04030
>>>>
>>>> Below is the relevant trace (trimmed):
>>>>
>>>> // enqueue request (16KB -> 4 TRBs)
>>>> cdns3_prepare_trb: dma buf: 0xf7abc000, size: 4096, ctrl: 0x00200415
>>>> cdns3_prepare_trb: dma buf: 0xf7abd000, size: 4096, ctrl: 0x00000415
>>>> cdns3_prepare_trb: dma buf: 0xf7abe000, size: 4096, ctrl: 0x00000415
>>>> cdns3_prepare_trb: dma buf: 0xf7abf000, size: 4096, ctrl: 0x00000425
>>>>
>>>> cdns3_doorbell_epx: ep1out, ep_trbaddr f9c04000
>>>>
>>>> // Clear_Halt
>>>> cdns3_ctrl_req: Clear Endpoint Feature(Halt ep1out)
>>>> cdns3_doorbell_epx: ep1out, ep_trbaddr f9c04030
>>>>
>>>
>>> Can you confirm whether the host had already sent some data for this
>>> TD prior to the endpoint reset operation?
>>>
>>
>> I confirm that the host sent no data prior to or during the EPRST operation.
>
> According to the specification, the controller may fetch TRB descriptors after
> the endpoint has been initialized.
> In complex Transfer Descriptors (TDs) consisting of several TRBs with the CH=1
> bit set, the controller may fetch additional TRBs because it treats them as a
> single logical entity.
>
> I have not been able to determine exactly how many TRBs can be prefetched
> in such a situation.
>
> According to the description of the EPRST bit:
> After endpoint reset the software is responsible for it to re-set the Endpoint
> TRADDR.
>
> This fix looks correct to me,
>
> Can you confirm which version of controller do you have in usb_cap6 register?
>
> Pawel
Thanks for the clarification.
I confirm that the version read from the usb_cap6 register is 0002450d.
Best regards,
Yongchao Wu
>>
>> TotalPhase Trace:
>> 0,HS,2700,0:06.078.671,2.057.666 ms,0 B,,13,00,Set
>> Configuration,Configuration=1
>> 0,HS,2710,0:06.080.811,1.125.266 ms,,,,,[10 SOF],[Frames: 1243.7 - 1245.0]
>> 0,HS,2711,0:06.080.955,992.550 us,2 B,,13,00,Get String Descriptor,Index=5
>> Length=2
>> 0,HS,2733,0:06.082.061,125.083 us,,,,,[2 SOF],[Frames: 1245.1 - 1245.2]
>> 0,HS,2734,0:06.082.119,104.566 us,28 B,,13,00,Get String Descriptor,Index=5
>> Length=28
>> 0,HS,2756,0:06.082.311,355.935.283 ms,,,,,[2848 SOF],[Frames: 1245.3 -
>> 1601.2]
>> 0,HS,2757,0:06.438.196,105.033 us,4 B,,13,00,Get String Descriptor,Index=0
>> Length=256
>> 0,HS,2778,0:06.438.371,875.233 us,,,,,[8 SOF],[Frames: 1601.3 - 1602.2] //1.
>> Host issues Clear_Halt
>> 0,HS,2779,0:06.439.278,51.433 us,0 B,,13,00,Clear Endpoint Feature,Halt
>> Endpoint 01 OUT
>> 0,HS,2789,0:06.439.371,500.150 us,,,,,[5 SOF],[Frames: 1602.3 - 1602.7]
>> 0,HS,2790,0:06.439.874,51.416 us,0 B,,13,00,Clear Endpoint Feature,Halt
>> Endpoint 01 IN
>> 0,HS,2800,0:06.439.996,250.116 us,,,,,[3 SOF],[Frames: 1603.0 - 1603.2] //2.
>> First OUT transaction happens
>> 0,HS,2801,0:06.440.350,1.066 us,24 B,,13,01,OUT txn,43 4E 58 4E 01 00 00 01
>> 00 00 10 00..
>> 0,HS,2805,0:06.440.371,66 ns,,,,,[1 SOF],[Frame: 1603.3]
>> 0,HS,2806,0:06.440.453,4.283 us,218 B,,13,01,OUT txn,68 6F 73 74 3A 3A 66 65
>> 61 74 75 72..
>>
>>> Pawel
>>>
>>>> Best regards,
>>>> Yongchao
>
^ permalink raw reply
* [PATCH v5] drm/bridge: imx8qxp-pxl2dpi: avoid ERR_PTR with device_node cleanup
From: Guangshuo Li @ 2026-05-06 9:23 UTC (permalink / raw)
To: Liu Ying, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Luca Ceresoli, dri-devel, imx, linux-arm-kernel,
linux-kernel
Cc: Guangshuo Li, stable
imx8qxp_pxl2dpi_get_available_ep_from_port() returns ERR_PTR()
on errors. imx8qxp_pxl2dpi_find_next_bridge() stores its return
value in a __free(device_node) variable before checking IS_ERR().
When the function returns on the error path, the cleanup action calls
of_node_put() on the ERR_PTR() value.
Do not store the endpoint node in a cleanup variable before checking
whether it is an error pointer. Use a regular device_node pointer for
the endpoint node, check it with IS_ERR() first, and release it
explicitly with of_node_put() after getting the remote port parent.
This keeps the fix minimal and avoids changing
imx8qxp_pxl2dpi_get_available_ep_from_port().
Fixes: ceea3f7806a10 ("drm/bridge: imx8qxp-pxl2dpi: simplify put of device_node pointers")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
v5:
- Make the fix minimal for stable by avoiding __free(device_node)
for the endpoint node in imx8qxp_pxl2dpi_find_next_bridge().
- Keep imx8qxp_pxl2dpi_get_available_ep_from_port() unchanged.
- Do not change imx8qxp_pxl2dpi_set_pixel_link_sel().
- Drop Frank's Reviewed-by tag due to the implementation change.
v4:
- Drop the sentence mentioning the custom static analysis tool.
- Add Frank's Reviewed-by tag.
- No functional code changes.
v3:
- Do not change DEFINE_FREE(device_node, ...).
- Fix the driver pattern by making
imx8qxp_pxl2dpi_get_available_ep_from_port() return an int and
pass the endpoint via an output argument.
- Update both callers so __free(device_node) never holds ERR_PTR().
v2:
- Fix DEFINE_FREE(device_node, ...) directly.
drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
index 441fd32dc91c..f64f57a33c62 100644
--- a/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
@@ -264,12 +264,13 @@ imx8qxp_pxl2dpi_get_available_ep_from_port(struct imx8qxp_pxl2dpi *p2d,
static int imx8qxp_pxl2dpi_find_next_bridge(struct imx8qxp_pxl2dpi *p2d)
{
- struct device_node *ep __free(device_node) =
+ struct device_node *ep =
imx8qxp_pxl2dpi_get_available_ep_from_port(p2d, 1);
if (IS_ERR(ep))
return PTR_ERR(ep);
struct device_node *remote __free(device_node) = of_graph_get_remote_port_parent(ep);
+ of_node_put(ep);
if (!remote || !of_device_is_available(remote)) {
DRM_DEV_ERROR(p2d->dev, "no available remote\n");
return -ENODEV;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 0/4] HID: Proper fix for OOM in hid-core
From: Lee Jones @ 2026-05-06 9:16 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Jiri Kosina, Filipe Laíns, Bastien Nocera, Ping Cheng,
Jason Gerecke, Viresh Kumar, Johan Hovold, Alex Elder,
Greg Kroah-Hartman, Icenowy Zheng, linux-input, linux-kernel,
greybus-dev, linux-staging, linux-usb, stable
In-Reply-To: <20260504-wip-fix-core-v3-0-ce1f11f4968f@kernel.org>
On Mon, 04 May 2026, Benjamin Tissoires wrote:
> Commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing
> bogus memset()") enforced the provided data to be at least the size of
> the declared buffer in the report descriptor to prevent a buffer
> overflow.
>
> We only had corner cases of malicious devices exposing the OOM because
> in most cases, the buffer provided by the transport layer needs to be
> allocated at probe time and is large enough to handle all the possible
> reports.
>
> However, the patch from above, which enforces the spec a little bit more
> introduced both regressions for devices not following the spec (not
> necesserally malicious), but also a stream of errors for those devices.
>
> Let's revert to the old behavior by giving more information to HID core
> to be able to decide whether it can or not memset the rest of the buffer
> to 0 and continue the processing.
>
> Note that the first commit makes an API change, but the callers are
> relatively limited, so it should be fine on its own. The second patch
> can't really make the same kind of API change because we have too many
> callers in various subsystems. We can switch them one by one to the safe
> approach when needed.
>
> The last 2 patches are small cleanups I initially put together with the
> 2 first patches, but they can be applied on their own and don't need to
> be pulled in stable like the first 2.
>
> Cheers,
> Benjamin
>
> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
> ---
> Changes in v3:
> - fixed ghib -> ghid in greybus
> - fixed i386 size_t debug size reported by kernel-bot
> - Link to v2: https://lore.kernel.org/r/20260416-wip-fix-core-v2-0-be92570e5627@kernel.org
>
> Changes in v2:
> - added a small blurb explaining the difference between the safe and the
> non safe version of hid_safe_input_report
> - Link to v1: https://lore.kernel.org/r/20260415-wip-fix-core-v1-0-ed3c4c823175@kernel.org
>
> ---
> Benjamin Tissoires (4):
> HID: pass the buffer size to hid_report_raw_event
> HID: core: introduce hid_safe_input_report()
> HID: multitouch: use __free(kfree) to clean up temporary buffers
> HID: wacom: use __free(kfree) to clean up temporary buffers
>
> drivers/hid/bpf/hid_bpf_dispatch.c | 6 ++--
> drivers/hid/hid-core.c | 67 ++++++++++++++++++++++++++++++--------
> drivers/hid/hid-gfrm.c | 4 +--
> drivers/hid/hid-logitech-hidpp.c | 2 +-
> drivers/hid/hid-multitouch.c | 18 ++++------
> drivers/hid/hid-primax.c | 2 +-
> drivers/hid/hid-vivaldi-common.c | 2 +-
> drivers/hid/i2c-hid/i2c-hid-core.c | 7 ++--
> drivers/hid/usbhid/hid-core.c | 11 ++++---
> drivers/hid/wacom_sys.c | 46 +++++++++-----------------
> drivers/staging/greybus/hid.c | 2 +-
> include/linux/hid.h | 6 ++--
> include/linux/hid_bpf.h | 14 +++++---
> 13 files changed, 109 insertions(+), 78 deletions(-)
What's the plan for this set Benjamin? -rcs or -next?
--
Lee Jones
^ permalink raw reply
* Re: [PATCH] iio: pressure: bmp280: zero-init bmp580 trigger handler buffer
From: Andy Shevchenko @ 2026-05-06 9:14 UTC (permalink / raw)
To: David Carlier
Cc: Jonathan Cameron, dlechner, nuno.sa, andy, linux-iio,
linux-kernel, stable
In-Reply-To: <20260505173455.181358-1-devnexen@gmail.com>
On Tue, May 05, 2026 at 06:34:55PM +0100, David Carlier wrote:
> bmp580_trigger_handler() builds an on-stack scan buffer containing
> two __le32 fields and an aligned_s64 timestamp, and pushes it to
> userspace via iio_push_to_buffers_with_ts(). However, only the low
> 3 bytes of each __le32 field are populated by the device data:
>
> memcpy(&buffer.comp_press, &data->buf[3], 3);
> memcpy(&buffer.comp_temp, &data->buf[0], 3);
>
> The high byte of each field is left uninitialised on the stack.
> The bmp580 channels declare storagebits = 32, so the IIO core
> transports all four bytes per sample to userspace as part of the
> scan element, leaking two bytes of kernel stack per scan.
>
> Zero-initialise the buffer before populating it, mirroring the fix
> applied to bme280_trigger_handler() in commit 018f50909e66 ("iio:
> bmp280: zero-init buffer").
Same Q, is any part of the above, including the initial report/analysis
AI assisted? If so, you have to mentioned this in the respective
Reported-by:/Closes:/et cetera tags.
...
> } buffer;
} buffer = { };
will suffice.
> int ret;
>
> + memset(&buffer, 0, sizeof(buffer));
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4] drm/bridge: imx8qxp-pxl2dpi: avoid ERR_PTR with device_node cleanup
From: Guangshuo Li @ 2026-05-06 9:09 UTC (permalink / raw)
To: Liu Ying
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Luca Ceresoli, dri-devel, imx, linux-arm-kernel, linux-kernel,
stable
In-Reply-To: <afrn-zcfiRpJzIcO@raspi>
Hi Liu,
Thanks for the review.
On Wed, 6 May 2026 at 15:03, Liu Ying <victor.liu@nxp.com> wrote:
>
> Can you provide a minimal fix for stable tree by not using the cleanup
> action? You can add the cleanup action with follow-up patch(es).
>
Yes, I agree. I will make the stable fix minimal by not changing the
helper function pattern. In v5, I will only avoid using the cleanup
action for the endpoint node in imx8qxp_pxl2dpi_find_next_bridge() and
release it explicitly with of_node_put() after
of_graph_get_remote_port_parent().
> Why do you need to initialize ep to NULL?
>
The NULL initialization was only needed because v4 changed the helper
to use an output argument together with a cleanup variable. With the
minimal fix, ep will be a normal pointer, so the NULL initialization
is not needed.
I will send a v5.
Best regards,
Guangshuo
^ permalink raw reply
* [PATCH 4/4] media: mediatek: vcodec: free working buf in vdec_vp9_slice_setup_single()
From: Haoxiang Li @ 2026-05-06 8:42 UTC (permalink / raw)
To: tiffany.lin, andrew-ct.chen, yunfei.dong, mchehab, matthias.bgg,
angelogioacchino.delregno, hverkuil+cisco, laurent.pinchart,
p.zabel, benjamin.gaignard, nicolas
Cc: linux-media, linux-kernel, linux-arm-kernel, linux-mediatek,
Haoxiang Li, stable
In-Reply-To: <20260506084203.202882-1-lihaoxiang@isrc.iscas.ac.cn>
Add an error path label in vdec_vp9_slice_setup_single()
and call vdec_vp9_slice_free_working_buffer() to free
working buffer.
Fixes: b0f407c19648 ("media: mediatek: vcodec: add vp9 decoder driver for mt8186")
Cc: stable@vger.kernel.org
Signed-off-by: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn>
---
.../mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c
index 673b17d0dd8d..1dd0f7fd642f 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c
@@ -1806,10 +1806,12 @@ static int vdec_vp9_slice_setup_single(struct vdec_vp9_slice_instance *instance,
ret = vdec_vp9_slice_setup_tile_buffer(instance, vsi, bs);
if (ret)
- goto err;
+ goto alloc_err;
return 0;
+alloc_err:
+ vdec_vp9_slice_free_working_buffer(instance);
err:
return ret;
}
--
2.25.1
^ permalink raw reply related
* [PATCH 3/4] media: mediatek: vcodec: free working buf on error path in vdec_vp9_slice_setup_lat()
From: Haoxiang Li @ 2026-05-06 8:42 UTC (permalink / raw)
To: tiffany.lin, andrew-ct.chen, yunfei.dong, mchehab, matthias.bgg,
angelogioacchino.delregno, hverkuil+cisco, laurent.pinchart,
p.zabel, benjamin.gaignard, nicolas
Cc: linux-media, linux-kernel, linux-arm-kernel, linux-mediatek,
Haoxiang Li, stable
In-Reply-To: <20260506084203.202882-1-lihaoxiang@isrc.iscas.ac.cn>
Add an error path label in vdec_vp9_slice_setup_lat()
and call vdec_vp9_slice_free_working_buffer() to free
working buffer to prevent potential memory leak.
Fixes: 5d418351ca8f ("media: mediatek: vcodec: support stateless VP9 decoding")
Cc: stable@vger.kernel.org
Signed-off-by: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn>
---
.../mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c
index 0f47b2671353..673b17d0dd8d 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c
@@ -1172,10 +1172,12 @@ static int vdec_vp9_slice_setup_lat(struct vdec_vp9_slice_instance *instance,
ret = vdec_vp9_slice_setup_tile_buffer(instance, vsi, bs);
if (ret)
- goto err;
+ goto alloc_err;
return 0;
+alloc_err:
+ vdec_vp9_slice_free_working_buffer(instance);
err:
return ret;
}
--
2.25.1
^ permalink raw reply related
* RE: [PATCH] wifi: rtw88: usb: fix memory leaks on USB write failures
From: Ping-Ke Shih @ 2026-05-06 8:41 UTC (permalink / raw)
To: luka.gejak@linux.dev, Kalle Valo
Cc: Stanislaw Gruszka, Yan-Hsuan Chuang, Brian Norris,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
In-Reply-To: <20260501162012.250013-1-luka.gejak@linux.dev>
luka.gejak@linux.dev <luka.gejak@linux.dev> wrote:
> From: Luka Gejak <luka.gejak@linux.dev>
>
> When rtw_usb_write_port() fails to submit a USB Request Block (URB)
> (e.g., due to device disconnect or ENOMEM), the completion callback is
> never executed.
>
> Currently, the driver ignores the return value of rtw_usb_write_port()
> in rtw_usb_write_data() and rtw_usb_tx_agg_skb(). Because these
> functions rely on the completion callback to free the socket buffers
> (skbs) and the transaction control block (txcb), a submission failure
> results in:
> 1. A memory leak of the allocated skb in rtw_usb_write_data().
> 2. A memory leak of the txcb structure and all aggregated skbs in
> rtw_usb_tx_agg_skb().
>
> Fix this by checking the return value of rtw_usb_write_port(). If it
> fails, explicitly free the skb in rtw_usb_write_data(), and properly
> purge the tx_ack_queue and free the txcb in rtw_usb_tx_agg_skb().
>
> Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver")
This commit doesn't introduce USB support.
> Cc: stable@vger.kernel.org
> Tested-by: Luka Gejak <luka.gejak@linux.dev>
How did you test this patch? Have you really encountered leak problem and
fixed it by this patch? Or make this patch by analysis, and test it
without regression?
> Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
> ---
> drivers/net/wireless/realtek/rtw88/usb.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtw88/usb.c b/drivers/net/wireless/realtek/rtw88/usb.c
> index 718940ebba31..d430645a3ef3 100644
> --- a/drivers/net/wireless/realtek/rtw88/usb.c
> +++ b/drivers/net/wireless/realtek/rtw88/usb.c
> @@ -456,7 +456,13 @@ static bool rtw_usb_tx_agg_skb(struct rtw_usb *rtwusb, struct sk_buff_head *list
> tx_desc = (struct rtw_tx_desc *)skb_head->data;
> qsel = le32_get_bits(tx_desc->w1, RTW_TX_DESC_W1_QSEL);
>
> - rtw_usb_write_port(rtwdev, qsel, skb_head, rtw_usb_write_port_tx_complete, txcb);
> + if (rtw_usb_write_port(rtwdev, qsel, skb_head,
> + rtw_usb_write_port_tx_complete, txcb)) {
Can we use 'ret = rtw_usb_write_port(...);' style, and check by next line?
Like the other one modified by this patch.
> + /* URB submission failed, completion won't run, free the queue */
I think this comment is not necessary.
> + skb_queue_purge(&txcb->tx_ack_queue);
Should use ieee80211_purge_tx_queue() since this is TX?
> + kfree(txcb);
> + return false;
> + }
>
> return true;
> }
> @@ -518,8 +524,10 @@ static int rtw_usb_write_data(struct rtw_dev *rtwdev,
>
> ret = rtw_usb_write_port(rtwdev, qsel, skb,
> rtw_usb_write_port_complete, skb);
> - if (unlikely(ret))
> + if (unlikely(ret)) {
> rtw_err(rtwdev, "failed to do USB write, ret=%d\n", ret);
> + dev_kfree_skb_any(skb);
> + }
>
> return ret;
> }
> --
> 2.54.0
^ permalink raw reply
* Re: [PATCH 7.0 000/307] 7.0.4-rc1 review
From: Dileep malepu @ 2026-05-06 8:36 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, rwarsow, conor, hargar, broonie, achill, sr
In-Reply-To: <20260504135142.814938198@linuxfoundation.org>
On Mon, May 4, 2026 at 7:26 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 7.0.4 release.
> There are 307 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 06 May 2026 13:50:49 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v7.x/stable-review/patch-7.0.4-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-7.0.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
> -------------
The kernel was built successfully and booted without any issues
in the virtual environment. No dmesg regressions were observed
during testing.
kernel version: 7.0.4-rc1
Configurations: x86_64_defconfig, defconfig
Architectures: arm64, x86_64
Kernel Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Commit: 4a299534048e330448f6cd13a87bb7d23549b6d6
Tested-by: Dileep Malepu <dileep.debian@gmail.com>
Regards,
Dileep Malepu.
^ permalink raw reply
* Re: [PATCH v1] serial: qcom_geni: fix kfifo underflow when flush precedes DMA completion IRQ
From: Bartosz Golaszewski @ 2026-05-06 8:30 UTC (permalink / raw)
To: Viken Dadhaniya
Cc: linux-arm-msm, linux-kernel, linux-serial, stable,
Greg Kroah-Hartman, Jiri Slaby, Bartosz Golaszewski
In-Reply-To: <20260506-serial-dma-stale-tx-buf-v1-1-e3ccb360d719@oss.qualcomm.com>
On Wed, 6 May 2026 06:45:21 +0200, Viken Dadhaniya
<viken.dadhaniya@oss.qualcomm.com> said:
> When uart_flush_buffer() runs before the DMA completion IRQ is delivered,
> the following race can occur (all steps serialized by uart_port_lock):
>
> 1. DMA starts: tx_remaining = N, kfifo contains N bytes
> 2. DMA completes in hardware; IRQ is pending but not yet delivered
> 3. uart_flush_buffer() acquires the port lock and calls kfifo_reset(),
> making kfifo_len() = 0 while tx_remaining remains N
> 4. uart_flush_buffer() releases the port lock
> 5. DMA IRQ fires; handle_tx_dma() acquires the port lock and calls
> uart_xmit_advance(uport, tx_remaining) on an empty kfifo
>
> uart_xmit_advance() increments kfifo->out by tx_remaining. Since
> kfifo_reset() already set both in and out to 0, out wraps past in,
> causing kfifo_len() to return UART_XMIT_SIZE - tx_remaining. The next
> start_tx_dma() call then submits a DMA transfer of stale buffer data.
>
> Fix this by snapshotting kfifo_len() at the start of handle_tx_dma()
> and skipping uart_xmit_advance() when fifo_len < tx_remaining, which
> indicates the kfifo was reset by a preceding flush.
>
> Fixes: 2aaa43c70778 ("tty: serial: qcom-geni-serial: add support for serial engine DMA")
> Cc: stable@vger.kernel.org
> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
> ---
Make sense, thanks.
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v5 0/7] firmware: samsung: acpm: Various fixes for sashiko bug reports
From: Tudor Ambarus @ 2026-05-06 8:29 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alim Akhtar
Cc: linux-kernel, linux-samsung-soc, linux-arm-kernel, peter.griffin,
andre.draszik, jyescas, kernel-team, stable, Titouan Ameline
In-Reply-To: <20260505-acpm-fixes-sashiko-reports-v5-0-43b5ee7f1674@linaro.org>
Hi Krzysztof!
I checked Sashiko's review feedback on the set, and in my opinion the
set is ready to be queued. I'm going to send the cleanup and the
ACPM TMU helper driver patches now.
Thanks!
ta
^ permalink raw reply
* RE: [PATCH] wifi: rtw88: increase TX report timeout to fix race condition
From: Ping-Ke Shih @ 2026-05-06 8:23 UTC (permalink / raw)
To: Luka Gejak, Bitterblue Smith, Kalle Valo
Cc: Yan-Hsuan Chuang, Brian Norris, Stanislaw Gruszka,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
In-Reply-To: <39E7B292-F03C-4307-B0BE-62DEC191FED8@linux.dev>
> >> I also realize now that globally changing RTW_TX_PROBE_TIMEOUT to
> >> 2500ms is too heavy-handed. Since this impacts all rtw88 chips,
> >> including PCIe variants where 500ms might be exactly what is needed to
> >> catch a real firmware lockup, the blast radius is too large. How would
> >> you prefer I handle this for the v2 patch? I can either implement a
> >> more conservative global bump, or make the timeout dynamic based on
> >> the HCI interface so USB devices get a longer timeout to accommodate
> >> the bus latency during scans.
I'd limit this change to USB devices, even limit to RTL8723DU you tested.
As RTL8822CU supports hw_scan, the symptom might be different.
Ping-Ke
^ permalink raw reply
* [PATCH net v8 2/2] ipv6: flowlabel: enforce per-netns limit for unprivileged callers
From: Maoyi Xie @ 2026-05-06 8:24 UTC (permalink / raw)
To: David S . Miller
Cc: Jakub Kicinski, Paolo Abeni, Eric Dumazet, David Ahern,
Alexey Kuznetsov, Willem de Bruijn, Willem de Bruijn, netdev,
linux-kernel, stable, Maoyi Xie
In-Reply-To: <20260506082416.2259567-1-maoyixie.tju@gmail.com>
From: Maoyi Xie <maoyi.xie@ntu.edu.sg>
fl_size, fl_ht and ip6_fl_lock in net/ipv6/ip6_flowlabel.c are
file scope and shared across netns. mem_check() reads fl_size to
decide whether to deny non-CAP_NET_ADMIN callers. capable() runs
against init_user_ns, so an unprivileged user in any non-init
userns can push fl_size past FL_MAX_SIZE - FL_MAX_SIZE / 4 and
starve every other unprivileged userns on the host.
Add struct netns_ipv6::flowlabel_count, bumped and decremented
next to fl_size in fl_intern, ip6_fl_gc and ip6_fl_purge. The new
field fills the existing 4-byte hole after ipmr_seq, so struct
netns_ipv6 stays the same size on 64-bit builds.
Bump FL_MAX_SIZE from 4096 to 8192. It has been 4096 since the
file was added. Machines and connection counts have grown.
mem_check() folds an extra per-netns ceiling into the existing
non-CAP_NET_ADMIN conditional. The ceiling is half of the total
budget that unprivileged callers have ever been able to use, i.e.
(FL_MAX_SIZE - FL_MAX_SIZE / 4) / 2 = 3072 entries. With
FL_MAX_SIZE doubled, this preserves the original per-user reach
of 3K (what an unprivileged caller could already obtain before
this change), while forcing an attacker to spread allocations
across at least two netns to exhaust the global non-CAP_NET_ADMIN
budget.
CAP_NET_ADMIN against init_user_ns still bypasses both caps.
The previous patch took ip6_fl_lock across mem_check and
fl_intern, so the new flowlabel_count read in mem_check and the
new flowlabel_count++ in fl_intern run under the same critical
section. flowlabel_count is therefore plain int, like fl_size.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Suggested-by: Willem de Bruijn <willemb@google.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Cc: stable@vger.kernel.org # v5.15+
Signed-off-by: Maoyi Xie <maoyi.xie@ntu.edu.sg>
---
include/net/netns/ipv6.h | 1 +
net/ipv6/ip6_flowlabel.c | 14 +++++++++++---
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/include/net/netns/ipv6.h b/include/net/netns/ipv6.h
index 499e42881..875916d60 100644
--- a/include/net/netns/ipv6.h
+++ b/include/net/netns/ipv6.h
@@ -119,6 +119,7 @@ struct netns_ipv6 {
struct fib_notifier_ops *notifier_ops;
struct fib_notifier_ops *ip6mr_notifier_ops;
atomic_t ipmr_seq;
+ int flowlabel_count;
struct {
struct hlist_head head;
spinlock_t lock;
diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c
index a89746431..b1ccdf0dc 100644
--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -36,7 +36,7 @@
/* FL hash table */
#define FL_MAX_PER_SOCK 32
-#define FL_MAX_SIZE 4096
+#define FL_MAX_SIZE 8192
#define FL_HASH_MASK 255
#define FL_HASH(l) (ntohl(l)&FL_HASH_MASK)
@@ -162,8 +162,9 @@ static void ip6_fl_gc(struct timer_list *unused)
ttd = fl->expires;
if (time_after_eq(now, ttd)) {
*flp = fl->next;
- fl_free(fl);
fl_size--;
+ fl->fl_net->ipv6.flowlabel_count--;
+ fl_free(fl);
continue;
}
if (!sched || time_before(ttd, sched))
@@ -197,6 +198,7 @@ static void __net_exit ip6_fl_purge(struct net *net)
*flp = fl->next;
fl_free(fl);
fl_size--;
+ net->ipv6.flowlabel_count--;
continue;
}
flp = &fl->next;
@@ -243,6 +245,7 @@ static struct ip6_flowlabel *fl_intern(struct net *net,
fl->next = fl_ht[FL_HASH(fl->label)];
rcu_assign_pointer(fl_ht[FL_HASH(fl->label)], fl);
fl_size++;
+ net->ipv6.flowlabel_count++;
return NULL;
}
@@ -460,6 +463,9 @@ fl_create(struct net *net, struct sock *sk, struct in6_flowlabel_req *freq,
static int mem_check(struct sock *sk)
{
+ const int unpriv_total_limit = FL_MAX_SIZE - (FL_MAX_SIZE / 4);
+ const int unpriv_user_limit = unpriv_total_limit / 2;
+ struct net *net = sock_net(sk);
int room;
struct ipv6_fl_socklist *sfl;
int count = 0;
@@ -478,7 +484,9 @@ static int mem_check(struct sock *sk)
if (room <= 0 ||
((count >= FL_MAX_PER_SOCK ||
- (count > 0 && room < FL_MAX_SIZE/2) || room < FL_MAX_SIZE/4) &&
+ (count > 0 && room < FL_MAX_SIZE / 2) ||
+ room < FL_MAX_SIZE / 4 ||
+ net->ipv6.flowlabel_count >= unpriv_user_limit) &&
!capable(CAP_NET_ADMIN)))
return -ENOBUFS;
--
2.34.1
^ permalink raw reply related
* [PATCH net v8 1/2] ipv6: flowlabel: take ip6_fl_lock across mem_check and fl_intern
From: Maoyi Xie @ 2026-05-06 8:24 UTC (permalink / raw)
To: David S . Miller
Cc: Jakub Kicinski, Paolo Abeni, Eric Dumazet, David Ahern,
Alexey Kuznetsov, Willem de Bruijn, Willem de Bruijn, netdev,
linux-kernel, stable, Maoyi Xie
In-Reply-To: <20260506082416.2259567-1-maoyixie.tju@gmail.com>
From: Maoyi Xie <maoyi.xie@ntu.edu.sg>
mem_check() in net/ipv6/ip6_flowlabel.c reads fl_size without
holding ip6_fl_lock. fl_intern() takes the lock immediately
afterwards. The two checks therefore race against concurrent
fl_intern, ip6_fl_gc and ip6_fl_purge writers, which makes the
mem_check budget check approximate.
Move spin_lock_bh(&ip6_fl_lock) and the matching unlock from
fl_intern() into its only caller ipv6_flowlabel_get(). The
mem_check() call now runs under the same critical section as the
fl_intern() insert, so the budget check is exact.
With all writers and the read of fl_size under ip6_fl_lock,
convert fl_size from atomic_t to plain int. The four sites that
update or read fl_size are fl_intern (insert path), ip6_fl_gc
(garbage collector, the !sched check and the per-entry decrement),
ip6_fl_purge (per-netns purge), and mem_check (budget check), and
all four now run under ip6_fl_lock.
This is a prerequisite for adding a per-netns budget alongside
fl_size. The follow-up patch adds netns_ipv6::flowlabel_count and
folds it into mem_check().
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Suggested-by: Willem de Bruijn <willemb@google.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Maoyi Xie <maoyi.xie@ntu.edu.sg>
---
net/ipv6/ip6_flowlabel.c | 34 +++++++++++++++++++++-------------
1 file changed, 21 insertions(+), 13 deletions(-)
diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c
index c92f98c6f..a89746431 100644
--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -40,7 +40,7 @@
#define FL_HASH_MASK 255
#define FL_HASH(l) (ntohl(l)&FL_HASH_MASK)
-static atomic_t fl_size = ATOMIC_INIT(0);
+static int fl_size;
static struct ip6_flowlabel __rcu *fl_ht[FL_HASH_MASK+1];
static void ip6_fl_gc(struct timer_list *unused);
@@ -163,7 +163,7 @@ static void ip6_fl_gc(struct timer_list *unused)
if (time_after_eq(now, ttd)) {
*flp = fl->next;
fl_free(fl);
- atomic_dec(&fl_size);
+ fl_size--;
continue;
}
if (!sched || time_before(ttd, sched))
@@ -172,7 +172,7 @@ static void ip6_fl_gc(struct timer_list *unused)
flp = &fl->next;
}
}
- if (!sched && atomic_read(&fl_size))
+ if (!sched && fl_size)
sched = now + FL_MAX_LINGER;
if (sched) {
mod_timer(&ip6_fl_gc_timer, sched);
@@ -196,7 +196,7 @@ static void __net_exit ip6_fl_purge(struct net *net)
atomic_read(&fl->users) == 0) {
*flp = fl->next;
fl_free(fl);
- atomic_dec(&fl_size);
+ fl_size--;
continue;
}
flp = &fl->next;
@@ -210,10 +210,10 @@ static struct ip6_flowlabel *fl_intern(struct net *net,
{
struct ip6_flowlabel *lfl;
+ lockdep_assert_held(&ip6_fl_lock);
+
fl->label = label & IPV6_FLOWLABEL_MASK;
- rcu_read_lock();
- spin_lock_bh(&ip6_fl_lock);
if (label == 0) {
for (;;) {
fl->label = htonl(get_random_u32())&IPV6_FLOWLABEL_MASK;
@@ -235,8 +235,6 @@ static struct ip6_flowlabel *fl_intern(struct net *net,
lfl = __fl_lookup(net, fl->label);
if (lfl) {
atomic_inc(&lfl->users);
- spin_unlock_bh(&ip6_fl_lock);
- rcu_read_unlock();
return lfl;
}
}
@@ -244,9 +242,7 @@ static struct ip6_flowlabel *fl_intern(struct net *net,
fl->lastuse = jiffies;
fl->next = fl_ht[FL_HASH(fl->label)];
rcu_assign_pointer(fl_ht[FL_HASH(fl->label)], fl);
- atomic_inc(&fl_size);
- spin_unlock_bh(&ip6_fl_lock);
- rcu_read_unlock();
+ fl_size++;
return NULL;
}
@@ -464,10 +460,14 @@ fl_create(struct net *net, struct sock *sk, struct in6_flowlabel_req *freq,
static int mem_check(struct sock *sk)
{
- int room = FL_MAX_SIZE - atomic_read(&fl_size);
+ int room;
struct ipv6_fl_socklist *sfl;
int count = 0;
+ lockdep_assert_held(&ip6_fl_lock);
+
+ room = FL_MAX_SIZE - fl_size;
+
if (room > FL_MAX_SIZE - FL_MAX_PER_SOCK)
return 0;
@@ -692,11 +692,19 @@ static int ipv6_flowlabel_get(struct sock *sk, struct in6_flowlabel_req *freq,
if (!sfl1)
goto done;
+ rcu_read_lock();
+ spin_lock_bh(&ip6_fl_lock);
err = mem_check(sk);
+ if (err == 0)
+ fl1 = fl_intern(net, fl, freq->flr_label);
+ else
+ fl1 = NULL;
+ spin_unlock_bh(&ip6_fl_lock);
+ rcu_read_unlock();
+
if (err != 0)
goto done;
- fl1 = fl_intern(net, fl, freq->flr_label);
if (fl1)
goto recheck;
--
2.34.1
^ permalink raw reply related
* [PATCH net v8 0/2] ipv6: flowlabel: per-netns budget for unprivileged callers
From: Maoyi Xie @ 2026-05-06 8:24 UTC (permalink / raw)
To: David S . Miller
Cc: Jakub Kicinski, Paolo Abeni, Eric Dumazet, David Ahern,
Alexey Kuznetsov, Willem de Bruijn, Willem de Bruijn, netdev,
linux-kernel, stable, Maoyi Xie
From: Maoyi Xie <maoyi.xie@ntu.edu.sg>
This series fixes the cross-tenant DoS in net/ipv6/ip6_flowlabel.c.
v1 through v6 were single-patch postings, each in its own thread.
v6 review pointed out that the existing fl_size read in
mem_check() and the corresponding write in fl_intern() are not in
the same critical section. v7 split the work into 2 patches.
Patch 1/2 is a prerequisite. It moves spin_lock_bh(&ip6_fl_lock)
and the matching unlock from fl_intern() into its only caller
ipv6_flowlabel_get(), so the mem_check() call runs under the same
critical section as the fl_intern() insert. With all writers and
the read of fl_size under the lock, fl_size is converted from
atomic_t to plain int. This is independent of the per-netns
budget. It also makes 2/2 backportable without conflicts.
Patch 2/2 is the v6 patch, rebased on 1/2.
- flowlabel_count is plain int rather than atomic_t, since the
previous patch put all writers and readers under ip6_fl_lock.
- In ip6_fl_gc(), fl_free() is now placed below the fl_size
and flowlabel_count decrements, removing the v6 cache of
fl->fl_net.
- In ip6_fl_purge(), fl_free() stays in its original position.
The function argument net is used for flowlabel_count.
- mem_check() uses spaces around the / operator on all four
expressions, addressing the checkpatch note in v6 review.
Numeric budget (preserved from v6):
pre-patch:
global non-CAP_NET_ADMIN budget = FL_MAX_SIZE - FL_MAX_SIZE/4
= 4096 - 1024 = 3072
per-actor reach = 3072
post-patch:
FL_MAX_SIZE doubled to 8192
global non-CAP_NET_ADMIN budget = 8192 - 2048 = 6144
per-netns ceiling = 6144 / 2 = 3072
per-actor reach = 3072 (preserved)
CAP_NET_ADMIN against init_user_ns still bypasses both caps.
Reproducer (KASAN VM, 4 cores, qemu): unprivileged netns A holds
3072 flowlabels via 100 procs. Fresh unprivileged netns B then
allocates 32 flowlabels (the FL_MAX_PER_SOCK ceiling for one
socket), the same as a clean baseline. Without the per-netns
ceiling, netns A could push fl_size past FL_MAX_SIZE - FL_MAX_SIZE
/ 4 and netns B would see allocations denied.
v8:
- 1/2: replaced the "Caller must hold ip6_fl_lock" comment in
fl_intern() with lockdep_assert_held(&ip6_fl_lock), matching
the runtime check already used in mem_check(), per Willem's
review.
- 1/2: added Fixes: 1da177e4c3f4 trailer to match 2/2, per
Willem's review.
- Carried forward Reviewed-by: Willem de Bruijn on both
patches.
- No code change beyond the lockdep_assert_held swap.
v7:
- 2-patch series: 1/2 (lock prep) and 2/2 (v6 rebased on 1/2).
- 2/2: flowlabel_count int, fl_free() reorder removed in
ip6_fl_purge(), checkpatch / spacing in mem_check() fixed.
v6: rebased onto current net (resolves the conflict on
include/net/netns/ipv6.h that v5 hit). fl_free() restored
to its pre-series position, with fl->fl_net cached locally
in ip6_fl_gc().
v5: replaced the per-netns ceiling FL_MAX_SIZE/8 with the
computed unpriv_user_limit = (FL_MAX_SIZE - FL_MAX_SIZE/4)/2,
which evaluates to 3072.
v4: addressed Willem's v3 review on netdev. Dropped the
flowlabel_has_excl cacheline argument in favour of "fills
the existing 4-byte hole after ipmr_seq".
v3: addressed Willem's review on the private security@ thread.
Merged FL_MAX_SIZE doubling, dropped test data, moved
flowlabel_count near ipmr_seq, inlined fl->fl_net in
ip6_fl_gc().
v2: per-netns counter + cap, sent to security@ as a 2-patch
series.
v1: fix-shape sketch in original disclosure.
Maoyi Xie (2):
ipv6: flowlabel: take ip6_fl_lock across mem_check and fl_intern
ipv6: flowlabel: enforce per-netns limit for unprivileged callers
include/net/netns/ipv6.h | 1 +
net/ipv6/ip6_flowlabel.c | 46 +++++++++++++++++++++++++++-------------
2 files changed, 32 insertions(+), 15 deletions(-)
base-commit: ebb639024ebd47a13a511cce6ae630c15e4b3126
--
2.34.1
^ permalink raw reply
* Re: [PATCH] ALSA: core: Serialize deferred fasync state checks
From: Takashi Iwai @ 2026-05-06 8:08 UTC (permalink / raw)
To: Cássio Gabriel
Cc: Takashi Iwai, Jaroslav Kysela, linux-sound, linux-kernel, stable
In-Reply-To: <20260506-alsa-core-fasync-on-lock-v1-1-ea48c77d6ca4@gmail.com>
On Wed, 06 May 2026 05:34:47 +0200,
Cássio Gabriel wrote:
>
> snd_fasync_helper() updates fasync->on under snd_fasync_lock, and
> snd_fasync_work_fn() now also evaluates fasync->on under the same
> lock. snd_kill_fasync() still tests the flag before taking the lock,
> leaving an unsynchronized read against FASYNC enable/disable updates.
>
> Move the enabled-state check into the locked section.
>
> Also clear fasync->on under snd_fasync_lock in snd_fasync_free()
> before unlinking the pending entry. Together with the locked sender-side
> check, this publishes teardown before flushing the deferred work and
> prevents a racing sender from requeueing the entry after free has
> started.
>
> Fixes: ef34a0ae7a26 ("ALSA: core: Add async signal helpers")
> Fixes: 8146cd333d23 ("ALSA: core: Fix potential data race at fasync handling")
> Cc: stable@vger.kernel.org
> Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Thanks, applied now.
Takashi
^ permalink raw reply
* Re: [PATCH v4 0/2] firmware_loader/ALSA: Fix TAS2781 async firmware teardown
From: Takashi Iwai @ 2026-05-06 8:05 UTC (permalink / raw)
To: Cássio Gabriel
Cc: Luis Chamberlain, Russ Weight, Danilo Krummrich,
Greg Kroah-Hartman, Rafael J. Wysocki, Takashi Iwai,
Shenghao Ding, Kevin Lu, Baojun Xu, Jaroslav Kysela, driver-core,
linux-kernel, linux-sound, stable
In-Reply-To: <20260505-alsa-hda-tas2781-fw-callback-teardown-v4-0-e7c4bf930dc8@gmail.com>
On Tue, 05 May 2026 13:18:15 +0200,
Cássio Gabriel wrote:
>
> TAS2781 HDA I2C and SPI queue RCA firmware loading with
> request_firmware_nowait() during component bind. The firmware loader
> keeps the callback module pinned and holds a device reference, but it
> does not provide a way for drivers to cancel or synchronize the queued
> callback before tearing down driver-private state.
>
> Add a small firmware-loader helper to cancel or synchronize async firmware
> requests, then use it from TAS2781 HDA unbind before controls and DSP state
> are removed.
>
> No hardware runtime test was available.
>
> Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
> ---
> Changes in v4:
> - Use spin_lock_irq() in the worker and cancel paths, which run from
> sleepable contexts.
> - Fold kfree(fw_work) into firmware_work_free().
> - Keep irqsave in the request path so GFP_ATOMIC callers do not depend on
> IRQ state assumptions.
> - Link to v3: https://patch.msgid.link/20260501-alsa-hda-tas2781-fw-callback-teardown-v3-0-8d9f873b97bd@gmail.com
>
> Changes in v3:
> - Keep request_firmware_nowait() manually managed instead of making the
> existing API implicitly devres-managed.
> - Track scheduled async firmware work in an internal list protected by a
> spinlock so request_firmware_nowait_cancel() can find and synchronize a
> pending request without weakening the GFP_ATOMIC caller contract.
> - Match pending requests by device, callback context and callback function
> instead of matching by callback alone.
> - Avoid the devres_add() / schedule_work() ordering race pointed out in
> review.
> - Leave devres-managed support for a separate devm_request_firmware_nowait()
> API if needed.
> - Link to v2: https://patch.msgid.link/20260430-alsa-hda-tas2781-fw-callback-teardown-v2-0-2c7d89cb3175@gmail.com
>
> Changes in v2:
> - Add request_firmware_nowait_cancel() in the firmware loader instead of
> tracking the callback lifetime locally in the TAS2781 HDA driver.
> - Keep the TAS2781 change to a cancel/sync call in I2C and SPI unbind.
> - Drop the unrelated cached kcontrol pointer cleanup from the previous
> local-driver version.
> - Link to v1: https://patch.msgid.link/20260430-alsa-hda-tas2781-fw-callback-teardown-v1-1-874367d6b41b@gmail.com
>
> ---
> Cássio Gabriel (2):
> firmware_loader: Add cancel helper for async requests
> ALSA: hda/tas2781: Cancel async firmware request at unbind
I guess this could go via driver tree? Or I can take both if I get an
ack, too.
In anyway, for the series:
Reviewed-by: Takashi Iwai <tiwai@suse.de>
thanks,
Takashi
^ permalink raw reply
* Re: [PATCH v5] drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS()
From: Tomi Valkeinen @ 2026-05-06 8:01 UTC (permalink / raw)
To: Vitor Soares
Cc: Vitor Soares, dri-devel, linux-kernel, Luca Ceresoli, stable,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter
In-Reply-To: <20260505134705.188661-2-ivitro@gmail.com>
Hi,
On 05/05/2026 16:47, Vitor Soares wrote:
> From: Vitor Soares <vitor.soares@toradex.com>
>
> The deprecated UNIVERSAL_DEV_PM_OPS() macro uses the provided callbacks
> for both runtime PM and system sleep. This causes the DSI clocks to be
> disabled twice: once during runtime suspend and again during system
> suspend, resulting in a WARN message from the clock framework when
> attempting to disable already-disabled clocks.
>
> [ 84.384540] clk:231:5 already disabled
> [ 84.388314] WARNING: CPU: 2 PID: 531 at /drivers/clk/clk.c:1181 clk_core_disable+0xa4/0xac
> ...
> [ 84.579183] Call trace:
> [ 84.581624] clk_core_disable+0xa4/0xac
> [ 84.585457] clk_disable+0x30/0x4c
> [ 84.588857] cdns_dsi_suspend+0x20/0x58 [cdns_dsi]
> [ 84.593651] pm_generic_suspend+0x2c/0x44
> [ 84.597661] ti_sci_pd_suspend+0xbc/0x15c
> [ 84.601670] dpm_run_callback+0x8c/0x14c
> [ 84.605588] __device_suspend+0x1a0/0x56c
> [ 84.609594] dpm_suspend+0x17c/0x21c
> [ 84.613165] dpm_suspend_start+0xa0/0xa8
> [ 84.617083] suspend_devices_and_enter+0x12c/0x634
> [ 84.621872] pm_suspend+0x1fc/0x368
>
> To address this issue, replace UNIVERSAL_DEV_PM_OPS() with
> RUNTIME_PM_OPS(). Bridge and panel drivers should only deal with runtime
> PM, as the DRM framework manages system-wide power transitions through
> the bridge enable() and disable() hooks.
>
> Link: https://lore.kernel.org/all/fbde0659-78f3-46e4-98cf-d832f765a18b@ideasonboard.com/
> Cc: stable@vger.kernel.org # 6.1.x
> Fixes: e19233955d9e ("drm/bridge: Add Cadence DSI driver")
> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
Thanks, pushed to drm-misc.
Tomi
^ permalink raw reply
* Re: [PATCH] ALSA: seq: Fix UMP group 16 filtering
From: Takashi Iwai @ 2026-05-06 7:57 UTC (permalink / raw)
To: Cássio Gabriel
Cc: Takashi Iwai, Jaroslav Kysela, linux-sound, linux-kernel, stable
In-Reply-To: <20260506-alsa-seq-ump-group16-filter-v1-1-b75160bf6993@gmail.com>
On Wed, 06 May 2026 05:15:48 +0200,
Cássio Gabriel wrote:
>
> The sequencer UAPI defines group_filter as an unsigned int bitmap.
> Bit 0 filters groupless messages and bits 1-16 filter UMP groups 1-16.
>
> The internal snd_seq_client storage is only unsigned short, so bit 16
> is truncated when userspace sets the filter. The same truncation affects
> the automatic UMP client filter used to avoid delivery to inactive
> groups, so events for group 16 cannot be filtered.
>
> Store the internal bitmap as unsigned int and keep both userspace-provided
> and automatically generated values limited to the defined UAPI bits.
>
> Fixes: d2b706077792 ("ALSA: seq: Add UMP group filter")
> Cc: stable@vger.kernel.org
> Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
A good catch! Applied now.
thanks,
Takashi
^ 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