6.12.92-rc1 review
Subsystems (4)
Greg Kroah-Hartman
maintainerPATCH 262/272 bpf, skmsg: fix verdict sk_data_ready racing with ktls rx
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xingwang Xiang <[email protected]>
[ Upstream commit ddf8029623a1af20e984c040e89ff918158397ab ]
sk_psock_strp_data_ready() already checks tls_sw_has_ctx_rx() and defers to psock->saved_data_ready when a TLS RX context is present, avoiding a conflict with the TLS strparser's ownership of the receive queue (commit e91de6afa81c, "bpf: Fix running sk_skb program types with ktls").
sk_psock_verdict_data_ready() has no equivalent guard. When a socket is inserted into a sockmap (BPF_SK_SKB_VERDICT) before TLS RX is configured, tls_sw_strparser_arm() saves sk_psock_verdict_data_ready as rx_ctx->saved_data_ready. On data arrival:
tls_data_ready -> tls_strp_data_ready -> tls_rx_msg_ready
-> saved_data_ready() = sk_psock_verdict_data_ready()
-> tcp_read_skb() drains sk_receive_queue via __skb_unlink()
without calling tcp_eat_skb(), so copied_seq is not advanced.tls_strp_msg_load() then finds tcp_inq() >= full_len (stale), calls tcp_recv_skb() on the now-empty queue, hits WARN_ON_ONCE(!first), and returns with rx_ctx->strp.anchor.frag_list pointing at a psock-owned (potentially freed) skb. tls_decrypt_sg() subsequently walks thatfrag_list: use-after-free.
Apply the same fix as sk_psock_strp_data_ready(): if a TLS RX context is present, call psock->saved_data_ready (sock_def_readable) to wake recv() waiters and return immediately, leaving the receive queue untouched. TLS retains sole ownership of the queue and decrypts the record normally through tls_sw_recvmsg().
--- net/core/skmsg.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
net/core/skmsg.c +7 -2
@@ -1267,12 +1267,19 @@ static int sk_psock_verdict_recv(struct sock *sk, struct sk_buff *skb)static void sk_psock_verdict_data_ready (struct sock *sk) {const struct proto_ops *ops =NULL ; +struct sk_psock *psock;struct socket *sock;int copied;trace_sk_data_ready (sk);rcu_read_lock (); + psock =sk_psock (sk); +if (psock &&tls_sw_has_ctx_rx (sk)) { + psock->saved_data_ready (sk); +rcu_read_unlock (); +return ; + } sock =READ_ONCE (sk->sk_socket);if (likely (sock)) ops =READ_ONCE (sock->ops);
@@ -1282,8 +1289,6 @@ static void sk_psock_verdict_data_ready(struct sock *sk) copied = ops->read_skb (sk, sk_psock_verdict_recv);if (copied >=0 ) { -struct sk_psock *psock; -rcu_read_lock (); psock =sk_psock (sk);if (psock)
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 263/272 gpiolib: cdev: use !mem_is_zero() instead of memchr_inv(s, 0, n)
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Shevchenko <[email protected]>
[ Upstream commit e106b1dd38e723ec2bb2bf57ea9b2aff464b9423 ]
Use the mem_is_zero() helper where possible.
Stable-dep-of: 3e6ccd790ed6 ("gpio: cdev: check if uAPI v2 config attributes are correctly zeroed")
--- drivers/gpio/gpiolib-cdev.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/gpio/gpiolib-cdev.c +4 -4
@@ -16,7 +16,6 @@#include <linux/hte.h> #include <linux/interrupt.h> #include <linux/irqreturn.h> -#include <linux/kernel.h> #include <linux/kfifo.h> #include <linux/module.h> #include <linux/mutex.h>
@@ -26,6 +25,7 @@#include <linux/rbtree.h> #include <linux/seq_file.h> #include <linux/spinlock.h> +#include <linux/string.h> #include <linux/timekeeping.h> #include <linux/uaccess.h> #include <linux/workqueue.h>
@@ -1331,7 +1331,7 @@ static int gpio_v2_line_config_validate(struct gpio_v2_line_config *lc,if (lc->num_attrs >GPIO_V2_LINE_NUM_ATTRS_MAX )return -EINVAL ; -if (memchr_inv (lc->padding,0 ,sizeof (lc->padding))) +if (!mem_is_zero (lc->padding,sizeof (lc->padding)))return -EINVAL ;for (i =0 ; i < num_lines; i++) {
@@ -1746,7 +1746,7 @@ static int linereq_create(struct gpio_device *gdev, void __user *ip)if ((ulr.num_lines ==0 ) || (ulr.num_lines >GPIO_V2_LINES_MAX ))return -EINVAL ; -if (memchr_inv (ulr.padding,0 ,sizeof (ulr.padding))) +if (!mem_is_zero (ulr.padding,sizeof (ulr.padding)))return -EINVAL ; lc = &ulr.config;
@@ -2516,7 +2516,7 @@ static int lineinfo_get(struct gpio_chardev_data *cdev, void __user *ip,if (copy_from_user (&lineinfo, ip,sizeof (lineinfo)))return -EFAULT ; -if (memchr_inv (lineinfo.padding,0 ,sizeof (lineinfo.padding))) +if (!mem_is_zero (lineinfo.padding,sizeof (lineinfo.padding)))return -EINVAL ; desc =gpio_device_get_desc (cdev->gdev, lineinfo.offset);
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 264/272 gpio: cdev: check if uAPI v2 config attributes are correctly zeroed
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bartosz Golaszewski <[email protected]>
[ Upstream commit 3e6ccd790ed69bedd3d9626d01dd35cf9821c121 ]
We check the padding of other uAPI v2 structures but not that of line config attributes. For used attributes: check if their padding is zeroed, for unused: check if the entire structure is zeroed.
--- drivers/gpio/gpiolib-cdev.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
drivers/gpio/gpiolib-cdev.c +13 -0
@@ -1324,6 +1324,7 @@ static int gpio_v2_line_flags_validate(u64 flags)static int gpio_v2_line_config_validate (struct gpio_v2_line_config *lc,unsigned int num_lines) { +size_t unused_attrs;unsigned int i;u64 flags;int ret;
@@ -1331,9 +1332,21 @@ static int gpio_v2_line_config_validate(struct gpio_v2_line_config *lc,if (lc->num_attrs >GPIO_V2_LINE_NUM_ATTRS_MAX )return -EINVAL ; + unused_attrs =GPIO_V2_LINE_NUM_ATTRS_MAX - lc->num_attrs; +if (!mem_is_zero (lc->padding,sizeof (lc->padding)))return -EINVAL ; +for (i =0 ; i < lc->num_attrs; i++) { +if (lc->attrs[i].attr.padding !=0 ) +return -EINVAL ; + } + +if (unused_attrs) { +if (!mem_is_zero (&lc->attrs[lc->num_attrs], unused_attrs *sizeof (*lc->attrs))) +return -EINVAL ; + } +for (i =0 ; i < num_lines; i++) { flags =gpio_v2_line_config_flags (lc, i); ret =gpio_v2_line_flags_validate (flags);
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 265/272 ASoC: cs35l56: Fix flushing of IRQ work in cs35l56_sdw_remove()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Richard Fitzgerald <[email protected]>
[ Upstream commit 18e7bd9f2446664053f8c34b72abd4606d22d858 ]
Use flush_work() instead of cancel_work_sync() to terminate pending IRQ work in cs35l56_sdw_remove(). And flush_work() again after masking the interrupts to flush any queueing that was racing with the masking. This is the same sequence as cs35l56_sdw_system_suspend().
cs35l56_sdw_interrupt() takes the pm_runtime to prevent the bus powering- down before the interrupt status can be read and handled. The work releases this pm_runtime. So cancelling it, instead of flushing, could leave an unbalanced pm_runtime.
--- sound/soc/codecs/cs35l56-sdw.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
sound/soc/codecs/cs35l56-sdw.c +2 -1
@@ -544,10 +544,11 @@ static int cs35l56_sdw_remove(struct sdw_slave *peripheral)/* Disable SoundWire interrupts */ cs35l56->sdw_irq_no_unmask = true; -cancel_work_sync (&cs35l56->sdw_irq_work); +flush_work (&cs35l56->sdw_irq_work);sdw_write_no_pm (peripheral,CS35L56_SDW_GEN_INT_MASK_1 ,0 );sdw_read_no_pm (peripheral,CS35L56_SDW_GEN_INT_STAT_1 );sdw_write_no_pm (peripheral,CS35L56_SDW_GEN_INT_STAT_1 ,0xFF ); +flush_work (&cs35l56->sdw_irq_work);cs35l56_remove (cs35l56);
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 266/272 drm/xe/oa: Fix exec_queue leak on width check in stream open
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shuicheng Lin <[email protected]>
[ Upstream commit 4d25342543c01310fc4e0cba7cb17c775e2421e2 ]
In xe_oa_stream_open_ioctl(), when param.exec_q->width > 1 the function returns -EOPNOTSUPP directly, skipping the existing err_exec_q cleanup path. The exec_queue reference obtained by xe_exec_queue_lookup() is leaked.
The exec queue holds a reference on the xe_file, which is only dropped during queue teardown. The leaked lookup ref is not on the file's exec_queue xarray, so file close cannot release it. This keeps both the exec queue and the file private state pinned indefinitely.
Jump to err_exec_q instead of returning directly so the reference is released.
--- drivers/gpu/drm/xe/xe_oa.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/gpu/drm/xe/xe_oa.c +4 -2
@@ -2019,8 +2019,10 @@ int xe_oa_stream_open_ioctl(struct drm_device *dev, u64 data, struct drm_file *fif (XE_IOCTL_DBG (oa->xe, !param.exec_q))return -ENOENT ; -if (XE_IOCTL_DBG (oa->xe, param.exec_q->width >1 )) -return -EOPNOTSUPP ; +if (XE_IOCTL_DBG (oa->xe, param.exec_q->width >1 )) { + ret = -EOPNOTSUPP ; + goto err_exec_q; + } }/*
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 267/272 octeontx2-af: npc: Fix allmulticast skip logic for LBK and SDP VFs
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ratheesh Kannoth <[email protected]>
[ Upstream commit 9eddc819f00b5b74bb4ac91396f80bd35f5f3561 ]
When installing the allmulticast NPC rule, rvu_npc_install_allmulti_entry() should skip LBK and SDP VFs (only CGX PF/VF may add the entry). The code combined is_lbk_vf() and is_sdp_vf() with logical AND, which is never true for a single pcifunc, so the intended early return never ran.
Use logical OR instead.
--- drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c +1 -1
@@ -853,7 +853,7 @@ void rvu_npc_install_allmulti_entry(struct rvu *rvu, u16 pcifunc, int nixlf,u16 vf_func;/* Only CGX PF/VF can add allmulticast entry */ -if (is_lbk_vf (rvu, pcifunc) &&is_sdp_vf (rvu, pcifunc)) +if (is_lbk_vf (rvu, pcifunc) ||is_sdp_vf (rvu, pcifunc))return ; blkaddr =rvu_get_blkaddr (rvu,BLKTYPE_NPC ,0 );
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 268/272 net: mana: validate rx_req_idx to prevent out-of-bounds array access
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aditya Garg <[email protected]>
[ Upstream commit b809d0409991b75a6cff846a5ac27c3062953f84 ]
In mana_hwc_rx_event_handler(), rx_req_idx is derived from sge->address in DMA-coherent memory. In Confidential VMs (SEV-SNP/TDX), this memory is shared unencrypted and HW can modify WQE contents at any time. No bounds check exists on rx_req_idx, which can lead to an out-of-bounds access into reqs[].
Add bounds check on rx_req_idx in mana_hwc_rx_event_handler() before using it to index the reqs[] array.
--- drivers/net/ethernet/microsoft/mana/hw_channel.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/net/ethernet/microsoft/mana/hw_channel.c +6 -0
@@ -233,6 +233,12 @@ static void mana_hwc_rx_event_handler(void *ctx, u32 gdma_rxq_id, rq_base_addr = hwc_rxq->msg_buf->mem_info.dma_handle; rx_req_idx = (sge->address - rq_base_addr) / hwc->max_req_msg_size; +if (rx_req_idx >= hwc_rxq->msg_buf->num_reqs) { +dev_err (hwc->dev,"HWC RX: wrong rx_req_idx=%llu, num_reqs=%u\n" , + rx_req_idx, hwc_rxq->msg_buf->num_reqs); +return ; + } + rx_req = &hwc_rxq->msg_buf->reqs[rx_req_idx]; resp = (struct gdma_resp_hdr *)rx_req->buf_va;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 269/272 pds_core: ensure null-termination for firmware version strings
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nikhil P. Rao <[email protected]>
[ Upstream commit 3d4432d34c1992701289cbe12df9fd024f315998 ]
The driver passes fw_version directly to devlink_info_version_stored_put() without ensuring null-termination. While current firmware null-terminates these strings, the driver should not rely on this behavior. Add explicit null-termination to prevent potential issues if firmware behavior changes.
--- drivers/net/ethernet/amd/pds_core/devlink.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/net/ethernet/amd/pds_core/devlink.c +4 -2
@@ -121,12 +121,14 @@ int pdsc_dl_info_get(struct devlink *dl, struct devlink_info_req *req, listlen =min (fw_list.num_fw_slots,ARRAY_SIZE (fw_list.fw_names));for (i =0 ; i < listlen; i++) { +char *fw_ver = fw_list.fw_names[i].fw_version; +if (i <ARRAY_SIZE (fw_slotnames))strscpy (buf, fw_slotnames[i],sizeof (buf));else snprintf (buf,sizeof (buf),"fw.slot_%d" , i); - err =devlink_info_version_stored_put (req, buf, - fw_list.fw_names[i].fw_version); + fw_ver[sizeof (fw_list.fw_names[i].fw_version) -1 ] ='\0' ; + err =devlink_info_version_stored_put (req, buf, fw_ver);if (err)return err; }
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 270/272 net: gro: dont merge zcopy skbs
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sabrina Dubroca <[email protected]>
[ Upstream commit 4db79a322db8c97f7b73b8a347395ef4d685eb40 ]
skb_gro_receive() can currently copy frags between the source and GRO skb, without checking the zerocopy status, and in particular the SKBFL_MANAGED_FRAG_REFS flag.
When SKBFL_MANAGED_FRAG_REFS is set, the skb doesn't hold a reference on the pages in shinfo->frags. Appending those frags to another skb's frags without fixing up the page refcount can lead to UAF.
When either the last skb in the GRO chain (the one we would append frags to) or the source skb is zerocopy, don't merge the skbs.
--- net/core/gro.c | 3 +++ 1 file changed, 3 insertions(+)
net/core/gro.c +3 -0
@@ -108,6 +108,9 @@ int skb_gro_receive(struct sk_buff *p, struct sk_buff *skb)if (p->pp_recycle != skb->pp_recycle)return -ETOOMANYREFS ; +if (skb_zcopy (p) ||skb_zcopy (skb)) +return -ETOOMANYREFS ; +if (unlikely (p->len + len >=netif_get_gro_max_size (p->dev, p) ||NAPI_GRO_CB (skb)->flush))return -E2BIG ;
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 271/272 LoongArch: kprobes: Fix handling of fatal unrecoverable recursions
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tiezhu Yang <[email protected]>
[ Upstream commit 1c856e158fd34ef2c4475a81c1dc386329989938 ]
KPROBE_HIT_SS and KPROBE_REENTER are two types of fatal recursions that can not be safely recovered in kprobes.
KPROBE_HIT_SS means that a kprobe is hit during single-stepping. At this point, the architecture-specific single-step context is already active. Nested single-stepping would corrupt the state, as the kprobe control block (kcb) and hardware registers cannot safely store multiple levels of stepping state.
KPROBE_REENTER means that a third-level recursion occurs when a probe is hit while the system is already handling a nested probe (second- level). The kcb only provides a single slot (prev_kprobe) to backup the state. When a third probe is hit, there is no more space to save the state without corrupting the first-level backup.
Kprobes work by replacing instructions with breakpoints. In order to execute the original instruction and continue, it must be moved to a temporary "single-step" slot. Since there is no backup space left to set up this slot safely, the CPU would be forced to return to the same original breakpoint address, triggering an endless loop.
Currently, the code only prints a warning and returns. This leads to an infinite re-entry loop as the CPU repeatedly hits the same trap and a "stuck" CPU core because preemption was disabled at the start of the handler and never re-enabled in this early return path.
Fix the logic by:
1. Merging KPROBE_HIT_SS and KPROBE_REENTER cases, as both represent fatal recursions that cannot be safely recovered.
2. Replacing WARN_ON_ONCE() with BUG() to terminate the system. This aligns LoongArch with other architectures (x86, arm64, riscv) and prevents stack overflow while providing diagnostic information.
--- arch/loongarch/kernel/kprobes.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/loongarch/kernel/kprobes.c +2 -2
@@ -184,16 +184,16 @@ static bool reenter_kprobe(struct kprobe *p, struct pt_regs *regs, struct kprobe_ctlblk *kcb) {switch (kcb->kprobe_status) { -case KPROBE_HIT_SS :case KPROBE_HIT_SSDONE :case KPROBE_HIT_ACTIVE :kprobes_inc_nmissed_count (p);setup_singlestep (p, regs, kcb,1 );break ; +case KPROBE_HIT_SS :case KPROBE_REENTER :pr_warn ("Failed to recover from reentered kprobes.\n" );dump_kprobe (p); -WARN_ON_ONCE (1 ); +BUG ();break ;default :WARN_ON (1 );
Signature · 1 line
2.53.0
Greg Kroah-Hartman
maintainerPATCH 272/272 landlock: Fix TCP handling of short AF_UNSPEC addresses
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthieu Buffet <[email protected]>
[ Upstream commit e4d82cbce2258f454634307fdabf33aa46b61ab0 ]
current_check_access_socket() treats AF_UNSPEC addresses as AF_INET ones, and only later adds special case handling to allow connect(AF_UNSPEC), and on IPv4 sockets bind(AF_UNSPEC+INADDR_ANY).
This would be fine except AF_UNSPEC addresses can be as short as a bare AF_UNSPEC sa_family_t field, and nothing more. The AF_INET code path incorrectly enforces a length of sizeof(struct sockaddr_in) instead.
Move AF_UNSPEC edge case handling up inside the switch-case, before the address is (potentially incorrectly) treated as AF_INET.
[ There was a conflict due to missing commit 9f74411a40ce ("landlock:
Log TCP bind and connect denials") ]
--- security/landlock/net.c | 118 +++++++++++++++++++++++----------------- 1 file changed, 67 insertions(+), 51 deletions(-)
security/landlock/net.c +67 -51
@@ -72,6 +72,61 @@ static int current_check_access_socket(struct socket *const sock,switch (address->sa_family) {case AF_UNSPEC : +if (access_request ==LANDLOCK_ACCESS_NET_CONNECT_TCP ) { +/* +* Connecting to an address with AF_UNSPEC dissolves +* the TCP association, which have the same effect as +* closing the connection while retaining the socket +* object (i.e., the file descriptor). As for dropping +* privileges, closing connections is always allowed. +* +* For a TCP access control system, this request is +* legitimate. Let the network stack handle potential +* inconsistencies and return -EINVAL if needed. +*/ +return 0 ; + }else if (access_request ==LANDLOCK_ACCESS_NET_BIND_TCP ) { +/* +* Binding to an AF_UNSPEC address is treated +* differently by IPv4 and IPv6 sockets. The socket's +* family may change under our feet due to +* setsockopt(IPV6_ADDRFORM), but that's ok: we either +* reject entirely or require +* %LANDLOCK_ACCESS_NET_BIND_TCP for the given port, so +* it cannot be used to bypass the policy. +* +* IPv4 sockets map AF_UNSPEC to AF_INET for +* retrocompatibility for bind accesses, only if the +* address is INADDR_ANY (cf. __inet_bind). IPv6 +* sockets always reject it. +* +* Checking the address is required to not wrongfully +* return -EACCES instead of -EAFNOSUPPORT or -EINVAL. +* We could return 0 and let the network stack handle +* these checks, but it is safer to return a proper +* error and test consistency thanks to kselftest. +*/ +if (sock->sk->__sk_common.skc_family ==AF_INET ) { +const struct sockaddr_in *const sockaddr = + (struct sockaddr_in *)address; + +if (addrlen <sizeof (struct sockaddr_in )) +return -EINVAL ; + +if (sockaddr->sin_addr.s_addr != +htonl (INADDR_ANY )) +return -EAFNOSUPPORT ; + }else { +if (addrlen <SIN6_LEN_RFC2133 ) +return -EINVAL ; +else +return -EAFNOSUPPORT ; + } + }else { +WARN_ON_ONCE (1 ); + } +/* Only for bind(AF_UNSPEC+INADDR_ANY) on IPv4 socket. */ + fallthrough;case AF_INET :if (addrlen <sizeof (struct sockaddr_in ))return -EINVAL ;
@@ -90,57 +145,18 @@ static int current_check_access_socket(struct socket *const sock,return 0 ; } -/* Specific AF_UNSPEC handling. */ -if (address->sa_family ==AF_UNSPEC ) { -/* -* Connecting to an address with AF_UNSPEC dissolves the TCP -* association, which have the same effect as closing the -* connection while retaining the socket object (i.e., the file -* descriptor). As for dropping privileges, closing -* connections is always allowed. -* -* For a TCP access control system, this request is legitimate. -* Let the network stack handle potential inconsistencies and -* return -EINVAL if needed. -*/ -if (access_request ==LANDLOCK_ACCESS_NET_CONNECT_TCP ) -return 0 ; - -/* -* For compatibility reason, accept AF_UNSPEC for bind -* accesses (mapped to AF_INET) only if the address is -* INADDR_ANY (cf. __inet_bind). Checking the address is -* required to not wrongfully return -EACCES instead of -* -EAFNOSUPPORT. -* -* We could return 0 and let the network stack handle these -* checks, but it is safer to return a proper error and test -* consistency thanks to kselftest. -*/ -if (access_request ==LANDLOCK_ACCESS_NET_BIND_TCP ) { -/* addrlen has already been checked for AF_UNSPEC. */ -const struct sockaddr_in *const sockaddr = - (struct sockaddr_in *)address; - -if (sock->sk->__sk_common.skc_family !=AF_INET ) -return -EINVAL ; - -if (sockaddr->sin_addr.s_addr !=htonl (INADDR_ANY )) -return -EAFNOSUPPORT ; - } - }else { -/* -* Checks sa_family consistency to not wrongfully return -* -EACCES instead of -EINVAL. Valid sa_family changes are -* only (from AF_INET or AF_INET6) to AF_UNSPEC. -* -* We could return 0 and let the network stack handle this -* check, but it is safer to return a proper error and test -* consistency thanks to kselftest. -*/ -if (address->sa_family != sock->sk->__sk_common.skc_family) -return -EINVAL ; - } +/* +* Checks sa_family consistency to not wrongfully return +* -EACCES instead of -EINVAL. Valid sa_family changes are +* only (from AF_INET or AF_INET6) to AF_UNSPEC. +* +* We could return 0 and let the network stack handle this +* check, but it is safer to return a proper error and test +* consistency thanks to kselftest. +*/ +if (address->sa_family != sock->sk->__sk_common.skc_family && + address->sa_family !=AF_UNSPEC ) +return -EINVAL ; id.key.data = (__force uintptr_t )port;BUILD_BUG_ON (sizeof (port) >sizeof (id.key.data));
Signature · 1 line
2.53.0
PATCH 1/1 selftests/landlock: Add missing connect(minimal AF_UNSPEC) test
From: Matthieu Buffet <[email protected]>
[ Upstream commit 6685201ebfacff0c889bcd569181fa6e8af5575e ]
connect_variant(unspec_any0) is called twice. Both calls end up in connect_variant_addrlen() with an address length of get_addrlen(minimal=false).
However, the connect() syscall and its variants (e.g. iouring/compat) accept much shorter addresses of 4 bytes and that behaviour was not tested.
Replace one of these calls with one using a minimal address length (just a bare sa_family=AF_UNSPEC field with no actual address). Also add a call using a truncated address for good measure.
--- tools/testing/selftests/landlock/net_test.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-)
tools/testing/selftests/landlock/net_test.c +13 -1
@@ -905,7 +905,19 @@ TEST_F(protocol, connect_unspec)EXPECT_EQ (0 ,close (ruleset_fd)); } - ret =connect_variant (connect_fd, &self->unspec_any0); +/* Try to re-disconnect with a truncated address struct. */ +EXPECT_EQ (-EINVAL , +connect_variant_addrlen ( + connect_fd, &self->unspec_any0, +get_addrlen (&self->unspec_any0, true) -1 )); + +/* +* Re-disconnect, with a minimal sockaddr struct (just a +* bare af_family=AF_UNSPEC field). +*/ + ret =connect_variant_addrlen (connect_fd, &self->unspec_any0, +get_addrlen (&self->unspec_any0, + true));if (self->srv0.protocol.domain ==AF_UNIX && self->srv0.protocol.type ==SOCK_STREAM ) {EXPECT_EQ (-EINVAL , ret);
Re: [PATCH 6.12.y] selftests/landlock: Add missing connect(minimal AF_UNSPEC) test
Quoted 5 lines
[ Upstream commit
6685201ebfacff0c889bcd569181fa6e8af5575e]
connect_variant(unspec_any0)is called twice. Both calls end up inconnect_variant_addrlen()with an address length ofget_addrlen(minimal=false).
Queued for 6.18 and 6.12, thanks.
Signature · 2 lines
Thanks, Sasha
Greg Kroah-Hartman wrote on Thu, May 28, 2026 at 09:46:14PM +0200:
Quoted 5 lines
This is the start of the stable review cycle for the 6.12.92 release. There are 272 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.
Quoted 8 lines
Responses should be made by Sat, 30 May 2026 19:45:52 +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.92-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.
Tested 97928cc88900 ("Linux 6.12.92-rc1") on:
- arm i.MX6ULL (Armadillo 640)
- arm64 i.MX8ULP (Armadillo IoT A9E)
No obvious regression in dmesg or basic tests:
Signature · 1 line
Dominique Martinet
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.92 release. There are 272 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 Sat, 30 May 2026 19:45:52 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.92-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 8 lines · On Thu, 28 May 2026 21:46:14 +0200 Greg Kroah-Hartman…
This is the start of the stable review cycle for the 6.12.92 release. There are 272 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 Sat, 30 May 2026 19:45:52 +0000. Anything received after that time might be too late.
Boot-tested under QEMU for Rust x86_64, arm64 and riscv64; built-tested for loongarch64:
I am seeing:
In file included from kernel/trace/blktrace.c:23:
In file included from kernel/trace/../../block/blk.h:5:
./include/linux/bio-integrity.h:101:12: error: unused function 'bio_integrity_map_user' [-Werror,-Wunused-function]
101 | static int bio_integrity_map_user(struct bio *bio, struct iov_iter *iter)
| ^~~~~~~~~~~~~~~~~~~~~~
This looks like it needs:
546d191427cf ("block: make bio_integrity_map_user() static inline")
(and indeed in my run CONFIG_BLK_DEV_INTEGRITY is not set like the commit message says).
Thanks!
Cheers,
Miguel
Hi!
Quoted 13 lines
Quoted 7 lines
This is the start of the stable review cycle for the 6.12.92 release. There are 272 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 Sat, 30 May 2026 19:45:52 +0000. Anything received after that time might be too late.
Boot-tested under QEMU for Rust
x86_64, arm64 and riscv64; built-tested for loongarch64:Tested-by Miguel Ojeda <[email protected]>
Quoted 8 lines
I am seeing:
In file included from
kernel/trace/blktrace.c:23:
In file included fromkernel/trace/../../block/blk.h:5:
./include/linux/bio-integrity.h:101:12: error: unused function 'bio_integrity_map_user' [-Werror,-Wunused-function]
101 | static intbio_integrity_map_user(struct bio *bio, struct iov_iter *iter)
| ^~~~~~~~~~~~~~~~~~~~~~
We see that, too:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/jobs/14592368004
We don't see the problem on 6.6, 6.18 or 7.0-stable.
Best regards,
Pavel
Sasha Levin
maintainerQuoted 11 lines · Pavel Machek
Quoted 8 lines
I am seeing:
./include/linux/bio-integrity.h:101:12: error: unused function 'bio_integrity_map_user' [-Werror,-Wunused-function]This looks like it needs:
546d191427cf("block: makebio_integrity_map_user()static inline")We see that, too:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/jobs/14592368004
We don't see the problem on 6.6, 6.18 or 7.0-stable.
Thanks! I've queued up 546d191427cf ("block: make bio_integrity_map_user() static inline").
--
Thanks,
Sasha
Quoted 7 lines · Sasha Levin
Quoted 6 lines · Pavel Machek
Quoted 6 lines
I am seeing:
./include/linux/bio-integrity.h:101:12: error: unused function 'bio_integrity_map_user' [-Werror,-Wunused-function]This looks like it needs:
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
546d191427cf ("block: make bio_integrity_map_user() static inline")We see that, too:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/jobs/14592368004
We don't see the problem on 6.6, 6.18 or 7.0-stable.Thanks! I've queued up
546d191427cf("block: makebio_integrity_map_user()static inline").
Thanks, also seen here, FWIW.
Signature · 1 line
Florian
Peter Schneider
Tested-byAm 29.05.2026 um 08:09 schrieb Miguel Ojeda:
Quoted 23 lines · On Thu, 28 May 2026 21:46:14 +0200 Greg Kroah-Hartman…
Quoted 8 lines
This is the start of the stable review cycle for the 6.12.92 release. There are 272 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 Sat, 30 May 2026 19:45:52 +0000. Anything received after that time might be too late.
Boot-tested under QEMU for Rust
x86_64, arm64 and riscv64; built-tested for loongarch64:Tested-by Miguel Ojeda <[email protected]>I am seeing:
In file included from
kernel/trace/blktrace.c:23:
In file included fromkernel/trace/../../block/blk.h:5:
./include/linux/bio-integrity.h:101:12: error: unused function 'bio_integrity_map_user' [-Werror,-Wunused-function]
101 | static intbio_integrity_map_user(struct bio *bio, struct iov_iter *iter)
| ^~~~~~~~~~~~~~~~~~~~~~
Quoted 6 lines
This looks like it needs:
546d191427cf ("block: make bio_integrity_map_user() static inline")(and indeed in my run
CONFIG_BLK_DEV_INTEGRITYis not set like the commit message says).
I didn't see this error message on x86_64; I built with CONFIG_WERROR=y and CONFIG_BLK_DEV_INTEGRITY=y
Builds, boots and works on my 2-socket Ivy Bridge Xeon E5-2697 v2 server. No dmesg oddities or regressions found.
Beste Grüße,
Peter Schneider
Signature · 8 lines
Climb the mountain not to plant your flag, but to embrace the challenge, enjoy the air and behold the view. Climb it so you can see the world, not so the world can see you. -- David McCullough Jr. OpenPGP: 0xA3828BD796CCE11A8CADE8866E3A92C92C3FF244 Download: https://www.peters-netzplatz.de/download/pschneider1968_pub.asc https://keys.mailvelope.com/pks/lookup?op=get&[email protected] https://keys.mailvelope.com/pks/lookup?op=get&[email protected]
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.92 release. There are 272 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.
# Librecast Test Results
020/020 [ OK ] liblcrq
010/010 [ OK ] libmld
120/120 [ OK ] liblibrecast
CPU/kernel: Linux auntie 6.12.92-rc1-g97928cc88900 #1 SMP PREEMPT_DYNAMIC Fri May 29 06:06:22 -00 2026 x86_64 AMD Ryzen 9 9950X 16-Core Processor AuthenticAMD GNU/Linux
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.92 release. There are 272 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 Sat, 30 May 2026 19:45:52 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.92-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.92 release. There are 272 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.