* Re: [PATCH] ALSA: caiaq: Fix control_put() result and cache rollback
From: Takashi Iwai @ 2026-04-17 15:52 UTC (permalink / raw)
To: Cássio Gabriel
Cc: Takashi Iwai, Daniel Mack, Jaroslav Kysela, Daniel Mack,
linux-sound, linux-kernel, stable
In-Reply-To: <20260417-caiaq-control-put-v1-1-c37826e92447@gmail.com>
On Fri, 17 Apr 2026 15:41:33 +0200,
Cássio Gabriel wrote:
>
> control_put() always returns 1 and updates cdev->control_state[]
> before sending the USB command. It also ignores transport errors
> from usb_bulk_msg(), snd_usb_caiaq_send_command(), and
> snd_usb_caiaq_send_command_bank().
>
> That breaks the ALSA .put() contract and can leave control_get()
> reporting a cached value the device never accepted.
>
> Return 0 for unchanged values, propagate transport failures,
> and restore the cached byte when the write fails.
>
> Fixes: 8e3cd08ed8e59 ("[ALSA] caiaq - add control API and more input features")
> Cc: stable@vger.kernel.org
> Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Applied now. Thanks.
Takashi
^ permalink raw reply
* [PATCH] HID: playstation: Clamp num_touch_reports
From: T.J. Mercier @ 2026-04-17 15:47 UTC (permalink / raw)
To: roderick.colenbrander, linux-input, Jiri Kosina,
Benjamin Tissoires
Cc: T.J. Mercier, stable, Xingyu Jin, Roderick Colenbrander,
linux-kernel
A device would never lie about the number of touch reports would it?
If it does the loop in dualshock4_parse_report will read off the end of
the touch_reports array, up to about 2 KiB for the maximum number of 256
loop iteraions. The data that is read is emitted via evdev if the
DS4_TOUCH_POINT_INACTIVE bit happens to be set. Protect against this by
clamping the num_touch_reports value provided by the device to the
maximum size of the touch_reports array.
Fixes: 752038248808 ("HID: playstation: add DualShock4 touchpad support.")
Cc: stable@vger.kernel.org
Reported-by: Xingyu Jin <xingyuj@google.com>
Signed-off-by: T.J. Mercier <tjmercier@google.com>
---
drivers/hid/hid-playstation.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
index 3c0db8f93c82..8d06ddff356a 100644
--- a/drivers/hid/hid-playstation.c
+++ b/drivers/hid/hid-playstation.c
@@ -2378,7 +2378,8 @@ static int dualshock4_parse_report(struct ps_device *ps_dev, struct hid_report *
(struct dualshock4_input_report_usb *)data;
ds4_report = &usb->common;
- num_touch_reports = usb->num_touch_reports;
+ num_touch_reports = min_t(u8, usb->num_touch_reports,
+ ARRAY_SIZE(usb->touch_reports));
touch_reports = usb->touch_reports;
} else if (hdev->bus == BUS_BLUETOOTH && report->id == DS4_INPUT_REPORT_BT &&
size == DS4_INPUT_REPORT_BT_SIZE) {
@@ -2392,7 +2393,8 @@ static int dualshock4_parse_report(struct ps_device *ps_dev, struct hid_report *
}
ds4_report = &bt->common;
- num_touch_reports = bt->num_touch_reports;
+ num_touch_reports = min_t(u8, bt->num_touch_reports,
+ ARRAY_SIZE(bt->touch_reports));
touch_reports = bt->touch_reports;
} else if (hdev->bus == BUS_BLUETOOTH &&
report->id == DS4_INPUT_REPORT_BT_MINIMAL &&
base-commit: 3cd8b194bf3428dfa53120fee47e827a7c495815
--
2.54.0.rc1.513.gad8abe7a5a-goog
^ permalink raw reply related
* Re: [PATCH 6.12 00/70] 6.12.82-rc1 review
From: Eddie Chapman @ 2026-04-17 15:34 UTC (permalink / raw)
To: Greg Kroah-Hartman, Manivannan Sadhasivam
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: <2026041742-armrest-clicker-84fd@gregkh>
On 17/04/2026 07:25, Greg Kroah-Hartman wrote:
> 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
>
Adding Manivannan Sadhasivam who is the author of the revert that is in
the 5.10, 5.15, 6.1 and 6.6 queues right now.
Manivannan, not sure if you are able to provide an updated patch for
6.12 where the revert is missing right now?
FWIW I applied the patch at
https://lore.kernel.org/stable/20260320172335.29778-1-john@kernel.doghat.io/
on top of 6.12.82-rc1 today and booted on an AMD system to test. It has
context issues but still applies fine, and I can confirm that my IOMMU
groups are no longer messed up. As a result have been able to pass
through 2 separate PCI cards to 2 separate VMs which I am unable to do
without the revert.
^ permalink raw reply
* Re: [PATCH 06/11] media: iris: Fix VM count passed to firmware
From: Vishnu Reddy @ 2026-04-17 15:29 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bryan O'Donoghue, Vikash Garodia, Dikshita Agarwal,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joerg Roedel, Will Deacon,
Robin Murphy, Bjorn Andersson, Konrad Dybcio, Stefan Schmidt,
Hans Verkuil, linux-media, linux-arm-msm, devicetree,
linux-kernel, iommu, stable
In-Reply-To: <otikvdonnfakykra57z4fingdyfm7xebw2h3lmykzk6sbk7emq@xptiwpx5lvjl>
On 4/14/2026 8:50 PM, Dmitry Baryshkov wrote:
> On Tue, Apr 14, 2026 at 10:30:02AM +0530, Vishnu Reddy wrote:
>> On Glymur, firmware interprets the value written to CPU_CS_SCIACMDARG3 as
>> the number of virtual machines (VMs) and internally adds 1 to it. Writing
> Does this apply to Glymur only or to other platforms too?
Only Glymur firmware is currently reading this register and other
platform firmwares are
ignoring this.
Thanks,
Vishnu Reddy.
>> 1 causes firmware to treat it as 2 VMs. Since only one VM is required,
>> remove this write to leave the register at its reset value of 0. This does
>> not affect other platforms as only Glymur firmware uses this register,
>> earlier platform firmwares ignore it.
>>
>> Fixes: abf5bac63f68a ("media: iris: implement the boot sequence of the firmware")
>> Cc:stable@vger.kernel.org
>> Signed-off-by: Vishnu Reddy<busanna.reddy@oss.qualcomm.com>
>> ---
>> drivers/media/platform/qcom/iris/iris_vpu_common.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/media/platform/qcom/iris/iris_vpu_common.c b/drivers/media/platform/qcom/iris/iris_vpu_common.c
>> index 548e5f1727fd..bfd1e762c38e 100644
>> --- a/drivers/media/platform/qcom/iris/iris_vpu_common.c
>> +++ b/drivers/media/platform/qcom/iris/iris_vpu_common.c
>> @@ -78,7 +78,6 @@ int iris_vpu_boot_firmware(struct iris_core *core)
>> iris_vpu_setup_ucregion_memory_map(core);
>>
>> writel(ctrl_init, core->reg_base + CTRL_INIT);
>> - writel(0x1, core->reg_base + CPU_CS_SCIACMDARG3);
>>
>> while (!ctrl_status && count < max_tries) {
>> ctrl_status = readl(core->reg_base + CTRL_STATUS);
>>
>> --
>> 2.34.1
>>
^ permalink raw reply
* Re: [PATCH 06/11] media: iris: Fix VM count passed to firmware
From: Vishnu Reddy @ 2026-04-17 15:28 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Bryan O'Donoghue, Vikash Garodia, Dikshita Agarwal,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joerg Roedel, Will Deacon,
Robin Murphy, Bjorn Andersson, Konrad Dybcio, Stefan Schmidt,
Hans Verkuil, linux-media, linux-arm-msm, devicetree,
linux-kernel, iommu, stable
In-Reply-To: <20260414063325.f3yag6gnmaysddkp@hu-mojha-hyd.qualcomm.com>
On 4/14/2026 12:03 PM, Mukesh Ojha wrote:
> On Tue, Apr 14, 2026 at 10:30:02AM +0530, Vishnu Reddy wrote:
>> On Glymur, firmware interprets the value written to CPU_CS_SCIACMDARG3 as
>> the number of virtual machines (VMs) and internally adds 1 to it. Writing
>> 1 causes firmware to treat it as 2 VMs. Since only one VM is required,
>> remove this write to leave the register at its reset value of 0. This does
>> not affect other platforms as only Glymur firmware uses this register,
>> earlier platform firmwares ignore it.
>>
>> Fixes: abf5bac63f68a ("media: iris: implement the boot sequence of the firmware")
>> Cc:stable@vger.kernel.org
>> Signed-off-by: Vishnu Reddy<busanna.reddy@oss.qualcomm.com>
> If this is a fix, should be the first patch in the series., so that it
> can be applied independently.
Ack, I'll move it accordingly.
>> ---
>> drivers/media/platform/qcom/iris/iris_vpu_common.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/media/platform/qcom/iris/iris_vpu_common.c b/drivers/media/platform/qcom/iris/iris_vpu_common.c
>> index 548e5f1727fd..bfd1e762c38e 100644
>> --- a/drivers/media/platform/qcom/iris/iris_vpu_common.c
>> +++ b/drivers/media/platform/qcom/iris/iris_vpu_common.c
>> @@ -78,7 +78,6 @@ int iris_vpu_boot_firmware(struct iris_core *core)
>> iris_vpu_setup_ucregion_memory_map(core);
>>
>> writel(ctrl_init, core->reg_base + CTRL_INIT);
>> - writel(0x1, core->reg_base + CPU_CS_SCIACMDARG3);
>>
>> while (!ctrl_status && count < max_tries) {
>> ctrl_status = readl(core->reg_base + CTRL_STATUS);
>>
>> --
>> 2.34.1
>>
^ permalink raw reply
* [PATCH] mtd: spi-nor: debugfs: fix out-of-bounds read in spi_nor_params_show()
From: Tudor Ambarus @ 2026-04-17 15:24 UTC (permalink / raw)
To: Pratyush Yadav, Michael Walle, Takahiro Kuwano, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra
Cc: Pratyush Yadav, Michael Walle, linux-mtd, linux-kernel, stable,
Tudor Ambarus
Sashiko noticed an out-of-bounds read [1].
In spi_nor_params_show(), the snor_f_names array is passed to
spi_nor_print_flags() using sizeof(snor_f_names).
Since snor_f_names is an array of pointers, sizeof() returns the total
number of bytes occupied by the pointers
(element_count * sizeof(void *))
rather than the element count itself. On 64-bit systems, this makes the
passed length 8x larger than intended.
Inside spi_nor_print_flags(), the 'names_len' argument is used to
bounds-check the 'names' array access. An out-of-bounds read occurs
if a flag bit is set that exceeds the array's actual element count
but is within the inflated byte-size count.
Correct this by using ARRAY_SIZE() to pass the actual number of
string pointers in the array.
Cc: stable@vger.kernel.org
Fixes: 0257be79fc4a ("mtd: spi-nor: expose internal parameters via debugfs")
Closes: https://sashiko.dev/#/patchset/20260417-die-erase-fix-v2-1-73bb7004ebad%40infineon.com [1]
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
We shall assign a CVE to this. I'll look into how next week.
Link: https://lore.kernel.org/linux-mtd/20260417-die-erase-fix-v2-1-73bb7004ebad@infineon.com/
---
drivers/mtd/spi-nor/debugfs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/debugfs.c b/drivers/mtd/spi-nor/debugfs.c
index fa6956144d2e..14ba1680c315 100644
--- a/drivers/mtd/spi-nor/debugfs.c
+++ b/drivers/mtd/spi-nor/debugfs.c
@@ -1,5 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
+#include <linux/array_size.h>
#include <linux/debugfs.h>
#include <linux/mtd/spi-nor.h>
#include <linux/spi/spi.h>
@@ -92,7 +93,8 @@ static int spi_nor_params_show(struct seq_file *s, void *data)
seq_printf(s, "address nbytes\t%u\n", nor->addr_nbytes);
seq_puts(s, "flags\t\t");
- spi_nor_print_flags(s, nor->flags, snor_f_names, sizeof(snor_f_names));
+ spi_nor_print_flags(s, nor->flags, snor_f_names,
+ ARRAY_SIZE(snor_f_names));
seq_puts(s, "\n");
seq_puts(s, "\nopcodes\n");
---
base-commit: 43cfbdda5af60ffc6272a7b8c5c37d1d0a181ca9
change-id: 20260417-fix-oob-read-spi-nor-25409b31d01a
Best regards,
--
Tudor Ambarus <tudor.ambarus@linaro.org>
^ permalink raw reply related
* Re: [PATCH 06/11] media: iris: Fix VM count passed to firmware
From: Vishnu Reddy @ 2026-04-17 14:35 UTC (permalink / raw)
To: Konrad Dybcio, Bryan O'Donoghue, Vikash Garodia,
Dikshita Agarwal, Abhinav Kumar, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joerg Roedel,
Will Deacon, Robin Murphy, Bjorn Andersson, Konrad Dybcio,
Stefan Schmidt, Hans Verkuil
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel, iommu,
stable
In-Reply-To: <fe1e2ef2-dece-4864-a89b-a311b3ddbfcc@oss.qualcomm.com>
On 4/14/2026 2:59 PM, Konrad Dybcio wrote:
> On 4/14/26 7:00 AM, Vishnu Reddy wrote:
>> On Glymur, firmware interprets the value written to CPU_CS_SCIACMDARG3 as
>> the number of virtual machines (VMs) and internally adds 1 to it. Writing
>> 1 causes firmware to treat it as 2 VMs. Since only one VM is required,
>> remove this write to leave the register at its reset value of 0. This does
>> not affect other platforms as only Glymur firmware uses this register,
>> earlier platform firmwares ignore it.
> Should we write a zero there, then?
zero being the reset value for that register, I would prefer avoiding to
write unless needed.
Thanks,
Vishnu Reddy.
> Konrad
^ permalink raw reply
* Re: [PATCH] xfs: fix memory leak for data allocated by xfs_zone_gc_data_alloc()
From: Darrick J. Wong @ 2026-04-17 14:18 UTC (permalink / raw)
To: Wilfred Mallawa
Cc: linux-xfs, linux-kernel, Carlos Maiolino, Hans Holmberg,
Wilfred Mallawa, stable
In-Reply-To: <20260417021628.2608734-3-wilfred.opensource@gmail.com>
On Fri, Apr 17, 2026 at 12:16:30PM +1000, Wilfred Mallawa wrote:
> From: Wilfred Mallawa <wilfred.mallawa@wdc.com>
>
> In xfs_zone_gc_mount(), on error, a struct xfs_zone_gc_data allocated
> with xfs_zone_gc_data_alloc() is freed with kfree(), however, this
> doesn't free the underlying folios or the rmap_irecs.
>
> Use xfs_zone_gc_data_free() to correctly free this memory.
>
> Fixes: 080d01c41d44 ("xfs: implement zoned garbage collection")
> Cc: stable@vger.kernel.org
Cc: <stable@vger.kernel.org> # v6.15
[autobackport plz, I need all the help I can get]
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
--D
> Signed-off-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
> ---
> fs/xfs/xfs_zone_gc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/xfs/xfs_zone_gc.c b/fs/xfs/xfs_zone_gc.c
> index e7b33d5a8b3d..2520e57e24a8 100644
> --- a/fs/xfs/xfs_zone_gc.c
> +++ b/fs/xfs/xfs_zone_gc.c
> @@ -1230,7 +1230,7 @@ xfs_zone_gc_mount(
> if (data->oz)
> xfs_open_zone_put(data->oz);
> out_free_gc_data:
> - kfree(data);
> + xfs_zone_gc_data_free(data);
> return error;
> }
>
> --
> 2.53.0
>
>
^ permalink raw reply
* [PATCH net] net: mctp: fix don't require received header reserved bits to be zero
From: wit_yuan @ 2026-04-17 14:13 UTC (permalink / raw)
To: jk
Cc: yuanzhaoming901030, yuanzm2, matt, davem, edumazet, kuba, pabeni,
netdev, linux-kernel, stable
From: Yuan Zhaoming <yuanzm2@lenovo.com>
From the MCTP Base specification (DSP0236 v1.2.1), the first byte of
the MCTP header contains a 4 bit reserved field, and 4 bit version.
On our current receive path, we require those 4 reserved bits to be
zero, but the 9500-8i card is non-conformant, and may set these
reserved bits.
DSP0236 states that the reserved bits must be written as zero, and
ignored when read. While the device might not conform to the former,
we should accept these message to conform to the latter.
Relax our check on the MCTP version byte to allow non-zero bits in the
reserved field.
Fixes: 889b7da23abf ("mctp: Add initial routing framework")
Signed-off-by: Yuan Zhaoming <yuanzm2@lenovo.com>
Cc: stable@vger.kernel.org
---
v3: https://lore.kernel.org/netdev/acd54f40-fcd7-44df-9fe6-0b278f4a3476@redhat.com/T/#t
v2: https://lore.kernel.org/netdev/20260410144339.0d1b289a@kernel.org/T/#t
v1: https://lore.kernel.org/netdev/ff147a3f0d27ef2aa6026cc86f9113d56a8c61ac.camel@codeconstruct.com.au/T/#t
---
include/net/mctp.h | 3 +++
net/mctp/route.c | 8 ++++++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/include/net/mctp.h b/include/net/mctp.h
index 3de6556..3d008b0 100644
--- a/include/net/mctp.h
+++ b/include/net/mctp.h
@@ -26,6 +26,9 @@ struct mctp_hdr {
#define MCTP_VER_MIN 1
#define MCTP_VER_MAX 1
+/* Definitions for ver field */
+#define MCTP_HDR_VER_MASK GENMASK(3, 0)
+
/* Definitions for flags_seq_tag field */
#define MCTP_HDR_FLAG_SOM BIT(7)
#define MCTP_HDR_FLAG_EOM BIT(6)
diff --git a/net/mctp/route.c b/net/mctp/route.c
index 26cb415..1236ea2 100644
--- a/net/mctp/route.c
+++ b/net/mctp/route.c
@@ -441,6 +441,7 @@ static int mctp_dst_input(struct mctp_dst *dst, struct sk_buff *skb)
unsigned long f;
u8 tag, flags;
int rc;
+ u8 ver;
msk = NULL;
rc = -EINVAL;
@@ -467,7 +468,8 @@ static int mctp_dst_input(struct mctp_dst *dst, struct sk_buff *skb)
netid = mctp_cb(skb)->net;
skb_pull(skb, sizeof(struct mctp_hdr));
- if (mh->ver != 1)
+ ver = mh->ver & MCTP_HDR_VER_MASK;
+ if (ver < MCTP_VER_MIN || ver > MCTP_VER_MAX)
goto out;
flags = mh->flags_seq_tag & (MCTP_HDR_FLAG_SOM | MCTP_HDR_FLAG_EOM);
@@ -1317,6 +1319,7 @@ static int mctp_pkttype_receive(struct sk_buff *skb, struct net_device *dev,
struct mctp_dst dst;
struct mctp_hdr *mh;
int rc;
+ u8 ver;
rcu_read_lock();
mdev = __mctp_dev_get(dev);
@@ -1334,7 +1337,8 @@ static int mctp_pkttype_receive(struct sk_buff *skb, struct net_device *dev,
/* We have enough for a header; decode and route */
mh = mctp_hdr(skb);
- if (mh->ver < MCTP_VER_MIN || mh->ver > MCTP_VER_MAX)
+ ver = mh->ver & MCTP_HDR_VER_MASK;
+ if (ver < MCTP_VER_MIN || ver > MCTP_VER_MAX)
goto err_drop;
/* source must be valid unicast or null; drop reserved ranges and
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net v3 4/4] nfc: llcp: fix OOB read of DM reason byte in nfc_llcp_recv_dm
From: Simon Horman @ 2026-04-17 13:48 UTC (permalink / raw)
To: snowwlake
Cc: Simon Horman, netdev, edumazet, stable, framemain, pabeni, davem,
kuba, linux-kernel
In-Reply-To: <20260414233534.55973-5-snowwlake@icloud.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
nfc: llcp: fix OOB read of DM reason byte in nfc_llcp_recv_dm
nfc_llcp_recv_dm() reads skb->data[2] (the DM reason byte) without
first verifying that skb->len is at least LLCP_HEADER_SIZE + 1. A DM
PDU carrying only the 2-byte LLCP header from a rogue peer therefore
triggers a 1-byte OOB read.
> Fixes: d646960f7986 ("NFC: Add LLCP sockets")
Is this Fixes tag correct? Looking at the git history, the function
nfc_llcp_recv_dm() with the vulnerable skb->data[2] access was actually
introduced by commit 5c0560b7a5c6 ("NFC: Handle LLCP Disconnected Mode
frames"), not by d646960f7986 ("NFC: Add LLCP sockets").
Suggested: Fixes: 5c0560b7a5c6 ("NFC: Handle LLCP Disconnected Mode frames")
^ permalink raw reply
* Re: [PATCH net v3 3/4] nfc: llcp: fix TLV parsing OOB in nfc_llcp_recv_snl
From: Simon Horman @ 2026-04-17 13:43 UTC (permalink / raw)
To: snowwlake
Cc: Simon Horman, kuba, netdev, pabeni, linux-kernel, stable,
framemain, edumazet, davem
In-Reply-To: <20260414233534.55973-4-snowwlake@icloud.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
nfc: llcp: fix TLV parsing OOB in nfc_llcp_recv_snl
This commit fixes multiple out-of-bounds read vulnerabilities in the
nfc_llcp_recv_snl() function when handling Service Name Lookup PDUs from
hostile NFC peers.
> nfc: llcp: fix TLV parsing OOB in nfc_llcp_recv_snl
>
> nfc_llcp_recv_snl() has four problems when handling a hostile peer:
>
> 1. nfc_llcp_dsap()/nfc_llcp_ssap() dereference skb->data[0..1] without
> verifying skb->len; a 0- or 1-byte frame leads to an OOB read.
> Additionally tlv_len = skb->len - LLCP_HEADER_SIZE wraps when
> skb->len < 2, causing the following loop to run far past the
> buffer.
>
> 2. The per-iteration loop guard `offset < tlv_len` only proves one
> byte is available, but the body reads tlv[0] and tlv[1].
>
> 3. The peer-supplied `length` field is used to advance `tlv` without
> being checked against the remaining array space.
>
> 4. The SDREQ handler previously only required length >= 1 but reads
> both tid (tlv[2]) and the first byte of service_name (tlv[3], via
> the pr_debug("%.16s") print and the service_name_len = length - 1
> string usage), so length >= 2 is required.
>
> Fix: reject frames smaller than LLCP_HEADER_SIZE up front; add TLV
> header and TLV value guards at the top of each iteration; bump the
> SDREQ minimum length to 2.
>
> Reachable from any NFC peer within ~4 cm once an LLCP link is up.
>
> Fixes: 7a06f0ee2823 ("NFC: llcp: Service Name Lookup implementation")
The Fixes: tag references commit 7a06f0ee2823, but this commit does
not exist in the repository. The vulnerable TLV parsing was actually
introduced in commit 19cfe5843e86 ("NFC: Initial SNL support") from
October 5, 2012, which added nfc_llcp_recv_snl() with the bounds
checking issues.
Should the Fixes: tag be:
Fixes: 19cfe5843e86 ("NFC: Initial SNL support")
> diff --git a/net/nfc/llcp_core.c b/net/nfc/llcp_core.c
> index db5bc6a878dd..8e7b8d2347d6 100644
> --- a/net/nfc/llcp_core.c
> +++ b/net/nfc/llcp_core.c
> @@ -1284,6 +1284,11 @@ static void nfc_llcp_recv_snl(struct nfc_llcp_local *local,
> size_t sdres_tlvs_len;
> HLIST_HEAD(nl_sdres_list);
>
> + if (skb->len < LLCP_HEADER_SIZE) {
> + pr_err("Malformed SNL PDU\n");
> + return;
> + }
> +
> dsap = nfc_llcp_dsap(skb);
> ssap = nfc_llcp_ssap(skb);
>
> @@ -1300,11 +1305,17 @@ static void nfc_llcp_recv_snl(struct nfc_llcp_local *local,
> sdres_tlvs_len = 0;
>
> while (offset < tlv_len) {
> + if (tlv_len - offset < 2)
> + break;
> type = tlv[0];
> length = tlv[1];
> + if (tlv_len - offset - 2 < length)
> + break;
>
> switch (type) {
> case LLCP_TLV_SDREQ:
> + if (length < 2)
> + break;
> tid = tlv[2];
> service_name = (char *) &tlv[3];
> service_name_len = length - 1;
>
> pr_debug("Looking for %.16s\n", service_name);
The new length check ensures length >= 2 to protect tlv[2] and tlv[3]
accesses. However, pr_debug with %.16s can read up to 16 bytes from
service_name (starting at &tlv[3]), not just one byte as stated in the
commit message.
When length==2 (the minimum), only tlv[3] is validated, but pr_debug
may read through tlv[18] while searching for a null terminator. If a
hostile peer sends a SDREQ with length=2 near the end of the buffer,
pr_debug could read beyond the validated region into skb tail room.
This only occurs when DEBUG is enabled (development kernels), so it's
less critical than the production OOB reads being fixed. However, should
the debug code use bounded printing to match the security-focused nature
of this patch?
pr_debug("Looking for %.*s\n", (int)service_name_len, service_name);
[ ... ]
> @@ -1363,6 +1374,8 @@ static void nfc_llcp_recv_snl(struct nfc_llcp_local *local,
> break;
>
> case LLCP_TLV_SDRES:
In v2 of this patch, Paolo Abeni noted that SDRES also needs a length
check for accessing tlv[2] and tlv[3]. While v2 included this check,
it was removed in v3 and is missing from the current version.
SDREQ now has the length < 2 protection (added above), but SDRES still
lacks validation. Looking at the SDRES handler later in the function:
net/nfc/llcp_core.c:nfc_llcp_recv_snl() {
case LLCP_TLV_SDRES:
dsap = tlv[2]; /* reads tlv[2] without validation */
...
ssap = tlv[3]; /* reads tlv[3] without validation */
}
Should SDRES also have the length >= 2 check before accessing tlv[2]
and tlv[3]?
^ permalink raw reply
* [PATCH] ALSA: caiaq: Fix control_put() result and cache rollback
From: Cássio Gabriel @ 2026-04-17 13:41 UTC (permalink / raw)
To: Takashi Iwai, Daniel Mack, Jaroslav Kysela
Cc: Daniel Mack, linux-sound, linux-kernel, stable,
Cássio Gabriel
control_put() always returns 1 and updates cdev->control_state[]
before sending the USB command. It also ignores transport errors
from usb_bulk_msg(), snd_usb_caiaq_send_command(), and
snd_usb_caiaq_send_command_bank().
That breaks the ALSA .put() contract and can leave control_get()
reporting a cached value the device never accepted.
Return 0 for unchanged values, propagate transport failures,
and restore the cached byte when the write fails.
Fixes: 8e3cd08ed8e59 ("[ALSA] caiaq - add control API and more input features")
Cc: stable@vger.kernel.org
Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
---
sound/usb/caiaq/control.c | 52 ++++++++++++++++++++++++++++++++---------------
1 file changed, 36 insertions(+), 16 deletions(-)
diff --git a/sound/usb/caiaq/control.c b/sound/usb/caiaq/control.c
index af459c49baf4..4598fb7e8be0 100644
--- a/sound/usb/caiaq/control.c
+++ b/sound/usb/caiaq/control.c
@@ -87,6 +87,7 @@ static int control_put(struct snd_kcontrol *kcontrol,
struct snd_usb_caiaqdev *cdev = caiaqdev(chip->card);
int pos = kcontrol->private_value;
int v = ucontrol->value.integer.value[0];
+ int ret;
unsigned char cmd;
switch (cdev->chip.usb_id) {
@@ -103,6 +104,10 @@ static int control_put(struct snd_kcontrol *kcontrol,
if (pos & CNT_INTVAL) {
int i = pos & ~CNT_INTVAL;
+ unsigned char old = cdev->control_state[i];
+
+ if (old == v)
+ return 0;
cdev->control_state[i] = v;
@@ -113,10 +118,11 @@ static int control_put(struct snd_kcontrol *kcontrol,
cdev->ep8_out_buf[0] = i;
cdev->ep8_out_buf[1] = v;
- usb_bulk_msg(cdev->chip.dev,
- usb_sndbulkpipe(cdev->chip.dev, 8),
- cdev->ep8_out_buf, sizeof(cdev->ep8_out_buf),
- &actual_len, 200);
+ ret = usb_bulk_msg(cdev->chip.dev,
+ usb_sndbulkpipe(cdev->chip.dev, 8),
+ cdev->ep8_out_buf,
+ sizeof(cdev->ep8_out_buf),
+ &actual_len, 200);
} else if (cdev->chip.usb_id ==
USB_ID(USB_VID_NATIVEINSTRUMENTS, USB_PID_MASCHINECONTROLLER)) {
@@ -128,21 +134,36 @@ static int control_put(struct snd_kcontrol *kcontrol,
offset = MASCHINE_BANK_SIZE;
}
- snd_usb_caiaq_send_command_bank(cdev, cmd, bank,
- cdev->control_state + offset,
- MASCHINE_BANK_SIZE);
+ ret = snd_usb_caiaq_send_command_bank(cdev, cmd, bank,
+ cdev->control_state + offset,
+ MASCHINE_BANK_SIZE);
} else {
- snd_usb_caiaq_send_command(cdev, cmd,
- cdev->control_state, sizeof(cdev->control_state));
+ ret = snd_usb_caiaq_send_command(cdev, cmd,
+ cdev->control_state,
+ sizeof(cdev->control_state));
+ }
+
+ if (ret < 0) {
+ cdev->control_state[i] = old;
+ return ret;
}
} else {
- if (v)
- cdev->control_state[pos / 8] |= 1 << (pos % 8);
- else
- cdev->control_state[pos / 8] &= ~(1 << (pos % 8));
+ int idx = pos / 8;
+ unsigned char mask = 1 << (pos % 8);
+ unsigned char old = cdev->control_state[idx];
+ unsigned char val = v ? (old | mask) : (old & ~mask);
- snd_usb_caiaq_send_command(cdev, cmd,
- cdev->control_state, sizeof(cdev->control_state));
+ if (old == val)
+ return 0;
+
+ cdev->control_state[idx] = val;
+ ret = snd_usb_caiaq_send_command(cdev, cmd,
+ cdev->control_state,
+ sizeof(cdev->control_state));
+ if (ret < 0) {
+ cdev->control_state[idx] = old;
+ return ret;
+ }
}
return 1;
@@ -640,4 +661,3 @@ int snd_usb_caiaq_control_init(struct snd_usb_caiaqdev *cdev)
return ret;
}
-
---
base-commit: c4643e7c7f45a07f26e01a4a617b859c01dabb3d
change-id: 20260416-caiaq-control-put-50be8a70431d
Best regards,
--
Cássio Gabriel <cassiogabrielcontato@gmail.com>
^ permalink raw reply related
* Re: [PATCH v3] drm/radeon: fix integer overflow in radeon_align_pitch()
From: Alex Deucher @ 2026-04-17 13:34 UTC (permalink / raw)
To: Werner Kasselman
Cc: alexander.deucher@amd.com, christian.koenig@amd.com,
airlied@gmail.com, simona@ffwll.ch, tzimmermann@suse.de,
amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <20260415221350.1178094-1-werner@verivus.com>
Applied. Thanks!
On Wed, Apr 15, 2026 at 6:14 PM Werner Kasselman <werner@verivus.ai> wrote:
>
> radeon_align_pitch() has the same kind of overflow issue as the old
> amdgpu helper: both the alignment round-up add and the final
> 'aligned * cpp' calculation can overflow signed int.
>
> If that wraps, radeon_mode_dumb_create() can end up returning an
> invalid pitch or creating a zero-sized dumb buffer.
>
> Fix this by using check_add_overflow() for the alignment round-up and
> check_mul_overflow() for the final pitch calculation, returning 0 on
> overflow. Also reject zero pitch and size in
> radeon_mode_dumb_create().
>
> Found via AST-based call-graph analysis using sqry.
>
> Fixes: ff72145badb8 ("drm: dumb scanout create/mmap for intel/radeon (v3)")
> Cc: stable@vger.kernel.org
> Signed-off-by: Werner Kasselman <werner@verivus.com>
> ---
> v3:
> - Squash this fix with the earlier zero pitch/size validation change.
> - Use overflow helpers for both the alignment round-up and final
> pitch calculation.
>
> drivers/gpu/drm/radeon/radeon_gem.c | 13 +++++++++++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c
> index 20fc87409f2e..8ce180e22d1d 100644
> --- a/drivers/gpu/drm/radeon/radeon_gem.c
> +++ b/drivers/gpu/drm/radeon/radeon_gem.c
> @@ -28,6 +28,7 @@
>
> #include <linux/debugfs.h>
> #include <linux/iosys-map.h>
> +#include <linux/overflow.h>
> #include <linux/pci.h>
>
> #include <drm/drm_device.h>
> @@ -812,6 +813,7 @@ int radeon_align_pitch(struct radeon_device *rdev, int width, int cpp, bool tile
> int aligned = width;
> int align_large = (ASIC_IS_AVIVO(rdev)) || tiled;
> int pitch_mask = 0;
> + int pitch;
>
> switch (cpp) {
> case 1:
> @@ -826,9 +828,12 @@ int radeon_align_pitch(struct radeon_device *rdev, int width, int cpp, bool tile
> break;
> }
>
> - aligned += pitch_mask;
> + if (check_add_overflow(aligned, pitch_mask, &aligned))
> + return 0;
> aligned &= ~pitch_mask;
> - return aligned * cpp;
> + if (check_mul_overflow(aligned, cpp, &pitch))
> + return 0;
> + return pitch;
> }
>
> int radeon_mode_dumb_create(struct drm_file *file_priv,
> @@ -842,8 +847,12 @@ int radeon_mode_dumb_create(struct drm_file *file_priv,
>
> args->pitch = radeon_align_pitch(rdev, args->width,
> DIV_ROUND_UP(args->bpp, 8), 0);
> + if (!args->pitch)
> + return -EINVAL;
> args->size = (u64)args->pitch * args->height;
> args->size = ALIGN(args->size, PAGE_SIZE);
> + if (!args->size)
> + return -EINVAL;
>
> r = radeon_gem_object_create(rdev, args->size, 0,
> RADEON_GEM_DOMAIN_VRAM, 0,
> --
> 2.43.0
^ permalink raw reply
* Re: [PATCH] ASoC: ES8389: convert to devm_clk_get_optional() to get clock
From: Uwe Kleine-König @ 2026-04-17 13:34 UTC (permalink / raw)
To: Li Jian
Cc: linux-kernel, lgirdwood, loongarch, chenhuacai, zhoubinbin,
jeffbai, stable, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Zhang Yi, Charles Keepax, Kuninori Morimoto, Alexandru Ardelean,
Jonathan Cameron, Stephen Boyd, linux-sound
In-Reply-To: <tencent_7C78374FB9F4B3A37101E5C719715D8BC40A@qq.com>
[-- Attachment #1: Type: text/plain, Size: 926 bytes --]
Hello,
On Fri, Apr 17, 2026 at 06:53:14PM +0800, Li Jian wrote:
> When enabling ES8390 via ACPI description, es8389 would fail to
> obtain a clock source, causing the driver to fail to initialize.
> This was not an issue with older kernels, but since commit
> abae8e57e49a ("clk: generalize devm_clk_get() a bit"),
> devm_clk_get() would return an error pointer when a clock source
> was not detected (instead of falling back to a static clock),
> causing the driver to fail early.
>
> Use devm_clk_get_optional() instead to return to the previous
> behaviour, allowing the use of a static clock source.
>
> Cc: stable@vger.kernel.org
> Fixes: abae8e57e49a ("clk: generalize devm_clk_get() a bit")
Are you sure you identified the breaking commit correctly? I intended
the patch not to introduce any semantic change, and even with your claim
I don't spot the issue in abae8e57e49a.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [f2fs-dev] [PATCH] f2fs: fix node_cnt race between extent node destroy and writeback
From: Yongpeng Yang @ 2026-04-17 13:26 UTC (permalink / raw)
To: Chao Yu, Jaegeuk Kim; +Cc: Yongpeng Yang, stable, linux-f2fs-devel
In-Reply-To: <f997ceb6-85d1-4872-be06-2a50469b3b18@kernel.org>
On 4/17/26 17:00, Chao Yu via Linux-f2fs-devel wrote:
> On 4/3/26 22:40, Yongpeng Yang wrote:
>> From: Yongpeng Yang <yangyongpeng@xiaomi.com>
>>
>> f2fs_destroy_extent_node() does not set FI_NO_EXTENT before clearing
>> extent nodes. When called from f2fs_drop_inode() with I_SYNC set,
>> concurrent kworker writeback can insert new extent nodes into the same
>> extent tree, racing with the destroy and triggering f2fs_bug_on() in
>> __destroy_extent_node(). The scenario is as follows:
>>
>> drop inode writeback
>> - iput
>> - f2fs_drop_inode // I_SYNC set
>> - f2fs_destroy_extent_node
>> - __destroy_extent_node
>> - while (node_cnt) {
>> write_lock(&et->lock)
>> __free_extent_tree
>> write_unlock(&et->lock)
>> - __writeback_single_inode
>> - f2fs_outplace_write_data
>> - f2fs_update_read_extent_cache
>> - __update_extent_tree_range
>> // FI_NO_EXTENT not set,
>> // insert new extent node
>> } // node_cnt == 0, exit while
>> - f2fs_bug_on(node_cnt) // node_cnt > 0
>>
>> Additionally, __update_extent_tree_range() only checks FI_NO_EXTENT for
>> EX_READ type, leaving EX_BLOCK_AGE updates completely unprotected.
>>
>> This patch set FI_NO_EXTENT under et->lock in __destroy_extent_node(),
>> consistent with other callers (__update_extent_tree_range and
>> __drop_extent_tree) and check FI_NO_EXTENT for both EX_READ and
>> EX_BLOCK_AGE tree.
>
> I suffered below test failure, then I bisect to this change.
>
> generic/475 84s ... [failed, exit status 1]- output mismatch (see /
> share/git/fstests/results//generic/475.out.bad)
> --- tests/generic/475.out 2025-01-12 21:57:40.279440664 +0800
> +++ /share/git/fstests/results//generic/475.out.bad 2026-04-17
> 12:08:28.000000000 +0800
> @@ -1,2 +1,6 @@
> QA output created by 475
> Silence is golden.
> +mount: /mnt/scratch_f2fs: mount system call failed: Structure needs
> cleaning.
> + dmesg(1) may have more information after failed mount system
> call.
> +mount failed
> +(see /share/git/fstests/results//generic/475.full for details)
> ...
> (Run 'diff -u /share/git/fstests/tests/generic/475.out /share/git/
> fstests/results//generic/475.out.bad' to see the entire diff)
>
>
> generic/388 73s ... [failed, exit status 1]- output mismatch (see /
> share/git/fstests/results//generic/388.out.bad)
> --- tests/generic/388.out 2025-01-12 21:57:40.275440602 +0800
> +++ /share/git/fstests/results//generic/388.out.bad 2026-04-17
> 11:58:05.000000000 +0800
> @@ -1,2 +1,6 @@
> QA output created by 388
> Silence is golden.
> +mount: /mnt/scratch_f2fs: mount system call failed: Structure needs
> cleaning.
> + dmesg(1) may have more information after failed mount system
> call.
> +cycle mount failed
> +(see /share/git/fstests/results//generic/388.full for details)
> ...
> (Run 'diff -u /share/git/fstests/tests/generic/388.out /share/git/
> fstests/results//generic/388.out.bad' to see the entire diff)
>
>
> F2FS-fs (dm-0): sanity_check_extent_cache: inode (ino=1761) extent
> info [220057, 57, 6] is incorrect, run fsck to fix
>
> I suspect we may miss any extent updates after we set FI_NO_EXTENT in
> __destroy_extent_node(), result in failing in sanity_check_extent_cache().
>
> Can we just relocate f2fs_bug_on(node_cnt) rather than complicated change?
> Thoughts?
Oh, I overlooked largest extent. How about relocate
f2fs_bug_on(node_cnt) to __destroy_extent_tree?
static void __destroy_extent_tree(struct inode *inode, enum extent_type
type)
/* free all extent info belong to this extent tree */
node_cnt = __destroy_extent_node(inode, type);
+ f2fs_bug_on(sbi, atomic_read(&et->node_cnt));
Thanks
Yongpeng,
>
> Thanks,
>
>>
>> Fixes: 3fc5d5a182f6 ("f2fs: fix to shrink read extent node in batches")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Yongpeng Yang <yangyongpeng@xiaomi.com>
>> ---
>> fs/f2fs/extent_cache.c | 17 ++++++++++-------
>> 1 file changed, 10 insertions(+), 7 deletions(-)
>>
>> diff --git a/fs/f2fs/extent_cache.c b/fs/f2fs/extent_cache.c
>> index 0ed84cc065a7..87169fd29d89 100644
>> --- a/fs/f2fs/extent_cache.c
>> +++ b/fs/f2fs/extent_cache.c
>> @@ -119,9 +119,10 @@ static bool __may_extent_tree(struct inode
>> *inode, enum extent_type type)
>> if (!__init_may_extent_tree(inode, type))
>> return false;
>> + if (is_inode_flag_set(inode, FI_NO_EXTENT))
>> + return false;
>> +
>> if (type == EX_READ) {
>> - if (is_inode_flag_set(inode, FI_NO_EXTENT))
>> - return false;
>> if (is_inode_flag_set(inode, FI_COMPRESSED_FILE) &&
>> !f2fs_sb_has_readonly(F2FS_I_SB(inode)))
>> return false;
>> @@ -644,6 +645,8 @@ static unsigned int __destroy_extent_node(struct
>> inode *inode,
>> while (atomic_read(&et->node_cnt)) {
>> write_lock(&et->lock);
>> + if (!is_inode_flag_set(inode, FI_NO_EXTENT))
>> + set_inode_flag(inode, FI_NO_EXTENT);
>> node_cnt += __free_extent_tree(sbi, et, nr_shrink);
>> write_unlock(&et->lock);
>> }
>> @@ -688,12 +691,12 @@ static void __update_extent_tree_range(struct
>> inode *inode,
>> write_lock(&et->lock);
>> - if (type == EX_READ) {
>> - if (is_inode_flag_set(inode, FI_NO_EXTENT)) {
>> - write_unlock(&et->lock);
>> - return;
>> - }
>> + if (is_inode_flag_set(inode, FI_NO_EXTENT)) {
>> + write_unlock(&et->lock);
>> + return;
>> + }
>> + if (type == EX_READ) {
>> prev = et->largest;
>> dei.len = 0;
>>
>
>
>
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply
* [PATCH v2 2/2] PCI/IOV: Skip VF Resizable BAR restore on read error
From: Marco Nenciarini @ 2026-04-17 13:24 UTC (permalink / raw)
To: Bjorn Helgaas, linux-pci
Cc: linux-kernel, Christian König, Marco Nenciarini, stable,
Michał Winiarski, Ilpo Järvinen, Rafael J . Wysocki,
Eric Chanudet, Alex Williamson, Lukas Wunner
In-Reply-To: <cover.1776429882.git.mnencia@kcore.it>
sriov_restore_vf_rebar_state() uses the VF Resizable BAR Control
register to decide how many VF BARs to restore (nbars) and which
VF BAR each iteration addresses (bar_idx). bar_idx indexes into
dev->sriov->barsz[], which has only PCI_SRIOV_NUM_BARS (6) entries.
When the device does not respond, config reads return the all-ones
pattern. Both fields are 3 bits wide, so nbars and bar_idx both
evaluate to 7. The barsz[] access then goes out of bounds. UBSAN
reports this as:
UBSAN: array-index-out-of-bounds in drivers/pci/iov.c:948:51
index 7 is out of range for type 'resource_size_t [6]'
Observed on an NVIDIA RTX PRO 1000 GPU (GB207GLM) that fell off the
PCIe bus during a failed GC6 power state exit. The subsequent
pci_restore_state() invoked sriov_restore_vf_rebar_state() while
config reads returned 0xffffffff, triggering the splat.
Bail out if any VF Resizable BAR Control read returns the error
pattern. No further VF BARs are touched, which is safe because a
config read that returns the error pattern indicates the device is
unreachable and restoration is pointless. This mirrors the guard
in pci_restore_rebar_state().
Fixes: 5a8f77e24a30 ("PCI/IOV: Restore VF resizable BAR state after reset")
Cc: stable@vger.kernel.org
Signed-off-by: Marco Nenciarini <mnencia@kcore.it>
---
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: Eric Chanudet <echanude@redhat.com>
Cc: Alex Williamson <alex@shazbot.org>
Cc: Lukas Wunner <lukas@wunner.de>
drivers/pci/iov.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index 91ac4e37ecb9c..08df9bace13d1 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -938,12 +938,18 @@ static void sriov_restore_vf_rebar_state(struct pci_dev *dev)
return;
pci_read_config_dword(dev, pos + PCI_VF_REBAR_CTRL, &ctrl);
+ if (PCI_POSSIBLE_ERROR(ctrl))
+ return;
+
nbars = FIELD_GET(PCI_VF_REBAR_CTRL_NBAR_MASK, ctrl);
for (i = 0; i < nbars; i++, pos += 8) {
int bar_idx, size;
pci_read_config_dword(dev, pos + PCI_VF_REBAR_CTRL, &ctrl);
+ if (PCI_POSSIBLE_ERROR(ctrl))
+ return;
+
bar_idx = FIELD_GET(PCI_VF_REBAR_CTRL_BAR_IDX, ctrl);
size = pci_rebar_bytes_to_size(dev->sriov->barsz[bar_idx]);
ctrl &= ~PCI_VF_REBAR_CTRL_BAR_SIZE;
--
2.47.3
^ permalink raw reply related
* [PATCH v2 1/2] PCI: Skip Resizable BAR restore on read error
From: Marco Nenciarini @ 2026-04-17 13:24 UTC (permalink / raw)
To: Bjorn Helgaas, linux-pci
Cc: linux-kernel, Christian König, Marco Nenciarini, stable,
Michał Winiarski, Ilpo Järvinen, Rafael J . Wysocki,
Eric Chanudet, Alex Williamson, Lukas Wunner
In-Reply-To: <cover.1776429882.git.mnencia@kcore.it>
pci_restore_rebar_state() uses the Resizable BAR Control register to
decide how many BARs to restore (nbars) and which BAR each iteration
addresses (bar_idx).
When the device does not respond, config reads return the all-ones
pattern. Both fields are 3 bits wide, so nbars and bar_idx both
evaluate to 7, past the spec's valid ranges for both fields.
pci_resource_n() then returns an unrelated resource slot, whose
size is used to derive a nonsensical value written back to the
Resizable BAR Control register.
Bail out if any Resizable BAR Control read returns the error
pattern. No further BARs are touched, which is safe because a
config read that returns the error pattern indicates the device is
unreachable and restoration is pointless.
Fixes: d3252ace0bc6 ("PCI: Restore resized BAR state on resume")
Cc: stable@vger.kernel.org
Signed-off-by: Marco Nenciarini <mnencia@kcore.it>
---
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: Eric Chanudet <echanude@redhat.com>
Cc: Alex Williamson <alex@shazbot.org>
Cc: Lukas Wunner <lukas@wunner.de>
drivers/pci/rebar.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/pci/rebar.c b/drivers/pci/rebar.c
index 39f8cf3b70d57..11965947c4cb5 100644
--- a/drivers/pci/rebar.c
+++ b/drivers/pci/rebar.c
@@ -231,6 +231,9 @@ void pci_restore_rebar_state(struct pci_dev *pdev)
return;
pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
+ if (PCI_POSSIBLE_ERROR(ctrl))
+ return;
+
nbars = FIELD_GET(PCI_REBAR_CTRL_NBAR_MASK, ctrl);
for (i = 0; i < nbars; i++, pos += 8) {
@@ -238,6 +241,9 @@ void pci_restore_rebar_state(struct pci_dev *pdev)
int bar_idx, size;
pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
+ if (PCI_POSSIBLE_ERROR(ctrl))
+ return;
+
bar_idx = ctrl & PCI_REBAR_CTRL_BAR_IDX;
res = pci_resource_n(pdev, bar_idx);
size = pci_rebar_bytes_to_size(resource_size(res));
--
2.47.3
^ permalink raw reply related
* Re: [PATCH net v3 3/5] iavf: send MAC change request synchronously
From: Przemek Kitszel @ 2026-04-17 13:05 UTC (permalink / raw)
To: Jose Ignacio Tornos Martinez
Cc: intel-wired-lan, anthony.l.nguyen, davem, edumazet, kuba, pabeni,
stable, netdev
In-Reply-To: <20260414110006.124286-4-jtornosm@redhat.com>
[-Jesse]
Thank you very much for working on this!
I see that we are going in good direction.
Please find some feedback inline.
> @@ -1067,26 +1107,13 @@ static int iavf_set_mac(struct net_device *netdev, void *p)
> return -EADDRNOTAVAIL;
>
> ret = iavf_replace_primary_mac(adapter, addr->sa_data);
> -
> if (ret)
> return ret;
>
> - ret = wait_event_interruptible_timeout(adapter->vc_waitqueue,
this was the only waiter on this waitqueue, please remove it entriely
> - iavf_is_mac_set_handled(netdev, addr->sa_data),
> - msecs_to_jiffies(2500));
> -
> - /* If ret < 0 then it means wait was interrupted.
> - * If ret == 0 then it means we got a timeout.
> - * else it means we got response for set MAC from PF,
> - * check if netdev MAC was updated to requested MAC,
> - * if yes then set MAC succeeded otherwise it failed return -EACCES
> - */
> - if (ret < 0)
> + ret = iavf_set_mac_sync(adapter, addr->sa_data);
> + if (ret)
> return ret;
>
> - if (!ret)
> - return -EAGAIN;
> -
> if (!ether_addr_equal(netdev->dev_addr, addr->sa_data))
> return -EACCES;
>
[..]
> +/**
> + * iavf_virtchnl_done - Check if virtchnl operation completed
> + * @adapter: board private structure
> + * @condition: optional callback for custom completion check
> + * (takes priority)
> + * @cond_data: context data for callback
> + * @v_opcode: virtchnl opcode value we're waiting for if no condition
> + * configured (typically VIRTCHNL_OP_UNKNOWN), if condition not used
> + *
> + * Checks completion status. Callback takes priority if provided. Otherwise
> + * waits for current_op to reach v_opcode (typically VIRTCHNL_OP_UNKNOWN
> + * after completion).
> + *
> + * Return: true if operation completed
> + */
> +static inline bool iavf_virtchnl_done(struct iavf_adapter *adapter,
> + bool (*condition)(struct iavf_adapter *, const void *),
> + const void *cond_data,
> + enum virtchnl_ops v_opcode)
> +{
> + if (condition)
> + return condition(adapter, cond_data);
> +
> + return adapter->current_op == v_opcode;
> +}
after seeing this and patch 5, I think that the changes to combine the
two polling functions together are too big for "a preparation for fix"
type of change - so I agree with others that this should be scoped out
off this series
that stands for iavf_virtchnl_done() too - there is no caller that wants
"some opcode" in patches 1-4
and it will be possible to just pass "wanted_opcode" as the current
param "const void *" of condition()
> +
> +/**
> + * iavf_poll_virtchnl_response - Poll admin queue for virtchnl response
> + * @adapter: board private structure
> + * @condition: optional callback to check if desired response received
> + * (takes priority)
> + * @cond_data: context data passed to condition callback
> + * @v_opcode: virtchnl opcode value to wait for if no condition configured
> + * (typically VIRTCHNL_OP_UNKNOWN), if condition, not used
> + * @timeout_ms: maximum time to wait in milliseconds
> + *
> + * Polls admin queue and processes all messages until condition returns true
> + * or timeout expires. If condition is NULL, waits for current_op to become
> + * v_opcode (typically VIRTCHNL_OP_UNKNOWN after operation completes).
> + * Caller must hold netdev_lock. This can sleep for up to timeout_ms while
> + * polling hardware.
> + *
> + * Return: 0 on success (condition met), -EAGAIN on timeout or error
> + */
> +int iavf_poll_virtchnl_response(struct iavf_adapter *adapter,
> + bool (*condition)(struct iavf_adapter *, const void *),
please add v_op from below as a param
nit: I would also name the params instead of using plain types, not sure
how easy it will be for kdoc... (so no pressure for that)
> + const void *cond_data,
> + enum virtchnl_ops v_opcode,
> + unsigned int timeout_ms)
> +{
> + struct iavf_hw *hw = &adapter->hw;
> + struct iavf_arq_event_info event;
> + enum virtchnl_ops v_op;
> + enum iavf_status v_ret;
> + unsigned long timeout;
> + u16 pending;
> + int ret;
> +
> + netdev_assert_locked(adapter->netdev);
> +
> + event.buf_len = IAVF_MAX_AQ_BUF_SIZE;
> + event.msg_buf = kzalloc(event.buf_len, GFP_KERNEL);
> + if (!event.msg_buf)
> + return -ENOMEM;
> +
> + timeout = jiffies + msecs_to_jiffies(timeout_ms);
> + do {
> + if (iavf_virtchnl_done(adapter, condition, cond_data, v_opcode)) {
> + ret = 0;
> + goto out;
> + }
> +
> + ret = iavf_clean_arq_element(hw, &event, &pending);
> + if (!ret) {
> + v_op = (enum virtchnl_ops)le32_to_cpu(event.desc.cookie_high);
comment about condition() signature:
I believe that condition() should take this @v_op
sidenote for patch5:
...@v_op instead of looking at adapter->current_op
> + v_ret = (enum iavf_status)le32_to_cpu(event.desc.cookie_low);
> +
> + iavf_virtchnl_completion(adapter, v_op, v_ret,
> + event.msg_buf, event.msg_len);
> +
> + memset(event.msg_buf, 0, IAVF_MAX_AQ_BUF_SIZE);
> +
> + if (pending)
> + continue;
please incorporate the condition() check with iavf_clean_arq_element()
response (to avoid processing all subsequent VC messages if condition()
was met already)
it's fine to pass 0 as "v_op" to condition() when there is no VC msg yet
> + }
> +
> + usleep_range(50, 75);
> + } while (time_before(jiffies, timeout));
> +
> + if (iavf_virtchnl_done(adapter, condition, cond_data, v_opcode))
> + ret = 0;
> + else
> + ret = -EAGAIN;
please change into just one call to condition(), and don't sleep between
the call and time_before() check (that will resolve my v2 concern)
> +
> +out:
> + kfree(event.msg_buf);
> + return ret;
> +}
^ permalink raw reply
* Re: [PATCH net v3 1/4] nfc: nci: fix u8 underflow in nci_store_general_bytes_nfc_dep
From: Simon Horman @ 2026-04-17 13:00 UTC (permalink / raw)
To: Lekë Hapçiu
Cc: netdev, davem, edumazet, kuba, pabeni, linux-kernel, stable,
Lekë Hapçiu
In-Reply-To: <20260414233534.55973-2-snowwlake@icloud.com>
On Wed, Apr 15, 2026 at 01:35:30AM +0200, Lekë Hapçiu wrote:
> From: Lekë Hapçiu <framemain@outlook.com>
>
> nci_store_general_bytes_nfc_dep() computes the General Bytes length by
> subtracting a fixed header offset from the peer-supplied atr_res_len
> (POLL) or atr_req_len (LISTEN) field:
>
> ndev->remote_gb_len = min_t(__u8,
> atr_res_len - NFC_ATR_RES_GT_OFFSET, /* offset = 15 */
> NFC_ATR_RES_GB_MAXSIZE);
>
> Both length fields are __u8. When a malicious NFC-DEP peer sends an
> ATR_RES/ATR_REQ whose length is smaller than the fixed offset (< 15
> or < 14 respectively), the subtraction wraps:
>
> atr_res_len = 0 -> (u8)(0 - 15) = 241
> min_t(__u8, 241, NFC_ATR_RES_GB_MAXSIZE=47) = 47
>
> The subsequent memcpy then reads 47 bytes beyond the valid activation
> parameter data into ndev->remote_gb[]. This buffer is later fed to
> nfc_llcp_parse_gb_tlv() as a TLV array.
>
> Reject the frame with NCI_STATUS_RF_PROTOCOL_ERROR when the length is
> below the required offset, and propagate the error out of
> nci_rf_intf_activated_ntf_packet() instead of silently accepting the
> malformed packet.
This does not seem to be consistent with the handling of other in
nci_rf_intf_activated_ntf_packet() when it calls other functions similar to
nci_rf_intf_activated_ntf_packet().
I suggest dropping this part of the fix, and addressing
nci_rf_intf_activated_ntf_packet() in a more holistic manner
if this kind of change is desired.
>
> Reachable from any NFC peer within ~4 cm during RF activation, prior
> to any pairing.
I do not understand how this statement relates to this change.
Could you explain?
>
> Fixes: c4fbb6515709 ("NFC: NCI: Add NFC-DEP support to NCI data exchange")
I am unable to find a commit with either that hash or subject.
It seems to me that this problem was introduced in:
767f19ae698e ("NFC: Implement NCI dep_link_up and dep_link_down")
--
pw-bot: changes-requested
^ permalink raw reply
* Re: [PATCH v3] Bluetooth: hci_bcm4377: validate firmware event length in completion ring
From: Neal Gompa @ 2026-04-17 12:55 UTC (permalink / raw)
To: Tristan Madani
Cc: linux-bluetooth, luiz.dentz, marcel, sven, marcan, asahi, stable
In-Reply-To: <20260417104639.2608008-1-tristmd@gmail.com>
On Fri, Apr 17, 2026 at 6:49 AM Tristan Madani <tristmd@gmail.com> wrote:
>
> From: Tristan Madani <tristan@talencesecurity.com>
>
> The firmware-controlled entry->len is used as the memcpy size for inline
> payload data without bounds checking when the PAYLOAD_MAPPED flag is not
> set. This causes out-of-bounds reads from the completion ring DMA memory
> for the HCI_D2H and SCO_D2H transfer rings.
>
> Add a length validation against the completion ring payload_size.
>
> Fixes: 8a06127602de ("Bluetooth: hci_bcm4377: Add new driver for BCM4377 PCIe boards")
> Cc: stable@vger.kernel.org
> Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
> ---
> drivers/bluetooth/hci_bcm4377.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/bluetooth/hci_bcm4377.c b/drivers/bluetooth/hci_bcm4377.c
> index 925d0a635..5d2f594c2 100644
> --- a/drivers/bluetooth/hci_bcm4377.c
> +++ b/drivers/bluetooth/hci_bcm4377.c
> @@ -755,6 +755,13 @@ static void bcm4377_handle_completion(struct bcm4377_data *bcm4377,
> msg_id = le16_to_cpu(entry->msg_id);
> transfer_ring = le16_to_cpu(entry->ring_id);
>
> + if (data_len > ring->payload_size) {
> + dev_warn(&bcm4377->pdev->dev,
> + "event data len %zu exceeds payload size %zu for ring %d\n",
> + data_len, ring->payload_size, ring->ring_id);
> + return;
> + }
> +
> if ((ring->transfer_rings & BIT(transfer_ring)) == 0) {
> dev_warn(
> &bcm4377->pdev->dev,
> --
> 2.47.3
>
>
Seems sensible enough.
Reviewed-by: Neal Gompa <neal@gompa.dev>
--
真実はいつも一つ！/ Always, there's only one truth!
^ permalink raw reply
* Re: [PATCH v2 0/2] hwtracing: hisi_ptt: Fix reset timeout handling and clean up trace start
From: Jonathan Cameron @ 2026-04-17 12:45 UTC (permalink / raw)
To: Pradhan, Sanman
Cc: yangyicong@hisilicon.com, alexander.shishkin@linux.intel.com,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
yangyccccc@gmail.com, Sanman Pradhan, Sizhe Liu
In-Reply-To: <20260414172451.14331-1-sanman.pradhan@hpe.com>
On Tue, 14 Apr 2026 17:25:03 +0000
"Pradhan, Sanman" <sanman.pradhan@hpe.com> wrote:
> From: Sanman Pradhan <psanman@juniper.net>
+CC Sizhe Liu
>
> Patch 1: Propagate the DMA reset timeout error from
> hisi_ptt_wait_dma_reset_done() instead of discarding it. De-assert
> the reset bit and log an error on timeout. Move ctrl->started to the
> successful path so a failed start does not leave the trace marked as
> active.
>
> Patch 2: Remove the unnecessary 16 MiB memset of trace buffers in
> hisi_ptt_trace_start(). The driver only copies data that hardware has
> written, so the zeroing is not needed.
>
> Changes since v1:
> - Patch 1: Return bool from hisi_ptt_wait_dma_reset_done() for
> consistency with the other wait helpers
> - Patch 1: Add pci_err() on timeout
> - Patch 1: De-assert RST before returning on timeout
> - Patch 1: Move ctrl->started to the successful path
> - Dropped "Use the passed buffer index in hisi_ptt_update_aux()" patch
> - Patch 2 is unchanged
>
> Sanman Pradhan (2):
> hwtracing: hisi_ptt: Propagate DMA reset timeout in trace_start()
> hwtracing: hisi_ptt: Remove unnecessary trace buffer zeroing in
> trace_start()
>
> drivers/hwtracing/ptt/hisi_ptt.c | 25 +++++++++++++------------
> 1 file changed, 13 insertions(+), 12 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v3 net] rose: fix OOB reads on short CLEAR REQUEST frames
From: Simon Horman @ 2026-04-17 12:02 UTC (permalink / raw)
To: Ashutosh Desai
Cc: netdev, linux-hams, davem, edumazet, kuba, pabeni, stable,
linux-kernel
In-Reply-To: <20260415055756.3825584-1-ashutoshdesai993@gmail.com>
On Wed, Apr 15, 2026 at 05:57:56AM +0000, Ashutosh Desai wrote:
> rose_process_rx_frame() calls rose_decode() which reads skb->data[2]
> without any prior length check. For CLEAR REQUEST frames the state
> machines then read skb->data[3] and skb->data[4] as the cause and
> diagnostic bytes.
>
> A crafted 3-byte ROSE CLEAR REQUEST frame passes the minimum length
> gate in rose_route_frame() and reaches rose_process_rx_frame(), where
> rose_decode() reads one byte past the header and the state machines
> read two bytes past the valid buffer. A remote peer can exploit this
> to leak kernel memory contents or trigger a kernel panic.
>
> Add a pskb_may_pull(skb, 3) check before rose_decode() to cover its
> skb->data[2] access, and a pskb_may_pull(skb, 5) check afterwards for
> the CLEAR REQUEST path to cover the cause and diagnostic reads.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: stable@vger.kernel.org
> Signed-off-by: Ashutosh Desai <ashutoshdesai993@gmail.com>
> ---
> V2 -> V3: drop kfree_skb() calls to fix double-free; add end-user
> visible symptom to commit log; use [net] subject prefix
> V1 -> V2: switch skb->len check to pskb_may_pull; add pskb_may_pull(skb, 3)
> before rose_decode() to cover its skb->data[2] access
>
> v2: https://lore.kernel.org/netdev/177614667427.3606651.8700070406932922261@gmail.com/
> v1: https://lore.kernel.org/netdev/20260409013246.2051746-1-ashutoshdesai993@gmail.com/
Unfortunately this conflicts with a recent commit, which I believe
addresses the same problem: commit 2835750dd647 ("net: rose: reject
truncated CLEAR_REQUEST frames in state machines")
I do, however, note that commit doesn't use pskb_may_pull.
So perhaps you could make an incremental change to add that.
Also, FTR, Sashiko has quite a few things to say about other problems
in this and adjacent code.
^ permalink raw reply
* Re: [PATCH rc v2 0/5] iommu/arm-smmu-v3: Fix device crash on kdump kernel
From: Jason Gunthorpe @ 2026-04-17 11:59 UTC (permalink / raw)
To: Tian, Kevin
Cc: Robin Murphy, Nicolin Chen, will@kernel.org, joro@8bytes.org,
praan@google.com, baolu.lu@linux.intel.com,
miko.lenczewski@arm.com, smostafa@google.com,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
jamien@nvidia.com
In-Reply-To: <BN9PR11MB5276A13A8014C5C6403FB4EC8C202@BN9PR11MB5276.namprd11.prod.outlook.com>
On Fri, Apr 17, 2026 at 07:48:46AM +0000, Tian, Kevin wrote:
> is there any report on such systems? It might be informational to include
> a link to the report so it's clear that this series fixes real issues instead of
> a preparation for coming systems...
Yeah, we have an internal report and this was confirmed to fix it.
> btw the DMA is allowed after the previous kernel is hung til the point
> where smmu driver blocks it. In cases where in-fly DMAs are considered
> dangerous to kdump, this series just make it worse instead of creating
> a new issue. While for majority other failures not related to DMAs,
> unblocking then increases the chance of success...
Right, exactly.
If DMA's are splattering over the kdump carve out memory its is
probably dead no matter what.
Jason
^ permalink raw reply
* Re: [PATCH iwl-net v2] igc: fix potential skb leak in igc_fpe_xmit_smd_frame()
From: Simon Horman @ 2026-04-17 11:51 UTC (permalink / raw)
To: Kohei Enju
Cc: intel-wired-lan, netdev, Tony Nguyen, Przemek Kitszel,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Faizal Rahim, kohei.enju, stable
In-Reply-To: <20260415025226.114115-1-kohei@enjuk.jp>
On Wed, Apr 15, 2026 at 02:52:18AM +0000, Kohei Enju wrote:
> When igc_fpe_init_tx_descriptor() fails, no one takes care of an
> allocated skb, leaking it. [1]
> Use dev_kfree_skb_any() on failure.
>
> Tested on an I226 adapter with the following command, while injecting
> faults in igc_fpe_init_tx_descriptor() to trigger the error path.
> # ethtool --set-mm $DEV verify-enabled on tx-enabled on pmac-enabled on
>
> [1]
> unreferenced object 0xffff888113c6cdc0 (size 224):
> ...
> backtrace (crc be3d3fda):
> kmem_cache_alloc_node_noprof+0x3b1/0x410
> __alloc_skb+0xde/0x830
> igc_fpe_xmit_smd_frame.isra.0+0xad/0x1b0
> igc_fpe_send_mpacket+0x37/0x90
> ethtool_mmsv_verify_timer+0x15e/0x300
>
> Cc: stable@vger.kernel.org
> Fixes: 5422570c0010 ("igc: add support for frame preemption verification")
> Signed-off-by: Kohei Enju <kohei@enjuk.jp>
> ---
> Changes:
> v2:
> - change to idiomatic style with goto (Simon)
> - add Cc to stable (Alex)
> - add reprodunction steps (Alex)
> v1: https://lore.kernel.org/all/20260329145122.126040-1-kohei@enjuk.jp/
Thanks for the update.
Reviewed-by: Simon Horman <horms@kernel.org>
Sashiko has comments about a potential existing bug in the same code path.
I'd appreciate it if, as a follow-up, you could look over that.
Thanks!
^ permalink raw reply
* RE: [PATCH] tipc: crypto: require a NUL-terminated AEAD algorithm name
From: Tung Quang Nguyen @ 2026-04-17 11:25 UTC (permalink / raw)
To: Pengpeng Hou
Cc: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
netdev@vger.kernel.org, tipc-discussion@lists.sourceforge.net,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
David S. Miller, Jon Maloy
In-Reply-To: <20260417075353.30662-1-pengpeng@iscas.ac.cn>
>Subject: [PATCH] tipc: crypto: require a NUL-terminated AEAD algorithm name
>
>struct tipc_aead_key carries alg_name in a fixed 32-byte field, but both the
>generic netlink validation path and the MSG_CRYPTO receive path pass that
>field straight to crypto_has_alg(), strcmp(), and
>crypto_alloc_aead() without first proving that it contains a terminating NUL.
>
This is not correct. TIPC guarantees the algorithm string is nul-terminated one.
>Reject locally supplied and received keys whose algorithm name fills the entire
>fixed-width field without a terminator.
>
>Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication")
>Cc: stable@vger.kernel.org
>
>Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
>---
> net/tipc/crypto.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
>diff --git a/net/tipc/crypto.c b/net/tipc/crypto.c index
>6d3b6b89b1d1..60110ea0fe7c 100644
>--- a/net/tipc/crypto.c
>+++ b/net/tipc/crypto.c
>@@ -307,6 +307,11 @@ static void tipc_crypto_work_tx(struct work_struct
>*work); static void tipc_crypto_work_rx(struct work_struct *work); static int
>tipc_aead_key_generate(struct tipc_aead_key *skey);
>
>+static bool tipc_aead_alg_name_valid(const char *alg_name) {
>+ return strnlen(alg_name, TIPC_AEAD_ALG_NAME) <
>TIPC_AEAD_ALG_NAME; }
>+
This is not needed because TIPC only supports one algorithm name "gcm(aes)" which is 8-byte length.
> #define is_tx(crypto) (!(crypto)->node) #define is_rx(crypto) (!is_tx(crypto))
>
>@@ -335,6 +340,11 @@ int tipc_aead_key_validate(struct tipc_aead_key
>*ukey, struct genl_info *info) {
> int keylen;
>
>+ if (unlikely(!tipc_aead_alg_name_valid(ukey->alg_name))) {
>+ GENL_SET_ERR_MSG(info, "algorithm name is not NUL-
>terminated");
>+ return -EINVAL;
>+ }
>+
This is not needed because the system guarantees that the string passed from user-space is nul-terminated one.
> /* Check if algorithm exists */
> if (unlikely(!crypto_has_alg(ukey->alg_name, 0, 0))) {
> GENL_SET_ERR_MSG(info, "unable to load the algorithm
>(module existed?)"); @@ -2298,6 +2308,10 @@ static bool
>tipc_crypto_key_rcv(struct tipc_crypto *rx, struct tipc_msg *hdr)
> pr_debug("%s: invalid MSG_CRYPTO key size\n", rx->name);
> goto exit;
> }
>+ if (unlikely(!tipc_aead_alg_name_valid(data))) {
>+ pr_debug("%s: invalid MSG_CRYPTO algorithm name\n", rx-
>>name);
>+ goto exit;
>+ }
This is not needed as explained above.
>
> spin_lock(&rx->lock);
> if (unlikely(rx->skey || (key_gen == rx->key_gen && rx->key.keys))) {
>--
>2.50.1 (Apple Git-155)
>
^ 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