* Re: [PATCH] ARM: io: avoid KASAN instrumentation of raw halfword I/O
From: Karl Mehltretter @ 2026-05-24 8:09 UTC (permalink / raw)
To: Linus Walleij
Cc: Russell King, Abbott Liu, Ard Biesheuvel, Florian Fainelli,
linux-arm-kernel, linux-kernel, stable
In-Reply-To: <CAD++jL=jrk4EYo+5mhp1cpy2cfsA966MVmbohWhcZdx_SObD_w@mail.gmail.com>
On Sun, May 24, 2026 at 12:11:36AM +0100, Linus Walleij wrote:
> Please put this patch into Russell's patch tracker.
Done: https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9474/1
Thanks,
Karl
^ permalink raw reply
* Re: [PATCH] ARM: entry: use byte load for KASAN VMAP stack shadow
From: Karl Mehltretter @ 2026-05-24 7:49 UTC (permalink / raw)
To: Linus Walleij
Cc: Russell King, Russell King (Oracle), linux-arm-kernel,
linux-kernel, stable
In-Reply-To: <CAD++jLnhONOMn=7hG-EC_uB80nxXfAnRMuZC2xoJjf2Xzcaiuw@mail.gmail.com>
On Sun, May 24, 2026 at 12:08:57AM +0100, Linus Walleij wrote:
> Please put this patch into Russell's patch tracker.
Done: https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9475/1
Thanks,
Karl
^ permalink raw reply
* [PATCH net] octeontx2-af: cn10k: restrict LMTLINE sharing to same PF
From: Junrui Luo @ 2026-05-24 7:29 UTC (permalink / raw)
To: Sunil Goutham, Linu Cherian, Geetha sowjanya, hariprasad,
Subbaraya Sundeep, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: netdev, linux-kernel, Yuhao Jiang, stable, Junrui Luo
rvu_mbox_handler_lmtst_tbl_setup() uses req->base_pcifunc as a direct
index into the LMT map table to read another function's LMTLINE
physical base address and copy it into the caller's own LMT map table
entry. The mailbox dispatcher authenticates req->hdr.pcifunc from the
IRQ source, but req->base_pcifunc is a separate payload field and is
not sanitized.
Reject the request with -EPERM when the caller and base function do
not share a parent PF.
Fixes: 893ae97214c3 ("octeontx2-af: cn10k: Support configurable LMTST regions")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
---
drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c
index d2163da28d18..0c27b4b669f1 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c
@@ -178,6 +178,13 @@ int rvu_mbox_handler_lmtst_tbl_setup(struct rvu *rvu,
* pcifunc (will be the one who is calling this mailbox).
*/
if (req->base_pcifunc) {
+ /* Only allow LMTLINE sharing within the same PF, so that a
+ * PCI function cannot hijack another PF's LMTLINE region.
+ */
+ if (rvu_get_pf(rvu->pdev, req->hdr.pcifunc) !=
+ rvu_get_pf(rvu->pdev, req->base_pcifunc))
+ return -EPERM;
+
/* Calculating the LMT table index equivalent to primary
* pcifunc.
*/
---
base-commit: c369299895a591d96745d6492d4888259b004a9e
change-id: 20260524-fixes-33bb6d8cccf8
Best regards,
--
Junrui Luo <moonafterrain@outlook.com>
^ permalink raw reply related
* [PATCH v2] uio: fix IRQ vector leak on probe failure and remove
From: Guangshuo Li @ 2026-05-24 6:42 UTC (permalink / raw)
To: Greg Kroah-Hartman, Yaxing Guo, linux-kernel; +Cc: Guangshuo Li, stable
probe() allocates MSI/MSI-X vectors with pci_alloc_irq_vectors(), but
neither the error path nor remove() releases them with
pci_free_irq_vectors().
Unlike drivers using pcim_enable_device(), this driver uses
pci_enable_device(), so the IRQ vectors are not managed automatically
and must be freed explicitly.
Add pci_free_irq_vectors() to the probe error path after successful
vector allocation and to remove(). The issue was identified by a
static analysis tool I developed.
Fixes: 3397c3cd859a ("uio: Add SVA support for PCI devices via uio_pci_generic_sva.c")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
v2:
- Change have_irq_vectors from int to bool.
- Set have_irq_vectors immediately after successful IRQ vector allocation.
drivers/uio/uio_pci_generic_sva.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/uio/uio_pci_generic_sva.c b/drivers/uio/uio_pci_generic_sva.c
index 4a46acd994a8..e216436c9116 100644
--- a/drivers/uio/uio_pci_generic_sva.c
+++ b/drivers/uio/uio_pci_generic_sva.c
@@ -63,6 +63,7 @@ static int probe(struct pci_dev *pdev, const struct pci_device_id *id)
{
struct uio_pci_sva_dev *udev;
int ret, i, irq = 0;
+ bool have_irq_vectors = false;
ret = pci_enable_device(pdev);
if (ret) {
@@ -78,6 +79,8 @@ static int probe(struct pci_dev *pdev, const struct pci_device_id *id)
ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_MSIX | PCI_IRQ_MSI);
if (ret > 0) {
+ have_irq_vectors = true;
+
irq = pci_irq_vector(pdev, 0);
if (irq < 0) {
dev_err(&pdev->dev, "Failed to get MSI vector\n");
@@ -139,6 +142,8 @@ static int probe(struct pci_dev *pdev, const struct pci_device_id *id)
out_free:
kfree(udev);
out_disable:
+ if (have_irq_vectors)
+ pci_free_irq_vectors(pdev);
pci_disable_device(pdev);
return ret;
@@ -148,6 +153,7 @@ static void remove(struct pci_dev *pdev)
{
struct uio_pci_sva_dev *udev = pci_get_drvdata(pdev);
+ pci_free_irq_vectors(pdev);
pci_release_regions(pdev);
pci_disable_device(pdev);
kfree(udev);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] uio: fix IRQ vector leak on probe failure and remove
From: Guangshuo Li @ 2026-05-24 6:29 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Yaxing Guo, linux-kernel, stable
In-Reply-To: <2026052229-overspend-preoccupy-2f6f@gregkh>
Hi Greg,
Thank you for reviewing the patch.
On Fri, 22 May 2026 at 18:03, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Thu, Apr 16, 2026 at 11:54:43PM +0800, Guangshuo Li wrote:
> > probe() allocates MSI/MSI-X vectors with pci_alloc_irq_vectors(), but
> > neither the error path nor remove() releases them with
> > pci_free_irq_vectors().
> >
> > Unlike drivers using pcim_enable_device(), this driver uses
> > pci_enable_device(), so the IRQ vectors are not managed automatically
> > and must be freed explicitly.
> >
> > Add pci_free_irq_vectors() to the probe error path after successful
> > vector allocation and to remove(). The issue was identified by a
> > static analysis tool I developed.
> >
> > Fixes: 3397c3cd859a ("uio: Add SVA support for PCI devices via uio_pci_generic_sva.c")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> > ---
> > drivers/uio/uio_pci_generic_sva.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/uio/uio_pci_generic_sva.c b/drivers/uio/uio_pci_generic_sva.c
> > index 4a46acd994a8..ea531f9a164c 100644
> > --- a/drivers/uio/uio_pci_generic_sva.c
> > +++ b/drivers/uio/uio_pci_generic_sva.c
> > @@ -62,7 +62,7 @@ static int uio_pci_sva_release(struct uio_info *info, struct inode *inode)
> > static int probe(struct pci_dev *pdev, const struct pci_device_id *id)
> > {
> > struct uio_pci_sva_dev *udev;
> > - int ret, i, irq = 0;
> > + int ret, i, irq = 0, have_irq_vectors = 0;
>
> have_irq_vectors should be a bool.
I will change have_irq_vectors to a bool and send a v2.
Best regards,
Guangshuo
^ permalink raw reply
* Re: [PATCH net v3] xfrm: iptfs: preserve shared-frag marker in iptfs_consume_frags()
From: Christian Hopps @ 2026-05-24 6:19 UTC (permalink / raw)
To: Takao Sato; +Cc: netdev, steffen.klassert, w, davem, herbert, stable
In-Reply-To: <20260522142504.1394864-1-takaosato1997@gmail.com>
Takao Sato <takaosato1997@gmail.com> writes:
> iptfs_consume_frags() transfers paged fragments from one socket buffer
> to another but fails to propagate the SKBFL_SHARED_FRAG flag. This is
> the same class of bug that was fixed in skb_try_coalesce() for
> CVE-2026-46300: when fragments backed by read-only page-cache pages are
> merged, the marker indicating their shared nature must be preserved so
> that ESP can decide correctly whether in-place encryption is safe.
>
> Apply the same two-line fix used in skb_try_coalesce() to
> iptfs_consume_frags().
>
> Fixes: b96ba312e21c ("xfrm: iptfs: share page fragments of inner packets")
> Cc: stable@vger.kernel.org # 6.8+
> Signed-off-by: Takao Sato <takaosato1997@gmail.com>
> ---
> net/xfrm/xfrm_iptfs.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/xfrm/xfrm_iptfs.c b/net/xfrm/xfrm_iptfs.c
> index 97bc979e5..4db85e158 100644
> --- a/net/xfrm/xfrm_iptfs.c
> +++ b/net/xfrm/xfrm_iptfs.c
> @@ -2168,6 +2168,8 @@ static void iptfs_consume_frags(struct sk_buff *to, struct sk_buff *from)
> memcpy(&toi->frags[toi->nr_frags], fromi->frags,
> sizeof(fromi->frags[0]) * fromi->nr_frags);
> toi->nr_frags += fromi->nr_frags;
> + if (fromi->nr_frags)
> + toi->flags |= fromi->flags & SKBFL_SHARED_FRAG;
> fromi->nr_frags = 0;
> from->data_len = 0;
> from->len = 0;
LGTM, Thanks!
Reviewed-by: Christian Hopps <chopps@labn.net>
^ permalink raw reply
* Re: [PATCH] USB: iowarrior: fix use-after-free on disconnect
From: Greg Kroah-Hartman @ 2026-05-24 6:09 UTC (permalink / raw)
To: Johan Hovold
Cc: Joseph Bursey, linux-usb, linux-kernel,
syzbot+ad2aac2febc3bedf0962, stable
In-Reply-To: <20260523170523.1074563-1-johan@kernel.org>
On Sat, May 23, 2026 at 07:05:23PM +0200, Johan Hovold wrote:
> Submitted write URBs are not stopped on close() and therefore need to be
> stopped unconditionally on disconnect() to avoid use-after-free in the
> completion handler.
>
> Fixes: b5f8d46867ca ("USB: iowarrior: fix use-after-free after driver unbind")
> Fixes: 946b960d13c1 ("USB: add driver for iowarrior devices.")
> Reported-by: syzbot+ad2aac2febc3bedf0962@syzkaller.appspotmail.com
> Link: https://lore.kernel.org/all/6a0ce39b.170a0220.39a13.0007.GAE@google.com/
> Cc: stable@vger.kernel.org
> Signed-off-by: Johan Hovold <johan@kernel.org>
> ---
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* [PATCH v2] accel/ethosu: fix integer overflow and underflow in dma_length()
From: Muhammad Bilal @ 2026-05-24 6:06 UTC (permalink / raw)
To: robh
Cc: tomeu, ogabbay, tzimmermann, Frank.Li, dri-devel, linux-kernel,
stable, Muhammad Bilal
In-Reply-To: <20260524051659.70654-1-meatuni001@gmail.com>
dma_length() computes the total DMA transfer length as:
len = ((len + stride[0]) * size0 + stride[1]) * size1
where len and stride[] are 64-bit values derived from user-supplied
40-bit command stream fields, and size0/size1 are user-supplied u16
values.
Two bugs exist:
1. Integer overflow: the final multiplication by size1 (up to 65535)
on an intermediate result that can already be ~2^55 easily exceeds
2^64, wrapping the u64 result to a small positive value. This
wrapped value passes the region_size[i] <= gem->size check in
ethosu_job.c while the hardware executes DMA with the original
large strides, accessing memory outside the GEM buffer.
2. Negative stride underflow: stride[0] and stride[1] are signed
64-bit values sign-extended from 40-bit user input, and can be
negative. Adding a large negative stride to a small u64 len wraps
to a huge value. With size0 or size1 == 1, check_mul_overflow()
does not trigger, and len + offset can wrap back to a small value,
bypassing the bounds check while the hardware accesses memory below
the GEM buffer base.
3. Missing caller check: dma_length() returned U64_MAX on error but
the caller only used the result for dev_dbg(), never checking for
U64_MAX. This left info->region_size[] at 0, causing ethosu_job.c
to skip the region entirely and allow hardware to run with stale
physical addresses.
Fix by adding underflow checks before each stride addition, replacing
the unchecked multiplications with check_mul_overflow(), and adding
a U64_MAX check in the caller that returns -EINVAL.
Fixes: 5a5e9c0228e6 ("accel: Add Arm Ethos-U NPU driver")
Cc: stable@vger.kernel.org
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
---
drivers/accel/ethosu/ethosu_gem.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/accel/ethosu/ethosu_gem.c b/drivers/accel/ethosu/ethosu_gem.c
index 5a02285a4986..0383b7a6c3d3 100644
--- a/drivers/accel/ethosu/ethosu_gem.c
+++ b/drivers/accel/ethosu/ethosu_gem.c
@@ -2,6 +2,7 @@
/* Copyright 2025 Arm, Ltd. */
#include <linux/err.h>
+#include <linux/overflow.h>
#include <linux/slab.h>
#include <drm/ethosu_accel.h>
@@ -164,12 +165,18 @@ static u64 dma_length(struct ethosu_validated_cmdstream_info *info,
u64 len = dma->len;
if (mode >= 1) {
+ if (dma->stride[0] < 0 && (u64)(-dma->stride[0]) > len)
+ return U64_MAX;
len += dma->stride[0];
- len *= dma_st->size0;
+ if (check_mul_overflow(len, (u64)dma_st->size0, &len))
+ return U64_MAX;
}
if (mode == 2) {
+ if (dma->stride[1] < 0 && (u64)(-dma->stride[1]) > len)
+ return U64_MAX;
len += dma->stride[1];
- len *= dma_st->size1;
+ if (check_mul_overflow(len, (u64)dma_st->size1, &len))
+ return U64_MAX;
}
if (dma->region >= 0)
info->region_size[dma->region] = max(info->region_size[dma->region],
@@ -397,6 +404,8 @@ static int ethosu_gem_cmdstream_copy_and_validate(struct drm_device *ddev,
case NPU_OP_DMA_START:
srclen = dma_length(info, &st.dma, &st.dma.src);
dstlen = dma_length(info, &st.dma, &st.dma.dst);
+ if (srclen == U64_MAX || dstlen == U64_MAX)
+ return -EINVAL;
if (st.dma.dst.region >= 0)
info->output_region[st.dma.dst.region] = true;
--
2.53.0
^ permalink raw reply related
* [PATCH] accel/ethosu: fix integer overflow in dma_length()
From: Muhammad Bilal @ 2026-05-24 5:16 UTC (permalink / raw)
To: robh
Cc: tomeu, ogabbay, tzimmermann, Frank.Li, dri-devel, linux-kernel,
stable, Muhammad Bilal
dma_length() computes the total DMA transfer length as:
len = ((len + stride[0]) * size0 + stride[1]) * size1
where len and stride[] are 64-bit values derived from user-supplied
40-bit command stream fields, and size0/size1 are user-supplied u16
values.
The final multiplication by size1 (up to 65535) on an intermediate
result that can already be ~2^55 easily exceeds 2^64, wrapping the
u64 result to a small positive value.
This wrapped value is then stored in info->region_size[] and compared
against gem->size in ethosu_job.c:
if (cmd_info->region_size[i] > gem->size)
return -EOVERFLOW;
A userspace caller can craft stride and size values so that the
calculated length wraps to zero or a small value, passing this check
while the hardware executes a DMA transfer with the original large
strides, accessing memory far outside the GEM buffer.
Fix by replacing the unchecked multiplications with
check_mul_overflow(), returning U64_MAX on overflow. The callers
of dma_length() already treat U64_MAX as an error sentinel.
Fixes: 5a5e9c0228e6 ("accel: Add Arm Ethos-U NPU driver")
Cc: stable@vger.kernel.org
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
---
drivers/accel/ethosu/ethosu_gem.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/accel/ethosu/ethosu_gem.c b/drivers/accel/ethosu/ethosu_gem.c
index 5a02285a4986..1f132611a6ce 100644
--- a/drivers/accel/ethosu/ethosu_gem.c
+++ b/drivers/accel/ethosu/ethosu_gem.c
@@ -2,6 +2,7 @@
/* Copyright 2025 Arm, Ltd. */
#include <linux/err.h>
+#include <linux/overflow.h>
#include <linux/slab.h>
#include <drm/ethosu_accel.h>
@@ -165,11 +166,13 @@ static u64 dma_length(struct ethosu_validated_cmdstream_info *info,
if (mode >= 1) {
len += dma->stride[0];
- len *= dma_st->size0;
+ if (check_mul_overflow(len, (u64)dma_st->size0, &len))
+ return U64_MAX;
}
if (mode == 2) {
len += dma->stride[1];
- len *= dma_st->size1;
+ if (check_mul_overflow(len, (u64)dma_st->size1, &len))
+ return U64_MAX;
}
if (dma->region >= 0)
info->region_size[dma->region] = max(info->region_size[dma->region],
--
2.53.0
^ permalink raw reply related
* [PATCH net v2 4/4] netlabel: validate CIPSO option against skb tail in netlbl_skbuff_getattr
From: Qi Tang @ 2026-05-24 4:14 UTC (permalink / raw)
To: davem, kuba, pabeni, edumazet
Cc: netdev, fw, lyutoon, stable, Qi Tang, Paul Moore, Simon Horman,
linux-security-module
In-Reply-To: <20260524041442.2432071-1-tpluszz77@gmail.com>
netlbl_skbuff_getattr() locates the CIPSO option in the IPv4 IP header
via cipso_v4_optptr() and hands the bare pointer to cipso_v4_getattr().
The consumer re-reads cipso[1] (option length), cipso[6] (tag type),
and then cipso_v4_parsetag_*() re-reads further bytes from the skb.
__ip_options_compile() validates these bytes only at parse time. An
nftables LOCAL_IN payload write reachable from an unprivileged user
namespace can rewrite them after parse and before the SELinux/Smack
peer-label consume path (selinux_sock_rcv_skb_compat ->
selinux_netlbl_sock_rcv_skb -> netlbl_skbuff_getattr). This is the
IPv4 analogue of the CALIPSO IPv6 trust-after-modification fixed in
the previous patch: the tag parsers walk the option using attacker-
controlled length bytes, producing slab-out-of-bounds reads whose
contents feed into the MLS access decision.
Validate the option fits within skb_tail_pointer(skb) before invoking
cipso_v4_getattr(). The pre-tag-walk guard "ptr + 8 > tail" covers
the CIPSO option header (type + length + DOI = 6 bytes) plus the
first tag header (type + length = 2 bytes), which are the bytes
cipso_v4_getattr() reads to dispatch on the tag. When the bounds
check fails the packet has been mutated after parse, so return
-EINVAL rather than fall through to the unlabeled path.
Runtime confirmation (Smack peer-label policy + nft LOCAL_IN
mutation of tag_len): UdpInDatagrams increments to 1 and recvfrom
returns the payload, showing netlbl_skbuff_getattr ->
cipso_v4_getattr -> cipso_v4_parsetag_rbm -> netlbl_bitmap_walk runs
end-to-end past the option's true bound; with this patch the
consume path returns -EINVAL at the bounds check and the counter
stays 0.
Cc: stable@vger.kernel.org
Reported-by: Qi Tang <tpluszz77@gmail.com>
Reported-by: Tong Liu <lyutoon@gmail.com>
Fixes: 04f81f0154e4 ("cipso: don't use IPCB() to locate the CIPSO IP option")
Signed-off-by: Qi Tang <tpluszz77@gmail.com>
---
net/netlabel/netlabel_kapi.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/net/netlabel/netlabel_kapi.c b/net/netlabel/netlabel_kapi.c
index d0d6220b8d59d..c2d3ea751f4e1 100644
--- a/net/netlabel/netlabel_kapi.c
+++ b/net/netlabel/netlabel_kapi.c
@@ -1393,11 +1393,24 @@ int netlbl_skbuff_getattr(const struct sk_buff *skb,
unsigned char *ptr;
switch (family) {
- case AF_INET:
+ case AF_INET: {
+ const unsigned char *tail = skb_tail_pointer(skb);
+ u8 opt_len, tag_len;
+
ptr = cipso_v4_optptr(skb);
- if (ptr && cipso_v4_getattr(ptr, secattr) == 0)
+ if (!ptr)
+ break;
+ /* CIPSO header (type+len+DOI = 6) + first tag header (type+len = 2) */
+ if (ptr + 8 > tail)
+ return -EINVAL;
+ opt_len = ptr[1]; /* total CIPSO option length */
+ tag_len = ptr[7]; /* first tag length */
+ if (ptr + opt_len > tail || ptr + 6 + tag_len > tail)
+ return -EINVAL;
+ if (cipso_v4_getattr(ptr, secattr) == 0)
return 0;
break;
+ }
#if IS_ENABLED(CONFIG_IPV6)
case AF_INET6: {
const unsigned char *tail = skb_tail_pointer(skb);
--
2.47.3
^ permalink raw reply related
* [PATCH net v2 3/4] netlabel: validate CALIPSO option against skb tail in netlbl_skbuff_getattr
From: Qi Tang @ 2026-05-24 4:14 UTC (permalink / raw)
To: davem, kuba, pabeni, edumazet
Cc: netdev, fw, lyutoon, stable, Qi Tang, Paul Moore, Simon Horman,
Huw Davies, linux-security-module
In-Reply-To: <20260524041442.2432071-1-tpluszz77@gmail.com>
netlbl_skbuff_getattr() locates the CALIPSO option in the IPv6 HBH
header via calipso_optptr() and hands the bare pointer to
calipso_getattr() -> calipso_opt_getattr(). The consumer re-reads
calipso[1] (option data length) and calipso[6] (cat_len/4) and walks
calipso + 10 for cat_len bytes via netlbl_bitmap_walk().
ipv6_hop_calipso() validates these bytes only at parse time inside
ipv6_parse_hopopts(). An nftables PRE_ROUTING payload write reachable
from an unprivileged user namespace can rewrite both bytes between
parse and the SELinux peer-label consume path
(selinux_sock_rcv_skb_compat -> selinux_netlbl_sock_rcv_skb ->
netlbl_skbuff_getattr). The self-consistency check
(cat_len + 8 > len) inside calipso_opt_getattr() is defeated by
mutating both bytes consistently, allowing a ~232-byte
slab-out-of-bounds read from calipso + 10 whose set bits become MLS
categories driving the access decision.
netlbl_skbuff_getattr() has the skb; gate the consume on the option
fitting within skb_tail_pointer(). The IPv6 option layout is
type(1) + length(1) + length bytes of data, so requiring
ptr + 2 + ptr[1] <= skb_tail covers the option and its embedded
bitmap. When the bounds check fails the packet has been mutated
after parse, so return -EINVAL rather than fall through to the
unlabeled path.
Runtime confirmation (SELinux compat path with selinux=1 enforcing=0
and a CALIPSO DOI added via netlabelctl): Udp6InDatagrams increments
to 1 with the mutated cat_len, showing
selinux_socket_sock_rcv_skb -> netlbl_skbuff_getattr ->
calipso_opt_getattr -> netlbl_bitmap_walk runs end-to-end past the
option's true bound; with this patch the consume path returns
-EINVAL at the bounds check and the counter stays 0.
Cc: stable@vger.kernel.org
Reported-by: Qi Tang <tpluszz77@gmail.com>
Reported-by: Tong Liu <lyutoon@gmail.com>
Fixes: 2917f57b6bc1 ("calipso: Allow the lsm to label the skbuff directly.")
Signed-off-by: Qi Tang <tpluszz77@gmail.com>
---
net/netlabel/netlabel_kapi.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/net/netlabel/netlabel_kapi.c b/net/netlabel/netlabel_kapi.c
index 3583fa63dd01f..d0d6220b8d59d 100644
--- a/net/netlabel/netlabel_kapi.c
+++ b/net/netlabel/netlabel_kapi.c
@@ -1399,11 +1399,22 @@ int netlbl_skbuff_getattr(const struct sk_buff *skb,
return 0;
break;
#if IS_ENABLED(CONFIG_IPV6)
- case AF_INET6:
+ case AF_INET6: {
+ const unsigned char *tail = skb_tail_pointer(skb);
+ u8 opt_data_len;
+
ptr = calipso_optptr(skb);
- if (ptr && calipso_getattr(ptr, secattr) == 0)
+ if (!ptr)
+ break;
+ if (ptr + 2 > tail)
+ return -EINVAL;
+ opt_data_len = ptr[1]; /* IPv6 option data length */
+ if (ptr + 2 + opt_data_len > tail)
+ return -EINVAL;
+ if (calipso_getattr(ptr, secattr) == 0)
return 0;
break;
+ }
#endif /* IPv6 */
}
--
2.47.3
^ permalink raw reply related
* [PATCH net v2 2/4] ipv4: ipmr: clamp ip_hdrlen against skb_headlen in ipmr_cache_report
From: Qi Tang @ 2026-05-24 4:14 UTC (permalink / raw)
To: davem, kuba, pabeni, edumazet
Cc: netdev, fw, lyutoon, stable, Qi Tang, David Ahern, Ido Schimmel,
Simon Horman
In-Reply-To: <20260524041442.2432071-1-tpluszz77@gmail.com>
ipmr_cache_report() copies ip_hdrlen(pkt) bytes from pkt->data into
a freshly allocated 128-byte skb that is delivered to userspace via
the mrouted IGMP raw socket and via igmpmsg_netlink_event:
const int ihl = ip_hdrlen(pkt);
...
skb_put(skb, ihl);
skb_copy_to_linear_data(skb, pkt->data, ihl);
ip_rcv_core() validates iph->ihl and pskb_may_pull()s ihl*4 bytes at
parse time. An nftables PRE_ROUTING payload write reachable from an
unprivileged user namespace can flip the ihl nibble from 5 to 15
between parse and ipmr_cache_report(). When the original skb is
non-linear (received via a NIC driver that uses paged frags), only
the parse-time ihl*4 = 20 bytes are in the linear region; the
consumer copies 60 bytes, and the extra 40 bytes are read from
skb_shared_info or adjacent slab memory and queued back to userspace,
a kernel heap-content infoleak. PoC observation: recvfrom on the
mroute socket returns 28 bytes without mutation, 68 bytes with
mutation (40 extra bytes leaked).
Clamp ihl against skb_headlen(pkt) so only bytes actually present
in the linear region are copied.
Cc: stable@vger.kernel.org
Reported-by: Qi Tang <tpluszz77@gmail.com>
Reported-by: Tong Liu <lyutoon@gmail.com>
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Qi Tang <tpluszz77@gmail.com>
---
net/ipv4/ipmr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index 2628cd3a93a68..b40f3dd8f650f 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -1056,7 +1056,7 @@ static void ipmr_cache_resolve(struct net *net, struct mr_table *mrt,
static int ipmr_cache_report(const struct mr_table *mrt,
struct sk_buff *pkt, vifi_t vifi, int assert)
{
- const int ihl = ip_hdrlen(pkt);
+ const int ihl = min_t(int, ip_hdrlen(pkt), skb_headlen(pkt));
struct sock *mroute_sk;
struct igmphdr *igmp;
struct igmpmsg *msg;
--
2.47.3
^ permalink raw reply related
* [PATCH net v2 1/4] ipv4: validate ip_options length in __ip_options_echo() against skb tail
From: Qi Tang @ 2026-05-24 4:14 UTC (permalink / raw)
To: davem, kuba, pabeni, edumazet
Cc: netdev, fw, lyutoon, stable, Qi Tang, David Ahern, Ido Schimmel,
Simon Horman
In-Reply-To: <20260524041442.2432071-1-tpluszz77@gmail.com>
__ip_options_echo() re-reads each option length byte (RR/TS/SRR/CIPSO)
from skb->data when building the echoed options into a 40-byte
__data[] buffer. __ip_options_compile() saved only the option offset
into IPCB(skb)->opt, not the length. An nftables LOCAL_IN payload
write reachable from an unprivileged user namespace can mutate the
length byte between parse and recvmsg, turning a parse-time validated
7-byte option into a 255-byte read.
unsigned char optbuf[sizeof(struct ip_options) + 40];
/* in __ip_options_echo: */
optlen = sptr[sopt->rr + 1]; /* re-read; nft can mutate */
memcpy(dptr, sptr + sopt->rr, optlen); /* into 40-byte buffer */
The destination is a stack buffer in ip_cmsg_recv_retopts() and a
DEFINE_RAW_FLEX() buffer in icmp.c / ip_output.c sized
IP_OPTIONS_DATA_FIXED_SIZE (40). KASAN reports a stack-out-of-bounds
write of size 255:
BUG: KASAN: stack-out-of-bounds in __ip_options_echo+0x7fc/0x1310
Write of size 255 at addr ffff88800a657950
__asan_memcpy+0x3c/0x60
__ip_options_echo+0x7fc/0x1310
ip_cmsg_recv_offset+0x58b/0xd10
udp_recvmsg+0x8da/0xc20
____sys_recvmsg+0x1b1/0x620
Validate that each re-read option length stays within
skb_tail_pointer(skb) before the memcpy.
Cc: stable@vger.kernel.org
Reported-by: Qi Tang <tpluszz77@gmail.com>
Reported-by: Tong Liu <lyutoon@gmail.com>
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Qi Tang <tpluszz77@gmail.com>
---
net/ipv4/ip_options.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/net/ipv4/ip_options.c b/net/ipv4/ip_options.c
index be8815ce3ac24..1cc6096e6dd9d 100644
--- a/net/ipv4/ip_options.c
+++ b/net/ipv4/ip_options.c
@@ -91,6 +91,8 @@ int __ip_options_echo(struct net *net, struct ip_options *dopt,
if (sopt->rr) {
optlen = sptr[sopt->rr+1];
+ if (sptr + sopt->rr + optlen > skb_tail_pointer(skb))
+ return -EINVAL;
soffset = sptr[sopt->rr+2];
dopt->rr = dopt->optlen + sizeof(struct iphdr);
memcpy(dptr, sptr+sopt->rr, optlen);
@@ -105,6 +107,8 @@ int __ip_options_echo(struct net *net, struct ip_options *dopt,
}
if (sopt->ts) {
optlen = sptr[sopt->ts+1];
+ if (sptr + sopt->ts + optlen > skb_tail_pointer(skb))
+ return -EINVAL;
soffset = sptr[sopt->ts+2];
dopt->ts = dopt->optlen + sizeof(struct iphdr);
memcpy(dptr, sptr+sopt->ts, optlen);
@@ -145,6 +149,8 @@ int __ip_options_echo(struct net *net, struct ip_options *dopt,
__be32 faddr;
optlen = start[1];
+ if (start + optlen > skb_tail_pointer(skb))
+ return -EINVAL;
soffset = start[2];
doffset = 0;
if (soffset > optlen)
@@ -174,6 +180,8 @@ int __ip_options_echo(struct net *net, struct ip_options *dopt,
}
if (sopt->cipso) {
optlen = sptr[sopt->cipso+1];
+ if (sptr + sopt->cipso + optlen > skb_tail_pointer(skb))
+ return -EINVAL;
dopt->cipso = dopt->optlen+sizeof(struct iphdr);
memcpy(dptr, sptr+sopt->cipso, optlen);
dptr += optlen;
--
2.47.3
^ permalink raw reply related
* [PATCH net v2 0/4] net: trust-after-modification fixes for IPv4 options + netlabel
From: Qi Tang @ 2026-05-24 4:14 UTC (permalink / raw)
To: davem, kuba, pabeni, edumazet
Cc: netdev, fw, lyutoon, stable, Qi Tang, David Ahern, Ido Schimmel,
Simon Horman, Paul Moore, Casey Schaufler, Huw Davies,
linux-security-module
Four small bounds-check fixes for a recurring pattern in IPv4 options
and CIPSO/CALIPSO consumers. The parse-time validator stores only
the option offset into IPCB / skb metadata. Later consumers (cmsg
echo, mrouted report, netlabel getattr) re-read the length /
pointer / cat_len bytes from the skb body and use them for indexed
memcpy or bitmap walk. An nftables payload mutation reachable from
an unprivileged user namespace (CAP_NET_ADMIN inside the namespace)
rewrites those bytes between parse and consume.
1/4 __ip_options_echo() 40-byte stack OOB write
(KASAN: stack-out-of-bounds,
Write of size 255).
2/4 ipmr_cache_report() Up to 40-byte OOB read of
skb head leaked into the
IGMPMSG cmsg delivered to
mrouted.
3/4 netlbl_skbuff_getattr() / CALIPSO ~232-byte slab OOB read
driving SELinux MLS
category bitmap.
4/4 netlbl_skbuff_getattr() / CIPSO Sibling of 3/4 on the
AF_INET (CIPSO IPv4) path.
Florian Westphal's [PATCH net 05/10] netfilter: disable payload
mangling in userns blocks the unprivileged-userns side of nft
payload-set at the source:
https://lore.kernel.org/netdev/20260522104257.2008-6-fw@strlen.de/
These four consumer-side bounds checks land in the same direction
as defense in depth, also covering root / CAP_NET_ADMIN nft
FORWARD payload mangling in the init userns and any non-nft
mutation path.
Changes v1 -> v2:
- 3/4 + 4/4 return -EINVAL on bounds-check failure instead of
falling through to netlbl_unlabel_getattr() (Paul Moore).
- 3/4 commit message drops the "Smack" mention from the CALIPSO
consume path; Smack does not currently consume CALIPSO (Casey
Schaufler).
- 4/4 inline comment explains the literal 8: CIPSO option header
(type+len+DOI = 6) plus first tag header (type+len = 2) (Paul
Moore).
- All four pick up Cc: stable@vger.kernel.org.
v1: https://lore.kernel.org/netdev/20260514165139.436961-1-tpluszz77@gmail.com/
Qi Tang (4):
ipv4: validate ip_options length in __ip_options_echo() against skb
tail
ipv4: ipmr: clamp ip_hdrlen against skb_headlen in ipmr_cache_report
netlabel: validate CALIPSO option against skb tail in
netlbl_skbuff_getattr
netlabel: validate CIPSO option against skb tail in
netlbl_skbuff_getattr
net/ipv4/ip_options.c | 8 ++++++++
net/ipv4/ipmr.c | 2 +-
net/netlabel/netlabel_kapi.c | 32 ++++++++++++++++++++++++++++----
3 files changed, 37 insertions(+), 5 deletions(-)
--
2.47.3
^ permalink raw reply
* Linux 6.12.91 / build breakage / perf cgroup: Update metric leader in evlist__expand_cgroup
From: Marek Vasut @ 2026-05-24 3:56 UTC (permalink / raw)
To: linux-stable, Sasha Levin; +Cc: Ian Rogers, Sun Jian, Namhyung Kim
Hello everyone,
the following commit landed in Linux 6.12.91:
d26e31446c0f ("perf cgroup: Update metric leader in evlist__expand_cgroup")
However, the first_wildcard_match field does not exist in Linux 6.12.91,
which prevents perf from being built:
"
$ git grep first_wildcard_match
tools/perf/util/cgroup.c: if
(pos->first_wildcard_match)
tools/perf/util/cgroup.c:
evsel->first_wildcard_match = pos->first_wildcard_match->priv;
"
Either this commit should be dropped, or 137359b7895f ("perf
parse-events: Use wildcard processing to set an event to merge into")
needs to be backported too (?).
Furthermore, it also seems 7cfcd01f33fc ("perf tool_pmu: Factor tool
events into their own PMU") calls parse_events__term_type_str() which is
also not defined on 6.12.y .
Thank you for your help !
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: Linux 6.12.91
From: Wang Yugui @ 2026-05-24 0:56 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-kernel, akpm, torvalds, stable, lwn, jslaby
In-Reply-To: <2026052319-chastity-viper-7530@gregkh>
Hi,
> I'm announcing the release of the 6.12.91 kernel.
>
> All users of the 6.12 kernel series must upgrade.
>
> The updated 6.12.y git tree can be found at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-6.12.y
> and can be browsed at the normal kernel.org git web browser:
> https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
2 regression of 6.12.91 are found here. Both of them are in perf tool
1, undefined reference to `parse_events__term_type_str'
Could we add a patch
d2f3ecb0ca2099d13bf8bf69219214c1425dc453 perf parse-events: Expose/rename config_term_name
or do some funcation rename(parse_events__term_type_str->config_term_name)?
2, undefined first_wildcard_match
Could we revert the patch (perf cgroup: Update metric leader in evlist__expand_cgroup)?
Best Regards
Wang Yugui (wangyugui@e16-tech.com)
2026/05/24
^ permalink raw reply
* [STATUS] stable/linux-6.1.y - dcbcab9d707928cd1679eba21ef0697fbb73b88a
From: KernelCI bot @ 2026-05-24 2:30 UTC (permalink / raw)
To: kernelci-results; +Cc: stable
Hello,
Status summary for stable/linux-6.1.y
Dashboard:
https://d.kernelci.org/c/stable/linux-6.1.y/dcbcab9d707928cd1679eba21ef0697fbb73b88a/
giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
branch: linux-6.1.y
commit hash: dcbcab9d707928cd1679eba21ef0697fbb73b88a
origin: maestro
test start time: 2026-05-23 12:15:08.086000+00:00
Builds: 41 ✅ 1 ❌ 0 ⚠️
Boots: 45 ✅ 0 ❌ 5 ⚠️
Tests: 1715 ✅ 146 ❌ 806 ⚠️
### POSSIBLE REGRESSIONS
No possible regressions observed.
### FIXED REGRESSIONS
No fixed regressions observed.
### UNSTABLE TESTS
Hardware: bcm2711-rpi-4-b
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a11a3dd5bf5d05c9744ef31
history: > ⚠️ > ✅ > ✅ > ✅
Hardware: beaglebone-black
> Config: multi_v7_defconfig
- Architecture/compiler: arm/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a11a5975bf5d05c9744f173
history: > ✅ > ⚠️ > ✅
Hardware: imx6dl-udoo
> Config: multi_v7_defconfig
- Architecture/compiler: arm/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a11a5985bf5d05c9744f176
history: > ⚠️ > ✅
Hardware: qemu-x86_64
> Config: x86_64_defconfig+lab-setup+x86-board+kselftest
- Architecture/compiler: x86_64/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a11a5175bf5d05c9744f101
history: > ✅ > ⚠️ > ✅
This branch has 1 pre-existing build issues. See details in the dashboard.
Sent every day if there were changes in the past 24 hours.
Legend: ✅ PASS ❌ FAIL ⚠️ INCONCLUSIVE
--
This is an experimental report format. Please send feedback in!
Talk to us at kernelci@lists.linux.dev
Made with love by the KernelCI team - https://kernelci.org
^ permalink raw reply
* [STATUS] stable/linux-6.12.y - c4ffbe29c40ed851601bce640d5ead48eaaae08d
From: KernelCI bot @ 2026-05-24 2:30 UTC (permalink / raw)
To: kernelci-results; +Cc: stable
Hello,
Status summary for stable/linux-6.12.y
Dashboard:
https://d.kernelci.org/c/stable/linux-6.12.y/c4ffbe29c40ed851601bce640d5ead48eaaae08d/
giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
branch: linux-6.12.y
commit hash: c4ffbe29c40ed851601bce640d5ead48eaaae08d
origin: maestro
test start time: 2026-05-23 11:13:22.651000+00:00
Builds: 44 ✅ 0 ❌ 0 ⚠️
Boots: 78 ✅ 0 ❌ 6 ⚠️
Tests: 9165 ✅ 575 ❌ 2822 ⚠️
### POSSIBLE REGRESSIONS
Hardware: imx8mp-evk
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.device_error_logs
last run: https://d.kernelci.org/test/maestro:6a119b8e5bf5d05c97448cea
history: > ✅ > ❌
- kselftest.device_error_logs.devices_error_logs_test_device_error_logs_py
last run: https://d.kernelci.org/test/maestro:6a11c8315bf5d05c974527b0
history: > ✅ > ❌
Hardware: mt8183-kukui-jacuzzi-juniper-sku16
> Config: defconfig+lab-setup+arm64-chromebook+CONFIG_MODULE_COMPRESS=n+CONFIG_MODULE_COMPRESS_NONE=y
- Architecture/compiler: arm64/gcc-14
- kernelci_watchdog_reset
last run: https://d.kernelci.org/test/maestro:6a1196e95bf5d05c97445f6c
history: > ✅ > ❌
- kernelci_watchdog_reset.wdt-reset.wdt-trigger-reset
last run: https://d.kernelci.org/test/maestro:6a11984b5bf5d05c97446f79
history: > ✅ > ❌
### FIXED REGRESSIONS
Hardware: imx8mp-evk
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.kvm.kvm_arch_timer_edge_cases
last run: https://d.kernelci.org/test/maestro:6a1199d75bf5d05c97448023
history: > ❌ > ✅
### UNSTABLE TESTS
Hardware: bcm2711-rpi-4-b
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a119b665bf5d05c97448bd3
history: > ✅ > ⚠️ > ✅ > ✅ > ✅
Hardware: beaglebone-black
> Config: multi_v7_defconfig
- Architecture/compiler: arm/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a1194815bf5d05c974443b5
history: > ✅ > ✅ > ✅ > ⚠️ > ✅
Hardware: imx6dl-udoo
> Config: multi_v7_defconfig
- Architecture/compiler: arm/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a1194835bf5d05c974443b8
history: > ✅ > ⚠️ > ✅
Hardware: qemu-x86_64
> Config: x86_64_defconfig+lab-setup+x86-board+kselftest
- Architecture/compiler: x86_64/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a1193f15bf5d05c97443af3
history: > ✅ > ✅ > ⚠️ > ✅
Sent every day if there were changes in the past 24 hours.
Legend: ✅ PASS ❌ FAIL ⚠️ INCONCLUSIVE
--
This is an experimental report format. Please send feedback in!
Talk to us at kernelci@lists.linux.dev
Made with love by the KernelCI team - https://kernelci.org
^ permalink raw reply
* [STATUS] stable/linux-5.10.y - 7adbe121223f7e32ab7e2592a72093f80f4e11a8
From: KernelCI bot @ 2026-05-24 2:30 UTC (permalink / raw)
To: kernelci-results; +Cc: stable
Hello,
Status summary for stable/linux-5.10.y
Dashboard:
https://d.kernelci.org/c/stable/linux-5.10.y/7adbe121223f7e32ab7e2592a72093f80f4e11a8/
giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
branch: linux-5.10.y
commit hash: 7adbe121223f7e32ab7e2592a72093f80f4e11a8
origin: maestro
test start time: 2026-05-23 12:15:07.250000+00:00
Builds: 40 ✅ 2 ❌ 0 ⚠️
Boots: 36 ✅ 0 ❌ 4 ⚠️
Tests: 315 ✅ 78 ❌ 44 ⚠️
### POSSIBLE REGRESSIONS
No possible regressions observed.
### FIXED REGRESSIONS
No fixed regressions observed.
### UNSTABLE TESTS
Hardware: bcm2711-rpi-4-b
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a11a1965bf5d05c9744e875
history: > ⚠️ > ✅ > ✅ > ✅
Hardware: beaglebone-black
> Config: multi_v7_defconfig
- Architecture/compiler: arm/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a11a07c5bf5d05c9744e2cd
history: > ✅ > ⚠️ > ✅
Hardware: qemu-x86_64
> Config: x86_64_defconfig+lab-setup+x86-board+kselftest
- Architecture/compiler: x86_64/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a11ade45bf5d05c9744f85e
history: > ✅ > ⚠️ > ✅
This branch has 2 pre-existing build issues. See details in the dashboard.
Sent every day if there were changes in the past 24 hours.
Legend: ✅ PASS ❌ FAIL ⚠️ INCONCLUSIVE
--
This is an experimental report format. Please send feedback in!
Talk to us at kernelci@lists.linux.dev
Made with love by the KernelCI team - https://kernelci.org
^ permalink raw reply
* [STATUS] stable/linux-5.15.y - 241d66fa280c91b65942d641e92d06c9ae6a0b95
From: KernelCI bot @ 2026-05-24 2:30 UTC (permalink / raw)
To: kernelci-results; +Cc: stable
Hello,
Status summary for stable/linux-5.15.y
Dashboard:
https://d.kernelci.org/c/stable/linux-5.15.y/241d66fa280c91b65942d641e92d06c9ae6a0b95/
giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
branch: linux-5.15.y
commit hash: 241d66fa280c91b65942d641e92d06c9ae6a0b95
origin: maestro
test start time: 2026-05-23 12:15:07.678000+00:00
Builds: 38 ✅ 4 ❌ 0 ⚠️
Boots: 36 ✅ 0 ❌ 5 ⚠️
Tests: 483 ✅ 170 ❌ 340 ⚠️
### POSSIBLE REGRESSIONS
No possible regressions observed.
### FIXED REGRESSIONS
No fixed regressions observed.
### UNSTABLE TESTS
Hardware: bcm2711-rpi-4-b
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a11af0b5bf5d05c9744fc4e
history: > ⚠️ > ✅ > ✅
Hardware: beaglebone-black
> Config: multi_v7_defconfig
- Architecture/compiler: arm/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a11a6715bf5d05c9744f2ff
history: > ✅ > ⚠️ > ✅
Hardware: qemu-x86_64
> Config: x86_64_defconfig+lab-setup+x86-board+kselftest
- Architecture/compiler: x86_64/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a11a0065bf5d05c9744e276
history: > ✅ > ⚠️ > ✅
This branch has 4 pre-existing build issues. See details in the dashboard.
Sent every day if there were changes in the past 24 hours.
Legend: ✅ PASS ❌ FAIL ⚠️ INCONCLUSIVE
--
This is an experimental report format. Please send feedback in!
Talk to us at kernelci@lists.linux.dev
Made with love by the KernelCI team - https://kernelci.org
^ permalink raw reply
* [STATUS] stable/linux-6.6.y - 0a40c6fbd105802fbbcaadca249e0948fbf8095a
From: KernelCI bot @ 2026-05-24 2:30 UTC (permalink / raw)
To: kernelci-results; +Cc: stable
Hello,
Status summary for stable/linux-6.6.y
Dashboard:
https://d.kernelci.org/c/stable/linux-6.6.y/0a40c6fbd105802fbbcaadca249e0948fbf8095a/
giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
branch: linux-6.6.y
commit hash: 0a40c6fbd105802fbbcaadca249e0948fbf8095a
origin: maestro
test start time: 2026-05-23 11:13:22.220000+00:00
Builds: 44 ✅ 0 ❌ 0 ⚠️
Boots: 63 ✅ 0 ❌ 6 ⚠️
Tests: 4653 ✅ 1611 ❌ 1469 ⚠️
### POSSIBLE REGRESSIONS
Hardware: mt8183-kukui-jacuzzi-juniper-sku16
> Config: defconfig+lab-setup+arm64-chromebook+CONFIG_MODULE_COMPRESS=n+CONFIG_MODULE_COMPRESS_NONE=y
- Architecture/compiler: arm64/gcc-14
- kernelci_watchdog_reset.wdt-reset.wdt-get-timeout
last run: https://d.kernelci.org/test/maestro:6a1196635bf5d05c97445d26
history: > ✅ > ❌
Hardware: mt8195-cherry-tomato-r2
> Config: defconfig+lab-setup+arm64-chromebook+CONFIG_MODULE_COMPRESS=n+CONFIG_MODULE_COMPRESS_NONE=y
- Architecture/compiler: arm64/gcc-14
- kernelci_watchdog_reset.wdt-reset.wdt-get-timeout
last run: https://d.kernelci.org/test/maestro:6a1196065bf5d05c97445a1b
history: > ✅ > ❌
### FIXED REGRESSIONS
Hardware: asus-CX3402CVA-brya
> Config: x86_64_defconfig+lab-setup+x86-board+kselftest
- Architecture/compiler: x86_64/gcc-14
- kernelci_sleep
last run: https://d.kernelci.org/test/maestro:6a11932a5bf5d05c97442f68
history: > ❌ > ✅
### UNSTABLE TESTS
Hardware: bcm2711-rpi-4-b
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a11963c5bf5d05c97445c17
history: > ✅ > ⚠️ > ✅ > ✅ > ✅
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.mm.mm_run_vmtests_sh_khugepaged
last run: https://d.kernelci.org/test/maestro:6a1198ac5bf5d05c97447823
history: > ⚠️ > ❌
Hardware: beaglebone-black
> Config: multi_v7_defconfig
- Architecture/compiler: arm/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a11921e5bf5d05c97442ceb
history: > ✅ > ✅ > ⚠️ > ✅
Hardware: imx6dl-udoo
> Config: multi_v7_defconfig
- Architecture/compiler: arm/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a11921f5bf5d05c97442cee
history: > ✅ > ⚠️ > ✅
Hardware: qemu-x86_64
> Config: x86_64_defconfig+lab-setup+x86-board+kselftest
- Architecture/compiler: x86_64/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a1193265bf5d05c97442f62
history: > ✅ > ✅ > ⚠️ > ✅
Sent every day if there were changes in the past 24 hours.
Legend: ✅ PASS ❌ FAIL ⚠️ INCONCLUSIVE
--
This is an experimental report format. Please send feedback in!
Talk to us at kernelci@lists.linux.dev
Made with love by the KernelCI team - https://kernelci.org
^ permalink raw reply
* Re: [PATCH] ALSA: firewire-motu: Protect register DSP event queue positions
From: Takashi Sakamoto @ 2026-05-24 2:23 UTC (permalink / raw)
To: Cássio Gabriel
Cc: Clemens Ladisch, Takashi Iwai, Jaroslav Kysela, linux-sound,
linux-kernel, stable
In-Reply-To: <20260521-alsa-firewire-motu-event-locking-v1-1-708e1c2b5e56@gmail.com>
Hi,
On Thu, May 21, 2026 at 08:01:23AM -0300, Cássio Gabriel wrote:
> The register DSP event queue is updated under parser->lock, but
> snd_motu_register_dsp_message_parser_count_event() reads pull_pos and
> push_pos without the lock.
> snd_motu_register_dsp_message_parser_copy_event() also reads both queue
> positions before taking the lock.
>
> Protect these accesses with parser->lock as well. This keeps the hwdep
> poll/read path consistent with the producer side and with the cached
> meter/parameter accessors.
>
> Fixes: 634ec0b2906e ("ALSA: firewire-motu: notify event for parameter change in register DSP model")
> Cc: stable@vger.kernel.org
> Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
> ---
> sound/firewire/motu/motu-register-dsp-message-parser.c | 11 +++++++----
> 1 file changed, 7 insertions(+), 4 deletions(-)
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
I remember that I was investigating whether to use the
'snd_motu.hwdep_lock' spin lock when working for this code,
especially for 'pull_pos'. The 'snd_hwdep.exclusive' is used to constraint
the number of file descriptors to open it, and the spin lock would be
protect the concurrent access, since the pull_pos is referred and updated
by user process only. However,
snd_motu_register_dsp_message_parser_copy_event() is called outside of
the spin lock. The suggested change is preferable.
Thanks
Takashi Sakamoto
^ permalink raw reply
* Re: Linux 5.15 bug in vdso_read_cpunode() in segment.h introduced in 2025, commit ac9c408ed19d535289ca59200dd6a44a6a2d6036
From: Borislav Petkov @ 2026-05-24 2:03 UTC (permalink / raw)
To: Greg KH; +Cc: Uros Bizjak, Jan Ingvoldstad, stable
In-Reply-To: <2026052230-obtrusive-prowler-86c2@gregkh>
On Fri, May 22, 2026 at 07:14:10AM +0200, Greg KH wrote:
> On Thu, May 21, 2026 at 04:47:43PM +0000, Borislav Petkov wrote:
> > On May 21, 2026 4:46:11 PM UTC, Borislav Petkov <bp@alien8.de> wrote:
> > >+ stable
> >
> > Now for real!
>
> Ok, so what are we to do about this?
Right, it looks like Sasha's AI picked it up, judging by his SOB below.
Now, we don't really need to backport it to stable and I didn't CC:stable
because of that...
But yeah, it needs to be reverted because the binutils version for 5.15
doesn't support the RDPID insn mnemonic and that patch is not fixing any bug
anyway, AFAICT.
Thx.
commit 64f14b1ab6f39a704b62bf9b3fa28803cf2b3ebe
Author: Uros Bizjak <ubizjak@gmail.com>
Date: Mon Jun 16 11:52:57 2025 +0200
x86/vdso: Fix output operand size of RDPID
[ Upstream commit ac9c408ed19d535289ca59200dd6a44a6a2d6036 ]
RDPID instruction outputs to a word-sized register (64-bit on x86_64 and
32-bit on x86_32). Use an unsigned long variable to store the correct size.
LSL outputs to 32-bit register, use %k operand prefix to always print the
32-bit name of the register.
Use RDPID insn mnemonic while at it as the minimum binutils version of
2.30 supports it.
[ bp: Merge two patches touching the same function into a single one. ]
Fixes: ffebbaedc861 ("x86/vdso: Introduce helper functions for CPU and node number")
Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/20250616095315.230620-1-ubizjak@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* Re: [PATCH] ARM: io: avoid KASAN instrumentation of raw halfword I/O
From: Linus Walleij @ 2026-05-23 22:11 UTC (permalink / raw)
To: Karl Mehltretter
Cc: Russell King, Abbott Liu, Ard Biesheuvel, Florian Fainelli,
linux-arm-kernel, linux-kernel, stable
In-Reply-To: <20260522212018.25295-1-kmehltretter@gmail.com>
On Fri, May 22, 2026 at 11:20 PM Karl Mehltretter
<kmehltretter@gmail.com> wrote:
> Commit 421015713b30 ("ARM: 9017/2: Enable KASan for ARM") made KASAN
> instrument ARM C memory accesses. For CPUs before ARMv6, __raw_readw()
> and __raw_writew() are C volatile halfword accesses, so KASAN instruments
> them as normal memory accesses.
>
> That is not valid for MMIO. On the QEMU versatilepb machine with an
> ARM926EJ-S CPU and CONFIG_KASAN=y, PL011 probing traps while registering
> the UART:
>
> Unable to handle kernel paging request at virtual address bd23e207
> PC is at __asan_store2+0x2c/0x9c
> LR is at pl011_register_port+0x4c/0x19c
>
> Keep the existing volatile halfword access, but move the pre-ARMv6
> definitions into __no_kasan_or_inline functions so raw MMIO halfword
> accesses are not instrumented by KASAN. The ARMv6-and-newer inline
> assembly path is unchanged.
>
> Fixes: 421015713b30 ("ARM: 9017/2: Enable KASan for ARM")
> Cc: stable@vger.kernel.org # v5.11+
> Assisted-by: Codex:gpt-5
> Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
That makes sense.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Please put this patch into Russell's patch tracker.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] ARM: entry: use byte load for KASAN VMAP stack shadow
From: Linus Walleij @ 2026-05-23 22:08 UTC (permalink / raw)
To: Karl Mehltretter
Cc: Russell King, Russell King (Oracle), linux-arm-kernel,
linux-kernel, stable
In-Reply-To: <20260522211503.25219-1-kmehltretter@gmail.com>
On Fri, May 22, 2026 at 11:15 PM Karl Mehltretter
<kmehltretter@gmail.com> wrote:
> Commit 44e9a3bb76e5 ("ARM: 9430/1: entry: Do a dummy read from
> VMAP shadow") added a dummy read from the KASAN VMAP stack shadow in
> __switch_to(). The read uses ldr, but KASAN shadow memory is
> byte-granular and the computed shadow address is not guaranteed to be
> word aligned.
>
> Booting the QEMU versatilepb machine with an ARM926EJ-S CPU and
> CONFIG_KASAN=y, CONFIG_KASAN_VMALLOC=y and CONFIG_VMAP_STACK=y faults
> before init:
>
> Unhandled fault: alignment exception (0x001) at 0xb91037f6
> PC is at __switch_to+0x64/0x88
>
> Use ldrb for the dummy shadow access. The code only needs to fault if
> the shadow mapping is missing, so a byte load is sufficient and matches
> the granularity of KASAN shadow memory.
>
> Fixes: 44e9a3bb76e5 ("ARM: 9430/1: entry: Do a dummy read from VMAP shadow")
> Cc: stable@vger.kernel.org # v6.13+
> Assisted-by: Codex:gpt-5
> Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Good catch!
Reviewed-by: Linus Walleij <linusw@kernel.org>
Please put this patch into Russell's patch tracker.
Yours,
Linus Walleij
^ 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