* Re: [PATCH 1/4] drm/hibmc: Use drm_atomic_helper_check_plane_state()
From: Yongbang Shi @ 2026-04-17 7:08 UTC (permalink / raw)
To: Thomas Zimmermann, tiantao6, kong.kongxinwei, sumit.semwal,
yongqin.liu, jstultz, maarten.lankhorst, mripard, airlied, simona
Cc: dri-devel, Rongrong Zou, Sean Paul, Dmitry Baryshkov, stable,
Liangjian(Jim,Kunpeng Solution Development Dept), Chenjianmin,
fengsheng (A), helin (T), shiyongbang
In-Reply-To: <34ecfa0c-a6f5-48b0-b706-27e1f9868dd7@suse.de>
> Hi
>
> Am 16.04.26 um 15:22 schrieb Yongbang Shi:
> [...]
>> However, I believe the modified version is the better implementation,
>> the plane check should be complete even if the CRTC is not enabled.
>
> Great.
>
> I agree that the logic in the helper is non-intuitive. I'll send you an
> updated series with an improved commit message next week.
>
Looking forward to the updated series next week, and I appreciate the
improved commit message as well.
Thanks,
Yongbang.
> Best regards
> Thomas
>
>>
>> [1]
>> https://elixir.bootlin.com/linux/v7.0/source/drivers/gpu/drm/
>> hisilicon/hibmc/hibmc_drm_de.c#L84
>> [2]
>> https://elixir.bootlin.com/linux/v7.0/source/drivers/gpu/drm/
>> hisilicon/hibmc/hibmc_drm_de.c#L94
>>
>>
>>>
>>>>
>>>>> + if (ret)
>>>>> + return ret;
>>>>> + else if (!new_plane_state->visible)
>>>>> return 0;
>>>>> - if (new_plane_state->crtc_x + new_plane_state->crtc_w >
>>>>> - crtc_state->adjusted_mode.hdisplay ||
>>>>> - new_plane_state->crtc_y + new_plane_state->crtc_h >
>>>>> - crtc_state->adjusted_mode.vdisplay) {
>>>>> - drm_dbg_atomic(plane->dev, "visible portion of plane is
>>>>> invalid\n");
>>>>> - return -EINVAL;
>>>>> - }
>>>>> -
>>>> The purpose of this check is to ensure that the right and bottom
>>>> boundaries of the plane do not extend beyond the crtc. In
>>>> `drm_atomic_helper_check_plane_state`, `drm_mode_get_hv_timing` is
>>>> called to retrieve the crtc boundaries, and `drm_rect_clip_scaled` is
>>>> used to clip the plane, any portions extending beyond the right and
>>>> bottom boundaries are discarded.
>>>>
>>>> I'd like to confirm that my understanding is correct? previously, the
>>>> check failed if the plane exceeded the boundaries, but now, after
>>>> `drm_atomic_helper_check_plane_state` is called, the plane is
>>>> clipped to
>>>> fit within the boundaries.
>>> Yes. This sets plane_state->dst, which is clipped to the size of the
>>> display mode. But it also tests that the primary plane covers the whole
>>> display.
>>>
>>>> in function drm_rect_clip_scaled:
>>>>
>>>> diff = dst->x2 - clip->x2;
>>>> if (diff > 0) {
>>>> ...
>>>> dst->x2 -= diff;
>>>> }
>>>> diff = dst->y2 - clip->y2;
>>>> if (diff > 0) {
>>>> ...
>>>> dst->y2 -= diff;
>>>> }
>>> I agree, the logic in drm_atomic_helper_check_plane_state() is hard to
>>> understand. It sets the clip rectangle to the size of the display mode
>>> (or zero if the CRTC is off) at [1]. Then is clips the source and
>>> destination coordinates against the clipping rectangle at [2].
>>>
>>> Because we set can_position to false, it tests if the destination and
>>> clipping rectangles are equal at [3]. This is similar to the that is
>>> being replaced, but with plane state correctly adjusted. If both
>>> rectangles are equal, it returns success. If the destination is too
>>> small, it fails with an errno code and a warning.
>>>
>>> If the plane is not visible, the helper already returned at [4].
>>>
>>> [1] https://elixir.bootlin.com/linux/v7.0/source/drivers/gpu/drm/
>>> drm_atomic_helper.c#L943
>>> [2] https://elixir.bootlin.com/linux/v7.0/source/drivers/gpu/drm/
>>> drm_atomic_helper.c#L945
>>> [3] https://elixir.bootlin.com/linux/v7.0/source/drivers/gpu/drm/
>>> drm_atomic_helper.c#L959
>>> [4] https://elixir.bootlin.com/linux/v7.0/source/drivers/gpu/drm/
>>> drm_atomic_helper.c#L949
>>>
>>> It is now possible to have a primary plane that is larger than the
>>> display mode. This is a feature of the DRM API.
>>>
>> Thank you so much for the explanation. It's much clearer to understand
>> drm_atomic_helper_check_plane_state.
>>
>> By the way, we ran some basic tests on this set of patches using the
>> latest BMC chip, and everything worked fine.
>>
>>
>> Thanks.
>>
>> Best regards
>> Yongbang.
>>
>>
>>> Best regards
>>> Thomas
>>>
>>>
>>>>
>>>> Thanks.
>>>>
>>>> Best regards
>>>> Yongbang.
>>>>
>>>>
>>>>> if (new_plane_state->fb->pitches[0] % 128 != 0) {
>>>>> drm_dbg_atomic(plane->dev, "wrong stride with 128-byte
>>>>> aligned\n");
>>>>> return -EINVAL;
>>>>> }
>>>>> +
>>>>> return 0;
>>>>> }
>>>>>
>> Reviewed-by: Yongbang Shi <shiyongbang@huawei.com>
>>
>>
>
^ permalink raw reply
* Re: [PATCH] ksmbd: validate num_aces and harden ACE walk in smb_inherit_dacl()
From: Namjae Jeon @ 2026-04-17 7:07 UTC (permalink / raw)
To: Michael Bommarito
Cc: Steve French, linux-cifs, Sergey Senozhatsky, Tom Talpey, stable
In-Reply-To: <20260416200439.2987930-1-michael.bommarito@gmail.com>
> diff --git a/fs/smb/server/smbacl.c b/fs/smb/server/smbacl.c
> index d5943256c071..fc4fcd48d6c9 100644
> --- a/fs/smb/server/smbacl.c
> +++ b/fs/smb/server/smbacl.c
> @@ -1105,8 +1105,25 @@ int smb_inherit_dacl(struct ksmbd_conn *conn,
> goto free_parent_pntsd;
> }
>
> - aces_base = kmalloc(sizeof(struct smb_ace) * num_aces * 2,
> - KSMBD_DEFAULT_GFP);
> + aces_size = pdacl_size - sizeof(struct smb_acl);
> +
> + /*
> + * Validate num_aces against the DACL payload before allocating.
> + * Each ACE must be at least as large as its fixed-size header
> + * (up to the SID base), so num_aces cannot exceed the payload
> + * divided by the minimum ACE size. This mirrors the check in
> + * parse_dacl() added by commit 1b8b67f3c5e5 ("ksmbd: fix
> + * incorrect validation for num_aces field of smb_acl").
> + */
Please remove the specific commit hash and patch name in the comments.
Thanks.
^ permalink raw reply
* Re: [PATCH v2] usb: dwc3: Move GUID programming after PHY initialization
From: Selvarasu Ganesan @ 2026-04-17 7:02 UTC (permalink / raw)
To: Thinh.Nguyen, gregkh, paulz, balbi, linux-usb, linux-kernel
Cc: jh0801.jung, akash.m5, h10.kim, alim.akhtar, thiagu.r,
muhammed.ali, stable, Pritam Manohar Sutar
In-Reply-To: <20260417063314.2359-1-selvarasu.g@samsung.com>
On 4/17/2026 12:03 PM, Selvarasu Ganesan wrote:
> The Linux Version Code is currently written to the GUID register before
> PHY initialization. Certain PHY implementations (such as Synopsys eUSB
> PHY performing link_sw_reset) clear the GUID register to its default
> value during initialization, causing the kernel version information to
> be lost.
>
> Move the GUID register programming to occur after PHY initialization
> completes to ensure the Linux version information persists.
>
> Fixes: fa0ea13e9f1c ("usb: dwc3: core: write LINUX_VERSION_CODE to our GUID register")
> Cc: stable@vger.kernel.org
> Reported-by: Pritam Manohar Sutar <pritam.sutar@samsung.com>
> Signed-off-by: Selvarasu Ganesan <selvarasu.g@samsung.com>
> ---
> drivers/usb/dwc3/core.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
Apologies, I missed including the what is change in patch-v2 for this
submission.
Changes in v2:
- Update commit message for properly describe the problem and solution.
Link to v1:
https://lore.kernel.org/linux-usb/20260410064735.515-1-selvarasu.g@samsung.com/
Thanks,
Selva
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 161a4d58b2cec..0d3c7e7b2262f 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -1341,12 +1341,6 @@ int dwc3_core_init(struct dwc3 *dwc)
>
> hw_mode = DWC3_GHWPARAMS0_MODE(dwc->hwparams.hwparams0);
>
> - /*
> - * Write Linux Version Code to our GUID register so it's easy to figure
> - * out which kernel version a bug was found.
> - */
> - dwc3_writel(dwc, DWC3_GUID, LINUX_VERSION_CODE);
> -
> ret = dwc3_phy_setup(dwc);
> if (ret)
> return ret;
> @@ -1378,6 +1372,12 @@ int dwc3_core_init(struct dwc3 *dwc)
> if (ret)
> goto err_exit_phy;
>
> + /*
> + * Write Linux Version Code to our GUID register so it's easy to figure
> + * out which kernel version a bug was found.
> + */
> + dwc3_writel(dwc, DWC3_GUID, LINUX_VERSION_CODE);
> +
> dwc3_core_setup_global_control(dwc);
> dwc3_core_num_eps(dwc);
>
^ permalink raw reply
* Re: [PATCH] [SCSI] advansys: fix host resource leak in EISA probe error path
From: Hannes Reinecke @ 2026-04-17 6:56 UTC (permalink / raw)
To: Guangshuo Li
Cc: Matthew Wilcox, James E.J. Bottomley, Martin K. Petersen,
linux-scsi, linux-kernel, stable
In-Reply-To: <CANUHTR_qm94JQn-FKa9BfRgxadXKbXJmJEof6ZdE070=Xi4mGw@mail.gmail.com>
On 4/17/26 08:29, Guangshuo Li wrote:
> Hi Hannes,
>
> Thanks for the feedback.
>
> On Fri, 17 Apr 2026 at 13:56, Hannes Reinecke <hare@suse.com> wrote:
>>
>>
>> You must be kidding ... EISA is died over a decade ago.
>>
>> If you _really_ are concerned about this please remove EISA support
>> completely from the driver.
>>
>
> I agree that EISA is obsolete, and I understand that this path is
> unlikely to matter on modern systems. My intent was simply to clean up
> an inconsistency I noticed while reviewing the existing error handling
> code.
>
> If maintaining the EISA path is not worthwhile, I’m fine with dropping
> this patch. I can also take a look at what removing the EISA support
> would involve.
>
Please, drop the patch, and rather invest time to check how to drop
EISA support. Fixing issues for code paths which are never exercised
is a bit pointless.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@suse.com +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
^ permalink raw reply
* [PATCH v4 net] ax25: fix OOB read after address header strip in ax25_rcv()
From: Ashutosh Desai @ 2026-04-17 6:54 UTC (permalink / raw)
To: netdev
Cc: linux-hams, jreuter, davem, edumazet, kuba, pabeni, horms, stable,
linux-kernel, david.laight.linux, Ashutosh Desai
A crafted AX.25 frame with a valid address header but no control or PID
bytes causes skb->len to drop to zero after skb_pull() strips the
address header. The subsequent reads of skb->data[0] and skb->data[1]
are then out of bounds.
Linearize the skb at entry to ax25_rcv() so all subsequent accesses to
skb->data are safe. Then check skb->len before reading the control and
PID bytes, discarding frames that are too short.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Ashutosh Desai <ashutoshdesai993@gmail.com>
---
v4: linearize skb at entry to ax25_rcv(); replace pskb_may_pull() with
skb->len check
v3: remove incorrect Suggested-by; add symptom, Fixes, Cc stable
v2: use pskb_may_pull(skb, 2) instead of skb->len < 2
Link to v3: https://lore.kernel.org/netdev/20260415063654.3831353-1-ashutoshdesai993@gmail.com/
Link to v2: https://lore.kernel.org/netdev/20260409152400.2219716-1-ashutoshdesai993@gmail.com/
Link to v1: https://lore.kernel.org/netdev/20260409012235.2049389-1-ashutoshdesai993@gmail.com/
net/ax25/ax25_in.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/ax25/ax25_in.c b/net/ax25/ax25_in.c
index d75b3e9ed93d..d14ccebf9cdd 100644
--- a/net/ax25/ax25_in.c
+++ b/net/ax25/ax25_in.c
@@ -190,6 +190,9 @@ static int ax25_rcv(struct sk_buff *skb, struct net_device *dev,
ax25_cb *ax25;
ax25_dev *ax25_dev;
+ if (skb_linearize(skb))
+ goto free;
+
/*
* Process the AX.25/LAPB frame.
*/
@@ -217,6 +220,9 @@ static int ax25_rcv(struct sk_buff *skb, struct net_device *dev,
*/
skb_pull(skb, ax25_addr_size(&dp));
+ if (skb->len < 2)
+ goto free;
+
/* For our port addresses ? */
if (ax25cmp(&dest, dev_addr) == 0 && dp.lastrepeat + 1 == dp.ndigi)
mine = 1;
--
2.34.1
^ permalink raw reply related
* [PATCH v2] media: marvell-cam: fix missing pci_disable_device() on remove
From: Guangshuo Li @ 2026-04-17 6:53 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Guangshuo Li, Kees Cook, Hans Verkuil,
Jonathan Corbet, linux-media, linux-kernel
Cc: stable
During manual code audit, we found that cafe_pci_probe() enables the
PCI device with pci_enable_device(), and its probe error path properly
calls pci_disable_device() on failure.
However, cafe_pci_remove() tears down the controller and frees the
driver data without disabling the PCI device, leaving the remove path
inconsistent with probe cleanup.
Add the missing pci_disable_device() call to cafe_pci_remove().
Fixes: abfa3df36c01 ("[media] marvell-cam: Separate out the Marvell camera core")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
v2:
- Fix subject prefix to use "media:" as reported by CI
drivers/media/platform/marvell/cafe-driver.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/platform/marvell/cafe-driver.c b/drivers/media/platform/marvell/cafe-driver.c
index 632c15572aa8..22034df6cba9 100644
--- a/drivers/media/platform/marvell/cafe-driver.c
+++ b/drivers/media/platform/marvell/cafe-driver.c
@@ -609,6 +609,7 @@ static void cafe_pci_remove(struct pci_dev *pdev)
return;
}
cafe_shutdown(cam);
+ pci_disable_device(pdev);
kfree(cam);
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v6 0/5] staging: rtl8723bs: fix multiple security vulnerabilities
From: Dan Carpenter @ 2026-04-17 6:44 UTC (permalink / raw)
To: Delene Tchio Romuald
Cc: gregkh, luka.gejak, hansg, linux-staging, linux-kernel, stable
In-Reply-To: <20260417061048.62484-1-delenetchior1@gmail.com>
Thanks!
Reviewed-by: Dan Carpenter <error27@gmail.com>
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] usb: dwc3: Fix GUID register programming order
From: Selvarasu Ganesan @ 2026-04-17 6:39 UTC (permalink / raw)
To: Thinh Nguyen
Cc: gregkh@linuxfoundation.org, paulz@synopsys.com, balbi@ti.com,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
jh0801.jung@samsung.com, akash.m5@samsung.com,
h10.kim@samsung.com, alim.akhtar@samsung.com,
thiagu.r@samsung.com, muhammed.ali@samsung.com,
stable@vger.kernel.org, Pritam Manohar Sutar
In-Reply-To: <20260416222407.fk2wbjnrkgwsjj5i@synopsys.com>
On 4/17/2026 3:54 AM, Thinh Nguyen wrote:
> On Wed, Apr 15, 2026, Selvarasu Ganesan wrote:
>> On 4/15/2026 7:16 AM, Thinh Nguyen wrote:
>>> On Tue, Apr 14, 2026, Selvarasu Ganesan wrote:
>>>> On 4/14/2026 6:35 AM, Thinh Nguyen wrote:
>>>>> On Fri, Apr 10, 2026, Selvarasu Ganesan wrote:
>>>>>> The Linux Version Code is currently written to the GUID register before
>>>>>> dwc3_core_soft_reset() is executed. Since the core soft reset clears the
>>>>>> GUID register back to its default value, the version information is
>>>>>> subsequently lost.
>>>>> This is not right. Soft reset should not clear the GUID register.
>>>>> Something else must have cleared it. Did you assert Vcc reset (hard
>>>>> reset) during phy reset/initialization?
>>>>>
>>>>> BR,
>>>>> Thinh
>>>> Hi Thinh,
>>>>
>>>> Thank you for the clarification. Yes, you are correct, this issue is not
>>>> related to a dwc3 core soft reset. Instead, the GUID value reverts to
>>>> its default state when the PHY link_sw_reset completes during PHY init
>>>> sequence.
>>>>
>>>> We are using the Synopsys eUSB PHY, this reset is triggered from our
>>>> downstream driver during the PHY init sequence (invoked through
>>>> |dwc3_core_init|).
>>>>
>>>> Could you please suggest the best way to retrieve the correct linux
>>>> version information from the GUID?
>>>> Additionally, would it be feasible to update the GUID register after the
>>>> PHY init sequence (triggered by |dwc3_core_init|) completes?
>>>>
>>> Yes. Just fix up the changelog to properly describe the problem and
>>> solution.
>>>
>>> BR,
>>> Thinh
>> Hi Thinh,
>>
>> Thanks for the confirmation. I have modified the changelog as shown
>> below, please review it once then i will post updated patchset.
>>
>>
>> From: Selvarasu Ganesan <selvarasu.g@samsung.com>
>> Date: Thu, 9 Apr 2026 18:34:03 +0530
>> Subject: [PATCH v2] usb: dwc3: Move GUID programming after PHY
>> initialization
>>
>> The Linux Version Code is currently written to the GUID register before
>> PHY initialization. Certain PHY implementations (such as Synopsys eUSB
>> PHY performing link_sw_reset) clear the GUID register to its default
>> value during initialization, causing the kernel version information to
>> be lost.
>>
>> Move the GUID register programming to occur after PHY initialization
>> completes to ensure the Linux version information persists.
>>
>> Fixes: fa0ea13e9f1c ("usb: dwc3: core: write LINUX_VERSION_CODE to our
>> GUID register")
>> Cc: stable@vger.kernel.org
>> Reported-by: Pritam Manohar Sutar <pritam.sutar@samsung.com>
>> Signed-off-by: Selvarasu Ganesan <selvarasu.g@samsung.com>
>> ---
>> drivers/usb/dwc3/core.c | 12 ++++++------
>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>> index 161a4d58b2cec..8b9e9d3e9589a 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -1341,12 +1341,6 @@ int dwc3_core_init(struct dwc3 *dwc)
>>
>> hw_mode = DWC3_GHWPARAMS0_MODE(dwc->hwparams.hwparams0);
>>
>> - /*
>> - * Write Linux Version Code to our GUID register so it's easy to
>> figure
>> - * out which kernel version a bug was found.
>> - */
>> - dwc3_writel(dwc, DWC3_GUID, LINUX_VERSION_CODE);
>> -
>> ret = dwc3_phy_setup(dwc);
>> if (ret)
>> return ret;
>> @@ -1374,6 +1368,12 @@ int dwc3_core_init(struct dwc3 *dwc)
>> if (ret)
>> goto err_exit_ulpi;
>>
>> + /*
>> + * Write Linux Version Code to our GUID register so it's easy to
>> figure
>> + * out which kernel version a bug was found.
>> + */
>> + dwc3_writel(dwc, DWC3_GUID, LINUX_VERSION_CODE);
>> +
> In the really old kernel, the phy init was part of the
> dwc3_core_soft_reset(). Move this after dwc3_core_soft_reset() just as
> you had before. It will be better for backporting, and it looks more
> fitting to place it there.
Sure.
>
>> ret = dwc3_core_soft_reset(dwc);
>> if (ret)
>> goto err_exit_phy;
>
> The changelog looks good.
Ok. Thanks for the confirmation.
Thanks,
Selva
>
> Thanks,
> Thinh
^ permalink raw reply
* [PATCH 5.15.y] smb: client: fix potential UAF in smb2_is_valid_oplock_break()
From: Robert Garcia @ 2026-04-17 6:34 UTC (permalink / raw)
To: stable, Paulo Alcantara
Cc: Steve French, linux-cifs, samba-technical, Robert Garcia,
linux-kernel
From: Paulo Alcantara <pc@manguebit.com>
[ Upstream commit 22863485a4626ec6ecf297f4cc0aef709bc862e4 ]
Skip sessions that are being teared down (status == SES_EXITING) to
avoid UAF.
Cc: stable@vger.kernel.org
Signed-off-by: Paulo Alcantara (Red Hat) <pc@manguebit.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
[ Appropriate path used. ]
Signed-off-by: Robert Garcia <rob_garcia@163.com>
---
fs/cifs/smb2misc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/cifs/smb2misc.c b/fs/cifs/smb2misc.c
index b84e682b4cae..da32b3f6686b 100644
--- a/fs/cifs/smb2misc.c
+++ b/fs/cifs/smb2misc.c
@@ -679,6 +679,8 @@ smb2_is_valid_oplock_break(char *buffer, struct TCP_Server_Info *server)
/* look up tcon based on tid & uid */
spin_lock(&cifs_tcp_ses_lock);
list_for_each_entry(ses, &server->smb_ses_list, smb_ses_list) {
+ if (cifs_ses_exiting(ses))
+ continue;
list_for_each_entry(tcon, &ses->tcon_list, tcon_list) {
spin_lock(&tcon->open_file_lock);
--
2.34.1
^ permalink raw reply related
* [PATCH v2] usb: dwc3: Move GUID programming after PHY initialization
From: Selvarasu Ganesan @ 2026-04-17 6:33 UTC (permalink / raw)
To: Thinh.Nguyen, gregkh, paulz, balbi, linux-usb, linux-kernel
Cc: jh0801.jung, akash.m5, h10.kim, alim.akhtar, thiagu.r,
muhammed.ali, Selvarasu Ganesan, stable, Pritam Manohar Sutar
In-Reply-To: <CGME20260417063502epcas5p4f8f7fefb697e6d130ef7e9a78581ed84@epcas5p4.samsung.com>
The Linux Version Code is currently written to the GUID register before
PHY initialization. Certain PHY implementations (such as Synopsys eUSB
PHY performing link_sw_reset) clear the GUID register to its default
value during initialization, causing the kernel version information to
be lost.
Move the GUID register programming to occur after PHY initialization
completes to ensure the Linux version information persists.
Fixes: fa0ea13e9f1c ("usb: dwc3: core: write LINUX_VERSION_CODE to our GUID register")
Cc: stable@vger.kernel.org
Reported-by: Pritam Manohar Sutar <pritam.sutar@samsung.com>
Signed-off-by: Selvarasu Ganesan <selvarasu.g@samsung.com>
---
drivers/usb/dwc3/core.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 161a4d58b2cec..0d3c7e7b2262f 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1341,12 +1341,6 @@ int dwc3_core_init(struct dwc3 *dwc)
hw_mode = DWC3_GHWPARAMS0_MODE(dwc->hwparams.hwparams0);
- /*
- * Write Linux Version Code to our GUID register so it's easy to figure
- * out which kernel version a bug was found.
- */
- dwc3_writel(dwc, DWC3_GUID, LINUX_VERSION_CODE);
-
ret = dwc3_phy_setup(dwc);
if (ret)
return ret;
@@ -1378,6 +1372,12 @@ int dwc3_core_init(struct dwc3 *dwc)
if (ret)
goto err_exit_phy;
+ /*
+ * Write Linux Version Code to our GUID register so it's easy to figure
+ * out which kernel version a bug was found.
+ */
+ dwc3_writel(dwc, DWC3_GUID, LINUX_VERSION_CODE);
+
dwc3_core_setup_global_control(dwc);
dwc3_core_num_eps(dwc);
--
2.34.1
^ permalink raw reply related
* [PATCH 5.15.y] wifi: cfg80211: cancel rfkill_block work in wiphy_unregister()
From: Rajani Kantha @ 2026-04-17 6:30 UTC (permalink / raw)
To: d.dulov, johannes.berg, stable
From: Daniil Dulov <d.dulov@aladdin.ru>
commit 767d23ade706d5fa51c36168e92a9c5533c351a1 upstream.
There is a use-after-free error in cfg80211_shutdown_all_interfaces found
by syzkaller:
BUG: KASAN: use-after-free in cfg80211_shutdown_all_interfaces+0x213/0x220
Read of size 8 at addr ffff888112a78d98 by task kworker/0:5/5326
CPU: 0 UID: 0 PID: 5326 Comm: kworker/0:5 Not tainted 6.19.0-rc2 #2 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Workqueue: events cfg80211_rfkill_block_work
Call Trace:
<TASK>
dump_stack_lvl+0x116/0x1f0
print_report+0xcd/0x630
kasan_report+0xe0/0x110
cfg80211_shutdown_all_interfaces+0x213/0x220
cfg80211_rfkill_block_work+0x1e/0x30
process_one_work+0x9cf/0x1b70
worker_thread+0x6c8/0xf10
kthread+0x3c5/0x780
ret_from_fork+0x56d/0x700
ret_from_fork_asm+0x1a/0x30
</TASK>
The problem arises due to the rfkill_block work is not cancelled when wiphy
is being unregistered. In order to fix the issue cancel the corresponding
work in wiphy_unregister().
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Fixes: 1f87f7d3a3b4 ("cfg80211: add rfkill support")
Cc: stable@vger.kernel.org
Signed-off-by: Daniil Dulov <d.dulov@aladdin.ru>
Link: https://patch.msgid.link/20260211082024.1967588-1-d.dulov@aladdin.ru
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Rajani Kantha <681739313@139.com>
---
net/wireless/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 22e6fd12f201..7612b2725286 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -1105,6 +1105,7 @@ void wiphy_unregister(struct wiphy *wiphy)
cancel_work_sync(&rdev->wiphy_work);
flush_work(&rdev->scan_done_wk);
+ cancel_work_sync(&rdev->rfkill_block);
cancel_work_sync(&rdev->conn_work);
flush_work(&rdev->event_work);
cancel_delayed_work_sync(&rdev->dfs_update_channels_wk);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] [SCSI] advansys: fix host resource leak in EISA probe error path
From: Guangshuo Li @ 2026-04-17 6:29 UTC (permalink / raw)
To: Hannes Reinecke
Cc: Matthew Wilcox, James E.J. Bottomley, Martin K. Petersen,
James Bottomley, linux-scsi, linux-kernel, stable
In-Reply-To: <b1a6b96d-07d2-4a19-b9db-2cd8d878895c@suse.com>
Hi Hannes,
Thanks for the feedback.
On Fri, 17 Apr 2026 at 13:56, Hannes Reinecke <hare@suse.com> wrote:
>
>
> You must be kidding ... EISA is died over a decade ago.
>
> If you _really_ are concerned about this please remove EISA support
> completely from the driver.
>
I agree that EISA is obsolete, and I understand that this path is
unlikely to matter on modern systems. My intent was simply to clean up
an inconsistency I noticed while reviewing the existing error handling
code.
If maintaining the EISA path is not worthwhile, I’m fine with dropping
this patch. I can also take a look at what removing the EISA support
would involve.
Thanks,
Guangshuo
^ permalink raw reply
* Re: [PATCH 6.12 00/70] 6.12.82-rc1 review
From: Greg Kroah-Hartman @ 2026-04-17 6:25 UTC (permalink / raw)
To: Eddie Chapman
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: <172f1405-0094-4957-9758-e700ec76516f@ehuk.net>
On Thu, Apr 16, 2026 at 07:55:19PM +0100, Eddie Chapman wrote:
> On 13/04/2026 16:59, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 6.12.82 release.
> > There are 70 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, 15 Apr 2026 15:57:08 +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/v6.x/stable-review/patch-6.12.82-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-6.12.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> I just wanted to point out that the revert of "PCI: Enable ACS after
> configuring IOMMU for OF platforms" is missing here despite being queued in
> the 6.1 & 6.6 rcs (it is meant to be reverted from 6.12 as well). I noticed
> when updating to 6.12.82-rc1 today as I was bit by the regression (all my
> IOMMU groups messed up).
>
> The revert for 6.12 is in fact here:
> https://lore.kernel.org/stable/20260320172335.29778-1-john@kernel.doghat.io/
>
> but unfortunately easily missed as shown by the confusion here (same
> thread):
> https://lore.kernel.org/stable/99426bd8-32e5-4246-9d3b-772e136bc078@leemhuis.info/
>
> subsequently clarified by the patch author here (also same thread):
> https://lore.kernel.org/stable/5hng5r6q525scbclramuv2h2hphljbcsscwohvrs7teuedgfvl@ncr7tqhr4l4z/
>
> Other than that 6.12.82-rc1 boots and runs fine for me on the one AMD Ryzen
> system I've tried it on.
That was not obvious at all, please don't make us dig through email
threads to know what to and not to apply, it doesn't scale when dealing
with the email volume we get.
Can someone resend that patch, properly marked fro 6.12, so we know to
apply it there?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] [SCSI] advansys: fix host resource leak in EISA probe error path
From: Guangshuo Li @ 2026-04-17 6:25 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Hannes Reinecke, James E.J. Bottomley, Martin K. Petersen,
James Bottomley, linux-scsi, linux-kernel, stable
In-Reply-To: <aeEfqbaI6LNObJAC@casper.infradead.org>
Hi Matthew,
On Fri, 17 Apr 2026 at 01:43, Matthew Wilcox <willy@infradead.org> wrote:
>
> On Fri, Apr 17, 2026 at 12:59:35AM +0800, Guangshuo Li wrote:
> > A manual code audit found that advansys_eisa_probe() frees saved
> > Scsi_Host objects directly in its error path.
I understand the concern. This issue was found through my own manual
review of the error handling path in `advansys_eisa_probe()`.
Specifically, I first compared the error handling path in
`advansys_eisa_probe()` with the normal cleanup path in
`advansys_eisa_remove()`, and noticed that they release saved
`Scsi_Host` objects differently.
In `advansys_eisa_remove()`, each saved host is released through
`advansys_release(shost)`. Following that path shows that
`advansys_release()` eventually releases the SCSI host through
`scsi_host_put()`, which drops the embedded device reference and
invokes the SCSI host release callback, `scsi_host_dev_release()`,
when the reference count reaches zero.
That release callback does more than just `kfree(shost)`. It also
releases resources associated with the `Scsi_Host`, such as the host
IDA index, `shost_data`, and other host-side state managed by the SCSI
core.
However, the `free_data` path in `advansys_eisa_probe()` frees the
saved `data->host[]` entries directly with `kfree()`. My concern is
that this bypasses the `scsi_host_put()` / `scsi_host_dev_release()`
path and may therefore leak resources associated with the initialized
SCSI host.
That is why the patch changes the error path to release saved hosts
through `advansys_release(shost)` instead of directly freeing the
saved host pointers.
I also noticed that I accidentally removed the final `kfree(data)`
while preparing the patch. That was an unintended editing mistake, and
if the proposed cleanup approach is acceptable, I will fix it in v2.
> I've been told all your patches are AI slop, I'm not reviewing this.
If possible, could you please share what your assessment is based on?
Also, if there is any technical issue with this patch, I would
appreciate it if you could point it out concretely. I’m happy to
revise the patch if there is something incorrect in the analysis or in
the fix itself.
Thanks,
Guangshuo
^ permalink raw reply
* Re: [PATCH 1/4] drm/hibmc: Use drm_atomic_helper_check_plane_state()
From: Thomas Zimmermann @ 2026-04-17 6:17 UTC (permalink / raw)
To: Yongbang Shi, tiantao6, kong.kongxinwei, sumit.semwal,
yongqin.liu, jstultz, maarten.lankhorst, mripard, airlied, simona
Cc: dri-devel, Rongrong Zou, Sean Paul, Dmitry Baryshkov, stable,
Liangjian(Jim,Kunpeng Solution Development Dept), Chenjianmin,
fengsheng (A), helin (T)
In-Reply-To: <fffc172f-6bfe-4947-8f3b-52a1534b1d3b@huawei.com>
Hi
Am 16.04.26 um 15:22 schrieb Yongbang Shi:
[...]
> However, I believe the modified version is the better implementation,
> the plane check should be complete even if the CRTC is not enabled.
Great.
I agree that the logic in the helper is non-intuitive. I'll send you an
updated series with an improved commit message next week.
Best regards
Thomas
>
> [1]
> https://elixir.bootlin.com/linux/v7.0/source/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c#L84
> [2]
> https://elixir.bootlin.com/linux/v7.0/source/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c#L94
>
>
>>
>>>
>>>> + if (ret)
>>>> + return ret;
>>>> + else if (!new_plane_state->visible)
>>>> return 0;
>>>> - if (new_plane_state->crtc_x + new_plane_state->crtc_w >
>>>> - crtc_state->adjusted_mode.hdisplay ||
>>>> - new_plane_state->crtc_y + new_plane_state->crtc_h >
>>>> - crtc_state->adjusted_mode.vdisplay) {
>>>> - drm_dbg_atomic(plane->dev, "visible portion of plane is
>>>> invalid\n");
>>>> - return -EINVAL;
>>>> - }
>>>> -
>>> The purpose of this check is to ensure that the right and bottom
>>> boundaries of the plane do not extend beyond the crtc. In
>>> `drm_atomic_helper_check_plane_state`, `drm_mode_get_hv_timing` is
>>> called to retrieve the crtc boundaries, and `drm_rect_clip_scaled` is
>>> used to clip the plane, any portions extending beyond the right and
>>> bottom boundaries are discarded.
>>>
>>> I'd like to confirm that my understanding is correct? previously, the
>>> check failed if the plane exceeded the boundaries, but now, after
>>> `drm_atomic_helper_check_plane_state` is called, the plane is clipped to
>>> fit within the boundaries.
>> Yes. This sets plane_state->dst, which is clipped to the size of the
>> display mode. But it also tests that the primary plane covers the whole
>> display.
>>
>>> in function drm_rect_clip_scaled:
>>>
>>> diff = dst->x2 - clip->x2;
>>> if (diff > 0) {
>>> ...
>>> dst->x2 -= diff;
>>> }
>>> diff = dst->y2 - clip->y2;
>>> if (diff > 0) {
>>> ...
>>> dst->y2 -= diff;
>>> }
>> I agree, the logic in drm_atomic_helper_check_plane_state() is hard to
>> understand. It sets the clip rectangle to the size of the display mode
>> (or zero if the CRTC is off) at [1]. Then is clips the source and
>> destination coordinates against the clipping rectangle at [2].
>>
>> Because we set can_position to false, it tests if the destination and
>> clipping rectangles are equal at [3]. This is similar to the that is
>> being replaced, but with plane state correctly adjusted. If both
>> rectangles are equal, it returns success. If the destination is too
>> small, it fails with an errno code and a warning.
>>
>> If the plane is not visible, the helper already returned at [4].
>>
>> [1] https://elixir.bootlin.com/linux/v7.0/source/drivers/gpu/drm/
>> drm_atomic_helper.c#L943
>> [2] https://elixir.bootlin.com/linux/v7.0/source/drivers/gpu/drm/
>> drm_atomic_helper.c#L945
>> [3] https://elixir.bootlin.com/linux/v7.0/source/drivers/gpu/drm/
>> drm_atomic_helper.c#L959
>> [4] https://elixir.bootlin.com/linux/v7.0/source/drivers/gpu/drm/
>> drm_atomic_helper.c#L949
>>
>> It is now possible to have a primary plane that is larger than the
>> display mode. This is a feature of the DRM API.
>>
> Thank you so much for the explanation. It's much clearer to understand
> drm_atomic_helper_check_plane_state.
>
> By the way, we ran some basic tests on this set of patches using the
> latest BMC chip, and everything worked fine.
>
>
> Thanks.
>
> Best regards
> Yongbang.
>
>
>> Best regards
>> Thomas
>>
>>
>>>
>>> Thanks.
>>>
>>> Best regards
>>> Yongbang.
>>>
>>>
>>>> if (new_plane_state->fb->pitches[0] % 128 != 0) {
>>>> drm_dbg_atomic(plane->dev, "wrong stride with 128-byte
>>>> aligned\n");
>>>> return -EINVAL;
>>>> }
>>>> +
>>>> return 0;
>>>> }
>>>>
> Reviewed-by: Yongbang Shi <shiyongbang@huawei.com>
>
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* [PATCH v6 5/5] staging: rtl8723bs: fix negative length in WEP decryption
From: Delene Tchio Romuald @ 2026-04-17 6:10 UTC (permalink / raw)
To: gregkh
Cc: error27, luka.gejak, hansg, linux-staging, linux-kernel, stable,
Delene Tchio Romuald
In-Reply-To: <20260417061048.62484-1-delenetchior1@gmail.com>
In rtw_wep_decrypt(), the payload length is computed as:
length = frame->len - prxattrib->hdrlen - prxattrib->iv_len;
All operands are unsigned. If the frame is shorter than the sum of
the header length, IV length and the 4-byte ICV, this subtraction
wraps around or produces a value smaller than 4; the subsequent
crc32_le(~0, payload, length - 4) call then wraps length - 4 to a
huge value and reads past the end of the receive buffer.
An attacker within WiFi radio range can exploit this by sending a
crafted short WEP-encrypted frame. No authentication is required.
Validate that the frame is large enough to contain at least the
4-byte ICV on top of the header and IV before computing length.
Found by reviewing length arithmetic in the WEP decrypt path.
Not tested on hardware.
Fixes: 554c0a3abf216 ("staging: Add rtl8723bs sdio wifi driver")
Cc: stable@vger.kernel.org
Signed-off-by: Delene Tchio Romuald <delenetchior1@gmail.com>
---
v6: unchanged.
v5: tighten the length check to also cover the 4-byte ICV
so that the subsequent crc32_le(payload, length - 4)
call cannot underflow length - 4.
v4: add Fixes: tag and Cc: stable (Dan Carpenter).
v3: rebased on staging-next; sent as numbered series with
proper Cc from get_maintainer.pl.
v2: rebased on staging-next (v1 was based on v7.0-rc6 and
did not apply).
drivers/staging/rtl8723bs/core/rtw_security.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/staging/rtl8723bs/core/rtw_security.c b/drivers/staging/rtl8723bs/core/rtw_security.c
index a00504ff29109..ddd6ed2245035 100644
--- a/drivers/staging/rtl8723bs/core/rtw_security.c
+++ b/drivers/staging/rtl8723bs/core/rtw_security.c
@@ -113,6 +113,12 @@ void rtw_wep_decrypt(struct adapter *padapter, u8 *precvframe)
memcpy(&wepkey[0], iv, 3);
/* memcpy(&wepkey[3], &psecuritypriv->dot11DefKey[psecuritypriv->dot11PrivacyKeyIndex].skey[0], keylength); */
memcpy(&wepkey[3], &psecuritypriv->dot11DefKey[keyindex].skey[0], keylength);
+
+ /* Ensure the frame is long enough for WEP payload and ICV */
+ if (((union recv_frame *)precvframe)->u.hdr.len <
+ prxattrib->hdrlen + prxattrib->iv_len + 4)
+ return;
+
length = ((union recv_frame *)precvframe)->u.hdr.len - prxattrib->hdrlen - prxattrib->iv_len;
payload = pframe + prxattrib->iv_len + prxattrib->hdrlen;
--
2.43.0
^ permalink raw reply related
* [PATCH v6 4/5] staging: rtl8723bs: fix out-of-bounds reads in IE parsing functions
From: Delene Tchio Romuald @ 2026-04-17 6:10 UTC (permalink / raw)
To: gregkh
Cc: error27, luka.gejak, hansg, linux-staging, linux-kernel, stable,
Delene Tchio Romuald
In-Reply-To: <20260417061048.62484-1-delenetchior1@gmail.com>
rtw_get_wapi_ie(), rtw_get_sec_ie() and rtw_get_wps_ie() walk a
buffer of Information Elements using the TLV length field without
first verifying that the length byte itself is inside the buffer,
and without verifying that the specific bytes dereferenced by the
subsequent memcmp() calls fit inside the declared element.
An attacker within WiFi radio range can exploit this by sending
crafted beacon or probe-response frames carrying truncated or
oversized IEs. No authentication is required.
Ensure the length byte is inside the buffer (cnt + 1 < in_len),
break out of the loop if the declared element length would read
past in_len, and before each memcmp() verify that the offsets it
touches are inside the buffer: cnt + 10 for the WAPI OUI compared
at offset 6, and cnt + 6 for the WPA/WPS OUIs compared at offset 2.
Found by reviewing bounds checks in IE walkers.
Not tested on hardware.
Fixes: 554c0a3abf216 ("staging: Add rtl8723bs sdio wifi driver")
Cc: stable@vger.kernel.org
Signed-off-by: Delene Tchio Romuald <delenetchior1@gmail.com>
---
v6: unchanged.
v5: add an inner bound check before each memcmp() so that
the OUI read at offset 6 (WAPI) or offset 2 (WPA/WPS)
stays inside the declared element (Dan Carpenter).
v4: add Fixes: tag and Cc: stable (Dan Carpenter).
v3: rebased on staging-next; sent as numbered series with
proper Cc from get_maintainer.pl.
v2: rebased on staging-next (v1 was based on v7.0-rc6 and
did not apply).
.../staging/rtl8723bs/core/rtw_ieee80211.c | 70 +++++++++++++------
1 file changed, 47 insertions(+), 23 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
index 72b7f731dd471..1b61879acb48e 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
@@ -582,18 +582,25 @@ int rtw_get_wapi_ie(u8 *in_ie, uint in_len, u8 *wapi_ie, u16 *wapi_len)
cnt = (_TIMESTAMP_ + _BEACON_ITERVAL_ + _CAPABILITY_);
- while (cnt < in_len) {
+ while (cnt + 1 < in_len) {
authmode = in_ie[cnt];
- if (authmode == WLAN_EID_BSS_AC_ACCESS_DELAY &&
- (!memcmp(&in_ie[cnt + 6], wapi_oui1, 4) ||
- !memcmp(&in_ie[cnt + 6], wapi_oui2, 4))) {
- if (wapi_ie)
- memcpy(wapi_ie, &in_ie[cnt], in_ie[cnt + 1] + 2);
+ if (cnt + 2 + in_ie[cnt + 1] > in_len)
+ break;
+
+ if (authmode == WLAN_EID_BSS_AC_ACCESS_DELAY) {
+ if (cnt + 10 > in_len)
+ break;
- if (wapi_len)
- *wapi_len = in_ie[cnt + 1] + 2;
+ if (!memcmp(&in_ie[cnt + 6], wapi_oui1, 4) ||
+ !memcmp(&in_ie[cnt + 6], wapi_oui2, 4)) {
+ if (wapi_ie)
+ memcpy(wapi_ie, &in_ie[cnt],
+ in_ie[cnt + 1] + 2);
+ if (wapi_len)
+ *wapi_len = in_ie[cnt + 1] + 2;
+ }
}
cnt += in_ie[cnt + 1] + 2; /* get next */
@@ -615,15 +622,23 @@ void rtw_get_sec_ie(u8 *in_ie, uint in_len, u8 *rsn_ie, u16 *rsn_len, u8 *wpa_ie
cnt = (_TIMESTAMP_ + _BEACON_ITERVAL_ + _CAPABILITY_);
- while (cnt < in_len) {
+ while (cnt + 1 < in_len) {
authmode = in_ie[cnt];
- if ((authmode == WLAN_EID_VENDOR_SPECIFIC) &&
- (!memcmp(&in_ie[cnt + 2], &wpa_oui[0], 4))) {
- if (wpa_ie)
- memcpy(wpa_ie, &in_ie[cnt], in_ie[cnt + 1] + 2);
+ if (cnt + 2 + in_ie[cnt + 1] > in_len)
+ break;
+
+ if (authmode == WLAN_EID_VENDOR_SPECIFIC) {
+ if (cnt + 6 > in_len)
+ break;
+
+ if (!memcmp(&in_ie[cnt + 2], &wpa_oui[0], 4)) {
+ if (wpa_ie)
+ memcpy(wpa_ie, &in_ie[cnt],
+ in_ie[cnt + 1] + 2);
- *wpa_len = in_ie[cnt + 1] + 2;
+ *wpa_len = in_ie[cnt + 1] + 2;
+ }
} else if (authmode == WLAN_EID_RSN) {
if (rsn_ie)
memcpy(rsn_ie, &in_ie[cnt], in_ie[cnt + 1] + 2);
@@ -658,21 +673,30 @@ u8 *rtw_get_wps_ie(u8 *in_ie, uint in_len, u8 *wps_ie, uint *wps_ielen)
cnt = 0;
- while (cnt < in_len) {
+ while (cnt + 1 < in_len) {
eid = in_ie[cnt];
- if ((eid == WLAN_EID_VENDOR_SPECIFIC) && (!memcmp(&in_ie[cnt + 2], wps_oui, 4))) {
- wpsie_ptr = &in_ie[cnt];
+ if (cnt + 2 + in_ie[cnt + 1] > in_len)
+ break;
- if (wps_ie)
- memcpy(wps_ie, &in_ie[cnt], in_ie[cnt + 1] + 2);
+ if (eid == WLAN_EID_VENDOR_SPECIFIC) {
+ if (cnt + 6 > in_len)
+ break;
- if (wps_ielen)
- *wps_ielen = in_ie[cnt + 1] + 2;
+ if (!memcmp(&in_ie[cnt + 2], wps_oui, 4)) {
+ wpsie_ptr = &in_ie[cnt];
- cnt += in_ie[cnt + 1] + 2;
+ if (wps_ie)
+ memcpy(wps_ie, &in_ie[cnt],
+ in_ie[cnt + 1] + 2);
- break;
+ if (wps_ielen)
+ *wps_ielen = in_ie[cnt + 1] + 2;
+
+ cnt += in_ie[cnt + 1] + 2;
+
+ break;
+ }
}
cnt += in_ie[cnt + 1] + 2; /* goto next */
}
--
2.43.0
^ permalink raw reply related
* [PATCH v6 3/5] staging: rtl8723bs: fix out-of-bounds read in portctrl()
From: Delene Tchio Romuald @ 2026-04-17 6:10 UTC (permalink / raw)
To: gregkh
Cc: error27, luka.gejak, hansg, linux-staging, linux-kernel, stable,
Delene Tchio Romuald
In-Reply-To: <20260417061048.62484-1-delenetchior1@gmail.com>
In portctrl(), when 802.1X port control is enabled and a non-EAPOL
frame is received, the ether_type is read from the LLC header
without verifying that the frame actually contains enough bytes to
hold the MAC header, IV and the LLC header plus two bytes of
ether_type. For sufficiently short frames, the memcpy() that loads
be_tmp reads past the end of the receive buffer.
An attacker within WiFi radio range can exploit this by sending a
crafted short frame. No authentication is required.
Validate the frame length before dereferencing the LLC header; drop
the frame if it is too short.
Found by reviewing length validation in the receive path.
Not tested on hardware.
Fixes: 554c0a3abf216 ("staging: Add rtl8723bs sdio wifi driver")
Cc: stable@vger.kernel.org
Signed-off-by: Delene Tchio Romuald <delenetchior1@gmail.com>
---
v6: drop the unrelated cleanups (ptr = ptr + X -> ptr += X,
ether_type inversion into direct return NULL); the patch
now only adds the short-frame length check before
dereferencing the LLC header (Dan Carpenter).
v5: return NULL directly on the short-frame and non-EAPOL
error paths (Dan Carpenter).
v4: add Fixes: tag and Cc: stable (Dan Carpenter).
v3: rebased on staging-next; sent as numbered series with
proper Cc from get_maintainer.pl.
v2: rebased on staging-next (v1 was based on v7.0-rc6 and
did not apply).
drivers/staging/rtl8723bs/core/rtw_recv.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/staging/rtl8723bs/core/rtw_recv.c b/drivers/staging/rtl8723bs/core/rtw_recv.c
index e30617875a69d..b476f7a03a234 100644
--- a/drivers/staging/rtl8723bs/core/rtw_recv.c
+++ b/drivers/staging/rtl8723bs/core/rtw_recv.c
@@ -539,6 +539,14 @@ static union recv_frame *portctrl(struct adapter *adapter, union recv_frame *pre
prtnframe = precv_frame;
+ /* Ensure frame has LLC header and ether_type */
+ if (pfhdr->len < pattrib->hdrlen +
+ pattrib->iv_len + LLC_HEADER_LENGTH + 2) {
+ rtw_free_recvframe(precv_frame,
+ &adapter->recvpriv.free_recv_queue);
+ return NULL;
+ }
+
/* get ether_type */
ptr = ptr + pfhdr->attrib.hdrlen + pfhdr->attrib.iv_len + LLC_HEADER_LENGTH;
memcpy(&be_tmp, ptr, 2);
--
2.43.0
^ permalink raw reply related
* [PATCH v6 2/5] staging: rtl8723bs: fix integer underflow in TKIP MIC verification
From: Delene Tchio Romuald @ 2026-04-17 6:10 UTC (permalink / raw)
To: gregkh
Cc: error27, luka.gejak, hansg, linux-staging, linux-kernel, stable,
Delene Tchio Romuald
In-Reply-To: <20260417061048.62484-1-delenetchior1@gmail.com>
In recvframe_chkmic(), the payload length is computed as:
datalen = precvframe->u.hdr.len - prxattrib->hdrlen
- prxattrib->iv_len - prxattrib->icv_len - 8;
All operands are unsigned. If the receive frame is shorter than the
sum of the header, IV, ICV and MIC sizes, this subtraction wraps
around and datalen becomes a huge unsigned value. That value is then
passed to rtw_secmicappend(), which reads past the end of the
receive buffer and can leak kernel memory or trigger a crash.
An attacker within WiFi radio range can exploit this by sending a
crafted short TKIP-encrypted frame. No authentication is required.
Validate that the frame is large enough for the TKIP MIC
computation before the subtraction.
Found by reviewing length arithmetic in the TKIP receive path.
Not tested on hardware.
Fixes: 554c0a3abf216 ("staging: Add rtl8723bs sdio wifi driver")
Cc: stable@vger.kernel.org
Reviewed-by: Luka Gejak <luka.gejak@linux.dev>
Signed-off-by: Delene Tchio Romuald <delenetchior1@gmail.com>
---
v6: unchanged.
v5: unchanged.
v4: add Fixes: tag and Cc: stable (Dan Carpenter); carry
Luka Gejak's Reviewed-by.
v3: rebased on staging-next; sent as numbered series with
proper Cc from get_maintainer.pl.
v2: rebased on staging-next (v1 was based on v7.0-rc6 and
did not apply).
drivers/staging/rtl8723bs/core/rtw_recv.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/staging/rtl8723bs/core/rtw_recv.c b/drivers/staging/rtl8723bs/core/rtw_recv.c
index 8d5d9a6dc4db0..e30617875a69d 100644
--- a/drivers/staging/rtl8723bs/core/rtw_recv.c
+++ b/drivers/staging/rtl8723bs/core/rtw_recv.c
@@ -390,6 +390,13 @@ static signed int recvframe_chkmic(struct adapter *adapter, union recv_frame *p
mickey = &stainfo->dot11tkiprxmickey.skey[0];
}
+ /* Ensure the frame is large enough for TKIP MIC verification */
+ if (precvframe->u.hdr.len <= prxattrib->hdrlen +
+ prxattrib->iv_len + prxattrib->icv_len + 8) {
+ res = _FAIL;
+ goto exit;
+ }
+
datalen = precvframe->u.hdr.len - prxattrib->hdrlen - prxattrib->iv_len - prxattrib->icv_len - 8;/* icv_len included the mic code */
pframe = precvframe->u.hdr.rx_data;
payload = pframe + prxattrib->hdrlen + prxattrib->iv_len;
--
2.43.0
^ permalink raw reply related
* [PATCH v6 1/5] staging: rtl8723bs: fix heap buffer overflow in recvframe_defrag()
From: Delene Tchio Romuald @ 2026-04-17 6:10 UTC (permalink / raw)
To: gregkh
Cc: error27, luka.gejak, hansg, linux-staging, linux-kernel, stable,
Delene Tchio Romuald
In-Reply-To: <20260417061048.62484-1-delenetchior1@gmail.com>
In recvframe_defrag(), a memcpy() copies fragment data into the
reassembly buffer before validating that the buffer has sufficient
space. If the total reassembled payload exceeds the receive buffer
capacity, this results in a heap buffer overflow.
Additionally, the return values of recvframe_pull() and
recvframe_pull_tail() were ignored. On failure those helpers revert
their pointer updates and return NULL; continuing past such a
failure would leave pfhdr->rx_tail at its pre-strip value, so the
subsequent bounds check against rx_end - rx_tail would operate on
stale pointers.
An attacker within WiFi radio range can exploit this by sending
crafted 802.11 fragmented frames. No authentication is required.
Check the return values of recvframe_pull() and recvframe_pull_tail(),
then verify that the fragment payload fits within the remaining
buffer space before the memcpy(). Consolidate the five cleanup
paths through a single out_err label.
Found by reviewing memory operations in the driver and tracing
buffer pointer manipulation through rtw_recv.h inline helpers.
Not tested on hardware.
Fixes: 554c0a3abf216 ("staging: Add rtl8723bs sdio wifi driver")
Cc: stable@vger.kernel.org
Signed-off-by: Delene Tchio Romuald <delenetchior1@gmail.com>
---
v6: restore the '/* memcpy */' comment that v5 had removed
as drive-by cleanup (Dan Carpenter).
v5: collapse the identical cleanup sites into a single
out_err label (Dan Carpenter).
v4: check return values of recvframe_pull() and
recvframe_pull_tail(); drop unnecessary (uint) cast;
add Fixes: tag and Cc: stable (Dan Carpenter).
v3: rebased on staging-next; sent as numbered series with
proper Cc from get_maintainer.pl.
v2: rebased on staging-next (v1 was based on v7.0-rc6 and
did not apply).
drivers/staging/rtl8723bs/core/rtw_recv.c | 36 ++++++++++++-----------
1 file changed, 19 insertions(+), 17 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_recv.c b/drivers/staging/rtl8723bs/core/rtw_recv.c
index f78194d508dfc..8d5d9a6dc4db0 100644
--- a/drivers/staging/rtl8723bs/core/rtw_recv.c
+++ b/drivers/staging/rtl8723bs/core/rtw_recv.c
@@ -1090,14 +1090,9 @@ static union recv_frame *recvframe_defrag(struct adapter *adapter,
pfhdr = &prframe->u.hdr;
list_del_init(&(prframe->u.list));
- if (curfragnum != pfhdr->attrib.frag_num) {
- /* the first fragment number must be 0 */
- /* free the whole queue */
- rtw_free_recvframe(prframe, pfree_recv_queue);
- rtw_free_recvframe_queue(defrag_q, pfree_recv_queue);
-
- return NULL;
- }
+ /* the first fragment number must be 0 */
+ if (curfragnum != pfhdr->attrib.frag_num)
+ goto out_err;
curfragnum++;
@@ -1112,13 +1107,9 @@ static union recv_frame *recvframe_defrag(struct adapter *adapter,
/* check the fragment sequence (2nd ~n fragment frame) */
- if (curfragnum != pnfhdr->attrib.frag_num) {
- /* the fragment number must be increasing (after decache) */
- /* release the defrag_q & prframe */
- rtw_free_recvframe(prframe, pfree_recv_queue);
- rtw_free_recvframe_queue(defrag_q, pfree_recv_queue);
- return NULL;
- }
+ /* the fragment number must be increasing (after decache) */
+ if (curfragnum != pnfhdr->attrib.frag_num)
+ goto out_err;
curfragnum++;
@@ -1127,10 +1118,16 @@ static union recv_frame *recvframe_defrag(struct adapter *adapter,
wlanhdr_offset = pnfhdr->attrib.hdrlen + pnfhdr->attrib.iv_len;
- recvframe_pull(pnextrframe, wlanhdr_offset);
+ if (!recvframe_pull(pnextrframe, wlanhdr_offset))
+ goto out_err;
/* append to first fragment frame's tail (if privacy frame, pull the ICV) */
- recvframe_pull_tail(prframe, pfhdr->attrib.icv_len);
+ if (!recvframe_pull_tail(prframe, pfhdr->attrib.icv_len))
+ goto out_err;
+
+ /* Verify the receiving buffer has enough space for the fragment */
+ if (pnfhdr->len > pfhdr->rx_end - pfhdr->rx_tail)
+ goto out_err;
/* memcpy */
memcpy(pfhdr->rx_tail, pnfhdr->rx_data, pnfhdr->len);
@@ -1146,6 +1143,11 @@ static union recv_frame *recvframe_defrag(struct adapter *adapter,
rtw_free_recvframe_queue(defrag_q, pfree_recv_queue);
return prframe;
+
+out_err:
+ rtw_free_recvframe(prframe, pfree_recv_queue);
+ rtw_free_recvframe_queue(defrag_q, pfree_recv_queue);
+ return NULL;
}
/* check if need to defrag, if needed queue the frame to defrag_q */
--
2.43.0
^ permalink raw reply related
* [PATCH v6 0/5] staging: rtl8723bs: fix multiple security vulnerabilities
From: Delene Tchio Romuald @ 2026-04-17 6:10 UTC (permalink / raw)
To: gregkh
Cc: error27, luka.gejak, hansg, linux-staging, linux-kernel, stable,
Delene Tchio Romuald
This series fixes five remotely-triggerable memory safety issues in
the rtl8723bs driver. All of them are reachable from the air by an
attacker within WiFi radio range, without authentication, via
crafted management or data frames:
1. Heap buffer overflow in recvframe_defrag() when reassembling
fragmented frames whose total payload exceeds the receive
buffer capacity.
2. Integer underflow in TKIP MIC verification when a frame is
shorter than the sum of header, IV, ICV and MIC sizes.
3. Out-of-bounds read in portctrl() when a non-EAPOL frame is
shorter than the 802.11 header + IV + LLC + ether_type.
4. Out-of-bounds reads in three IE walkers (rtw_get_wapi_ie(),
rtw_get_sec_ie(), rtw_get_wps_ie()) due to missing validation
of the TLV length byte and of the byte ranges touched by the
subsequent memcmp() calls.
5. Integer underflow in rtw_wep_decrypt() when a WEP frame is
shorter than the header + IV + ICV.
Each patch was found by code review and is not tested on hardware.
Changes since v5:
- Patch 1/5: restore the "/* memcpy */" comment that v5 had
removed as drive-by cleanup (Dan Carpenter).
- Patch 3/5: drop the unrelated cleanups (ptr = ptr + X -> ptr +=
X, inversion of the ether_type == eapol_type branch into
direct return NULL); the patch now only adds the short-frame
length check before dereferencing the LLC header (Dan
Carpenter).
- Patches 2/5, 4/5 and 5/5 are unchanged.
Changes since v4:
- Patch 1/5: collapse the identical cleanup sites in
recvframe_defrag() into a single out_err label (Dan Carpenter).
- Patch 4/5: in addition to the outer TLV length check, add an
inner bound check before each memcmp() so that the OUI read at
offset 6 (WAPI) or offset 2 (WPA/WPS) stays inside the declared
element (Dan Carpenter).
- Patch 5/5: tighten the length check to also cover the 4-byte
ICV, so that the subsequent crc32_le(payload, length - 4) call
cannot underflow length - 4.
Changes since v3:
- All patches: add Fixes: tag pointing at the driver import and
add Cc: stable per Dan Carpenter.
Changes since v2:
- Sent as numbered series with cover letter.
Changes since v1:
- Rebased on staging-next.
Delene Tchio Romuald (5):
staging: rtl8723bs: fix heap buffer overflow in recvframe_defrag()
staging: rtl8723bs: fix integer underflow in TKIP MIC verification
staging: rtl8723bs: fix out-of-bounds read in portctrl()
staging: rtl8723bs: fix out-of-bounds reads in IE parsing functions
staging: rtl8723bs: fix negative length in WEP decryption
.../staging/rtl8723bs/core/rtw_ieee80211.c | 70 +++++++++++++------
drivers/staging/rtl8723bs/core/rtw_recv.c | 51 +++++++++-----
drivers/staging/rtl8723bs/core/rtw_security.c | 6 ++
3 files changed, 87 insertions(+), 40 deletions(-)
base-commit: bf9c95f3eeefb7fc4b4a6380cc23f1dca744e379
--
2.43.0
^ permalink raw reply
* [PATCH v10 2/2] drm/xe: Reject coh_none PAT index for CPU_ADDR_MIRROR
From: Jia Yao @ 2026-04-17 5:59 UTC (permalink / raw)
To: intel-xe
Cc: Jia Yao, stable, Shuicheng Lin, Mathew Alwin, Michal Mrozek,
Matthew Brost, Matthew Auld
In-Reply-To: <20260417055917.2027459-1-jia.yao@intel.com>
Add validation in xe_vm_bind_ioctl() to reject PAT indices
with XE_COH_NONE coherency mode when used with
DRM_XE_VM_BIND_FLAG_CPU_ADDR_MIRROR.
CPU address mirror mappings use system memory that is CPU
cached, which makes them incompatible with COH_NONE PAT
indices. Allowing COH_NONE with CPU cached buffers is a
security risk, as the GPU may bypass CPU caches and read
stale sensitive data from DRAM.
Although CPU_ADDR_MIRROR does not create an immediate
mapping, the backing system memory is still CPU cached.
Apply the same PAT coherency restrictions as
DRM_XE_VM_BIND_OP_MAP_USERPTR.
v2:
- Correct fix tag
v6:
- No change
v7:
- Correct fix tag
v8:
- Rebase
v9:
- Limit the restrictions to iGPU
v10:
- Just add the iGPU logic but keep dGPU logic
Fixes: b43e864af0d4 ("drm/xe/uapi: Add DRM_XE_VM_BIND_FLAG_CPU_ADDR_MIRROR")
Cc: stable@vger.kernel.org # v6.18
Cc: Shuicheng Lin <shuicheng.lin@intel.com>
Cc: Mathew Alwin <alwin.mathew@intel.com>
Cc: Michal Mrozek <michal.mrozek@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Jia Yao <jia.yao@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
---
drivers/gpu/drm/xe/xe_vm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c
index 2408b547ca3d..1481dd53775d 100644
--- a/drivers/gpu/drm/xe/xe_vm.c
+++ b/drivers/gpu/drm/xe/xe_vm.c
@@ -3658,6 +3658,8 @@ static int vm_bind_ioctl_check_args(struct xe_device *xe, struct xe_vm *vm,
op == DRM_XE_VM_BIND_OP_MAP_USERPTR) ||
XE_IOCTL_DBG(xe, coh_mode == XE_COH_NONE &&
op == DRM_XE_VM_BIND_OP_MAP_USERPTR) ||
+ XE_IOCTL_DBG(xe, !IS_DGFX(xe) && coh_mode == XE_COH_NONE &&
+ is_cpu_addr_mirror) ||
XE_IOCTL_DBG(xe, xe_device_is_l2_flush_optimized(xe) &&
(op == DRM_XE_VM_BIND_OP_MAP_USERPTR ||
is_cpu_addr_mirror) &&
--
2.43.0
^ permalink raw reply related
* [PATCH v10 1/2] drm/xe/uapi: Reject coh_none PAT index for CPU cached memory in madvise
From: Jia Yao @ 2026-04-17 5:59 UTC (permalink / raw)
To: intel-xe
Cc: Jia Yao, stable, Shuicheng Lin, Mathew Alwin, Michal Mrozek,
Matthew Brost, Matthew Auld, José Roberto de Souza
In-Reply-To: <20260417055917.2027459-1-jia.yao@intel.com>
Add validation in xe_vm_madvise_ioctl() to reject PAT indices with
XE_COH_NONE coherency mode when applied to CPU cached memory.
Using coh_none with CPU cached buffers is a security issue. When the
kernel clears pages before reallocation, the clear operation stays in
CPU cache (dirty). GPU with coh_none can bypass CPU caches and read
stale sensitive data directly from DRAM, potentially leaking data from
previously freed pages of other processes.
This aligns with the existing validation in vm_bind path
(xe_vm_bind_ioctl_validate_bo).
v2(Matthew brost)
- Add fixes
- Move one debug print to better place
v3(Matthew Auld)
- Should be drm/xe/uapi
- More Cc
v4(Shuicheng Lin)
- Fix kmem leak issues by the way
v5
- Remove kmem leak because it has been merged by another patch
v6
- Remove the fix which is not related to current fix
v7
- No change
v8
- Rebase
v9
- Limit the restrictions to iGPU
v10
- No change
Fixes: ada7486c5668 ("drm/xe: Implement madvise ioctl for xe")
Cc: stable@vger.kernel.org # v6.18
Cc: Shuicheng Lin <shuicheng.lin@intel.com>
Cc: Mathew Alwin <alwin.mathew@intel.com>
Cc: Michal Mrozek <michal.mrozek@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Jia Yao <jia.yao@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Acked-by: Michal Mrozek <michal.mrozek@intel.com>
Acked-by: José Roberto de Souza <jose.souza@intel.com>
---
drivers/gpu/drm/xe/xe_vm_madvise.c | 47 ++++++++++++++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/xe/xe_vm_madvise.c b/drivers/gpu/drm/xe/xe_vm_madvise.c
index 66f00d3f5c07..c78906dea82b 100644
--- a/drivers/gpu/drm/xe/xe_vm_madvise.c
+++ b/drivers/gpu/drm/xe/xe_vm_madvise.c
@@ -621,6 +621,45 @@ static int xe_madvise_purgeable_retained_to_user(const struct xe_madvise_details
return 0;
}
+static bool check_pat_args_are_sane(struct xe_device *xe,
+ struct xe_vmas_in_madvise_range *madvise_range,
+ u16 pat_index)
+{
+ u16 coh_mode = xe_pat_index_get_coh_mode(xe, pat_index);
+ int i;
+
+ /*
+ * Using coh_none with CPU cached buffers is not allowed on iGPU.
+ * On iGPU the GPU shares the LLC with the CPU, so with coh_none
+ * the GPU bypasses CPU caches and reads directly from DRAM,
+ * potentially seeing stale sensitive data from previously freed
+ * pages. On dGPU this restriction does not apply, because the
+ * platform does not provide a non-coherent system memory access
+ * path that would violate the DMA coherency contract.
+ */
+ if (coh_mode != XE_COH_NONE || IS_DGFX(xe))
+ return true;
+
+ for (i = 0; i < madvise_range->num_vmas; i++) {
+ struct xe_vma *vma = madvise_range->vmas[i];
+ struct xe_bo *bo = xe_vma_bo(vma);
+
+ if (bo) {
+ /* BO with WB caching + COH_NONE is not allowed */
+ if (XE_IOCTL_DBG(xe, bo->cpu_caching == DRM_XE_GEM_CPU_CACHING_WB))
+ return false;
+ /* Imported dma-buf without caching info, assume cached */
+ if (XE_IOCTL_DBG(xe, !bo->cpu_caching))
+ return false;
+ } else if (XE_IOCTL_DBG(xe, xe_vma_is_cpu_addr_mirror(vma) ||
+ xe_vma_is_userptr(vma)))
+ /* System memory (userptr/SVM) is always CPU cached */
+ return false;
+ }
+
+ return true;
+}
+
static bool check_bo_args_are_sane(struct xe_vm *vm, struct xe_vma **vmas,
int num_vmas, u32 atomic_val)
{
@@ -750,6 +789,14 @@ int xe_vm_madvise_ioctl(struct drm_device *dev, void *data, struct drm_file *fil
}
}
+ if (args->type == DRM_XE_MEM_RANGE_ATTR_PAT) {
+ if (!check_pat_args_are_sane(xe, &madvise_range,
+ args->pat_index.val)) {
+ err = -EINVAL;
+ goto free_vmas;
+ }
+ }
+
if (madvise_range.has_bo_vmas) {
if (args->type == DRM_XE_MEM_RANGE_ATTR_ATOMIC) {
if (!check_bo_args_are_sane(vm, madvise_range.vmas,
--
2.43.0
^ permalink raw reply related
* [PATCH v8 0/2] drm/xe: Reject unsafe PAT indices for CPU cached memory
From: Jia Yao @ 2026-04-17 5:59 UTC (permalink / raw)
To: intel-xe
Cc: Jia Yao, stable, Shuicheng Lin, Mathew Alwin, Michal Mrozek,
Matthew Brost, Matthew Auld
This series strengthens PAT index validation to reject unsafe
configurations for CPU cached memory, preventing cases where the GPU
may bypass CPU caches and observe stale or sensitive data.
Patch 1 enforces PAT validation for the madvise ioctl path, ensuring
XE_COH_NONE cannot be used on CPU cached buffers, including CPU address
mirror and userptr-backed memory.
Patch 2 applies the same validation to vm_bind, treating
DRM_XE_VM_BIND_FLAG_CPU_ADDR_MIRROR the same as MAP_USERPTR with respect
to permissible PAT indices.
Together, these patches close a security gap affecting CPU cached
memory access when incoherent PAT values are used.
Changes since v10:
- Just add the iGPU logic but keep dGPU logic
Changes since v7:
- Rebased onto latest drm/xe tree, no functional changes.
Changes since v6:
- Corrected Fixes tags.
Fixes: ada7486c5668 ("drm/xe: Implement madvise ioctl for xe")
Fixes: b43e864af0d4 ("drm/xe/uapi: Add DRM_XE_VM_BIND_FLAG_CPU_ADDR_MIRROR")
Cc: stable@vger.kernel.org # v6.18
Cc: Shuicheng Lin <shuicheng.lin@intel.com>
Cc: Mathew Alwin <alwin.mathew@intel.com>
Cc: Michal Mrozek <michal.mrozek@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Jia Yao (2):
drm/xe/uapi: Reject coh_none PAT index for CPU cached memory in
madvise
drm/xe: Reject coh_none PAT index for CPU_ADDR_MIRROR
drivers/gpu/drm/xe/xe_vm.c | 2 +-
drivers/gpu/drm/xe/xe_vm_madvise.c | 45 ++++++++++++++++++++++++++++++
2 files changed, 46 insertions(+), 1 deletion(-)
--
2.43.0
^ permalink raw reply
* + kho-fix-error-handling-in-kho_add_subtree.patch added to mm-unstable branch
From: Andrew Morton @ 2026-04-17 5:57 UTC (permalink / raw)
To: mm-commits, stable, rppt, pratyush, pasha.tatashin, graf, leitao,
akpm
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4961 bytes --]
The patch titled
Subject: kho: fix error handling in kho_add_subtree()
has been added to the -mm mm-unstable branch. Its filename is
kho-fix-error-handling-in-kho_add_subtree.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/kho-fix-error-handling-in-kho_add_subtree.patch
This patch will later appear in the mm-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via various
branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there most days
------------------------------------------------------
From: Breno Leitao <leitao@debian.org>
Subject: kho: fix error handling in kho_add_subtree()
Date: Fri, 10 Apr 2026 02:03:03 -0700
Fix two error handling issues in kho_add_subtree(), where it doesn't
handle the error path correctly.
1. If fdt_setprop() fails after the subnode has been created, the
subnode is not removed. This leaves an incomplete node in the FDT
(missing "preserved-data" or "blob-size" properties).
2. The fdt_setprop() return value (an FDT error code) is stored
directly in err and returned to the caller, which expects -errno.
Fix both by storing fdt_setprop() results in fdt_err, jumping to a new
out_del_node label that removes the subnode on failure, and only setting
err = 0 on the success path, otherwise returning -ENOMEM (instead of
FDT_ERR_ errors that would come from fdt_setprop).
No user-visible changes. This patch fixes error handling in the KHO
(Kexec HandOver) subsystem, which is used to preserve data across kexec
reboots. The fix only affects a rare failure path during kexec
preparation — specifically when the kernel runs out of space in the
Flattened Device Tree buffer while registering preserved memory regions.
In the unlikely event that this error path was triggered, the old code
would leave a malformed node in the device tree and return an incorrect
error code to the calling subsystem, which could lead to confusing log
messages or incorrect recovery decisions. With this fix, the incomplete
node is properly cleaned up and the appropriate errno value is propagated,
this error code is not returned to the user.
Link: https://lore.kernel.org/20260410-kho_fix_send-v2-1-1b4debf7ee08@debian.org
Fixes: 3dc92c311498 ("kexec: add Kexec HandOver (KHO) generation helpers")
Signed-off-by: Breno Leitao <leitao@debian.org>
Suggested-by: Pratyush Yadav <pratyush@kernel.org>
Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
Cc: Alexander Graf <graf@amazon.com>
Cc: Breno Leitao <leitao@debian.org>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
kernel/liveupdate/kexec_handover.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
--- a/kernel/liveupdate/kexec_handover.c~kho-fix-error-handling-in-kho_add_subtree
+++ a/kernel/liveupdate/kexec_handover.c
@@ -762,19 +762,24 @@ int kho_add_subtree(const char *name, vo
goto out_pack;
}
- err = fdt_setprop(root_fdt, off, KHO_SUB_TREE_PROP_NAME,
- &phys, sizeof(phys));
- if (err < 0)
- goto out_pack;
+ fdt_err = fdt_setprop(root_fdt, off, KHO_SUB_TREE_PROP_NAME,
+ &phys, sizeof(phys));
+ if (fdt_err < 0)
+ goto out_del_node;
- err = fdt_setprop(root_fdt, off, KHO_SUB_TREE_SIZE_PROP_NAME,
- &size_u64, sizeof(size_u64));
- if (err < 0)
- goto out_pack;
+ fdt_err = fdt_setprop(root_fdt, off, KHO_SUB_TREE_SIZE_PROP_NAME,
+ &size_u64, sizeof(size_u64));
+ if (fdt_err < 0)
+ goto out_del_node;
WARN_ON_ONCE(kho_debugfs_blob_add(&kho_out.dbg, name, blob,
size, false));
+ err = 0;
+ goto out_pack;
+
+out_del_node:
+ fdt_del_node(root_fdt, off);
out_pack:
fdt_pack(root_fdt);
_
Patches currently in -mm which might be from leitao@debian.org are
mm-blk-cgroup-fix-use-after-free-in-cgwb_release_workfn.patch
mm-kmemleak-add-config_debug_kmemleak_verbose-build-option.patch
kho-add-size-parameter-to-kho_add_subtree.patch
kho-rename-fdt-parameter-to-blob-in-kho_add-remove_subtree.patch
kho-persist-blob-size-in-kho-fdt.patch
kho-fix-kho_in_debugfs_init-to-handle-non-fdt-blobs.patch
kho-kexec-metadata-track-previous-kernel-chain.patch
kho-document-kexec-metadata-tracking-feature.patch
mm-vmstat-fix-vmstat_shepherd-double-scheduling-vmstat_update.patch
kho-fix-error-handling-in-kho_add_subtree.patch
mm-vmstat-spread-vmstat_update-requeue-across-the-stat-interval.patch
^ 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