--- /dev/null
+From 3349ef6a366a61d631f6a263d12cea240957719d Mon Sep 17 00:00:00 2001
+From: Christian Brauner <brauner@kernel.org>
+Date: Tue, 21 Jul 2026 13:20:45 +0200
+Subject: binfmt_elf_fdpic: only honour the first PT_INTERP
+
+From: Christian Brauner <brauner@kernel.org>
+
+commit 3349ef6a366a61d631f6a263d12cea240957719d upstream.
+
+The program header scan handles PT_INTERP from a switch nested in the
+scan loop, so its break leaves the switch and not the loop. A binary
+carrying more than one PT_INTERP runs the case again and overwrites both
+interpreter_name and interpreter. The previous name allocation leaks and
+so does the previous interpreter reference, along with the write denial
+open_exec() took on it. The denial is never released, so the file stays
+unwritable for as long as the system runs.
+
+An unprivileged caller reaches this with a crafted binary and repeats it
+at will. binfmt_elf stops at the first PT_INTERP. Do the same here.
+
+The flaw dates back to the driver's introduction in the pre-git history
+tree introduced in v2.6.11 by 91808d6ebe39 ("[PATCH] FRV: Add FDPIC ELF
+binary format driver").
+
+Link: https://patch.msgid.link/20260721-gezittert-medium-kreide-b41fc1f0277e@brauner
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Cc: stable@vger.kernel.org
+Reviewed-by: Jori Koolstra <jkoolstra@xs4all.nl>
+Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/binfmt_elf_fdpic.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/fs/binfmt_elf_fdpic.c
++++ b/fs/binfmt_elf_fdpic.c
+@@ -231,6 +231,10 @@ static int load_elf_fdpic_binary(struct
+ for (i = 0; i < exec_params.hdr.e_phnum; i++, phdr++) {
+ switch (phdr->p_type) {
+ case PT_INTERP:
++ /* elf ABI allows only one interpreter */
++ if (interpreter_name)
++ continue;
++
+ retval = -ENOMEM;
+ if (phdr->p_filesz > PATH_MAX)
+ goto error;
--- /dev/null
+From 4dbc71bcaf9a30abf3920a4e2cc4ed33bba78c02 Mon Sep 17 00:00:00 2001
+From: Bryam Vargas <hexlabsecurity@proton.me>
+Date: Fri, 29 May 2026 00:37:24 +0000
+Subject: ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()
+
+From: Bryam Vargas <hexlabsecurity@proton.me>
+
+commit 4dbc71bcaf9a30abf3920a4e2cc4ed33bba78c02 upstream.
+
+ceph_handle_caps() reads snap_trace_len from the wire-format
+ceph_mds_caps header and uses it unconditionally to build a fake
+end pointer (snaptrace + snaptrace_len) that is later handed to
+ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case:
+
+ snaptrace = h + 1;
+ snaptrace_len = le32_to_cpu(h->snap_trace_len);
+ p = snaptrace + snaptrace_len;
+ ...
+ case CEPH_CAP_OP_IMPORT:
+ if (snaptrace_len) {
+ ...
+ if (ceph_update_snap_trace(mdsc, snaptrace,
+ snaptrace + snaptrace_len,
+ false, &realm)) { ... }
+
+ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm
+from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad)
+with the attacker-supplied fake end e == snaptrace + snaptrace_len.
+With snaptrace_len == 0xFFFFFFFF the bound check is trivially
+satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past
+the legitimate msg->front buffer, and ri->num_snaps /
+ri->num_prior_parent_snaps then drive further out-of-bounds
+reads of the encoded snap arrays.
+
+The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks
+above the op switch each catch this OOB through their
+ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit
+behind a hdr.version-gated if, so a malicious or compromised
+MDS that sets msg->hdr.version = 1 reaches the IMPORT path with
+no version-gated decoder having validated snap_trace_len. The
+shape has been present since ceph_handle_caps() was introduced.
+
+Validate snap_trace_len against the message front buffer before
+consuming it, using the canonical ceph_decode_need() / ceph_has_room()
+helper. The helper bounds the length with subtraction (n <= end - p,
+guarded by end >= p) rather than pointer addition, so it is wrap-safe
+for the attacker-controlled u32 length on 32-bit builds where
+p + snap_trace_len could overflow the address space. This matches the
+rest of the ceph decode path (e.g. the pool_ns_len check a few lines
+below), and the existing goto bad cleanup already covers this exit
+path.
+
+Cc: stable@vger.kernel.org
+Fixes: a8599bd821d0 ("ceph: capability management")
+Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
+Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ceph/caps.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/ceph/caps.c
++++ b/fs/ceph/caps.c
+@@ -4067,6 +4067,7 @@ void ceph_handle_caps(struct ceph_mds_se
+
+ snaptrace = h + 1;
+ snaptrace_len = le32_to_cpu(h->snap_trace_len);
++ ceph_decode_need(&snaptrace, end, snaptrace_len, bad);
+ p = snaptrace + snaptrace_len;
+
+ if (msg_version >= 2) {
--- /dev/null
+From 8efb8f8bbb353b8f2fdf4f37534c6d96c9f69e01 Mon Sep 17 00:00:00 2001
+From: Doruk Tan Ozturk <doruk@0sec.ai>
+Date: Thu, 16 Jul 2026 22:35:00 +0200
+Subject: geneve: require CAP_NET_ADMIN in the device netns for changelink
+
+From: Doruk Tan Ozturk <doruk@0sec.ai>
+
+commit 8efb8f8bbb353b8f2fdf4f37534c6d96c9f69e01 upstream.
+
+A tunnel changelink() operates on at most two netns, dev_net(dev) and
+the sticky underlay netns geneve->net. They differ once the device is
+created in or moved to a netns other than the one the request runs in.
+The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev),
+so a caller privileged there but not in geneve->net can rewrite a geneve
+device whose underlay lives in geneve->net.
+
+geneve_changelink() applies the new configuration against geneve->net:
+geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair
+reopen the underlay sockets in that netns (geneve_sock_add() uses
+geneve->net), so the same reasoning as the tunnel changelink series
+applies here.
+
+Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of
+the op before any attribute is parsed, matching ipgre_changelink() and
+the rest of the "require CAP_NET_ADMIN in the device netns for
+changelink" series.
+
+Found by 0sec automated security-research tooling (https://0sec.ai).
+
+Fixes: 5b861f6baa3a ("geneve: add rtnl changelink support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
+Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
+Link: https://patch.msgid.link/20260716203500.70573-3-doruk@0sec.ai
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/geneve.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/net/geneve.c
++++ b/drivers/net/geneve.c
+@@ -1754,6 +1754,9 @@ static int geneve_changelink(struct net_
+ struct geneve_config cfg;
+ int err;
+
++ if (!rtnl_dev_link_net_capable(dev, geneve->net))
++ return -EPERM;
++
+ /* If the geneve device is configured for metadata (or externally
+ * controlled, for example, OVS), then nothing can be changed.
+ */
--- /dev/null
+From 780dfed688622ea01be3c9c2c55eec2207f05e04 Mon Sep 17 00:00:00 2001
+From: Lu Baolu <baolu.lu@linux.intel.com>
+Date: Thu, 16 Jul 2026 13:35:53 +0800
+Subject: iommu/vt-d: Disallow SVA if page walk is not coherent
+
+From: Lu Baolu <baolu.lu@linux.intel.com>
+
+commit 780dfed688622ea01be3c9c2c55eec2207f05e04 upstream.
+
+Hardware implementations report Scalable-Mode Page-walk Coherency Support
+via the SMPWCS field in the extended capability register. If the hardware
+does not support page-walk coherency, a clflush is required every time
+the page table entries (which are walked by the IOMMU hardware) are
+updated.
+
+In the SVA case, page tables are managed by the CPU mm core, not by the
+IOMMU driver. Because the IOMMU driver has no way of knowing whether the
+CPU page table management code has ensured coherency via clflush, the
+driver must deny SVA if the hardware does not support coherent paging.
+
+Fixes: ff3dc6521f78 ("iommu/vt-d: Fix CPU and IOMMU SVM feature matching checks")
+Cc: stable@vger.kernel.org
+Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
+Reviewed-by: Kevin Tian <kevin.tian@intel.com>
+Reviewed-by: Samiullah Khawaja <skhawaja@google.com>
+Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iommu/intel/svm.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/iommu/intel/svm.c
++++ b/drivers/iommu/intel/svm.c
+@@ -175,7 +175,7 @@ static inline bool intel_svm_capable(str
+
+ void intel_svm_check(struct intel_iommu *iommu)
+ {
+- if (!pasid_supported(iommu))
++ if (!pasid_supported(iommu) || !ecap_smpwc(iommu->ecap))
+ return;
+
+ if (cpu_feature_enabled(X86_FEATURE_GBPAGES) &&
--- /dev/null
+From d3c32939fa0e3ee9b883b9a0fd1972c5c444e3d0 Mon Sep 17 00:00:00 2001
+From: Douya Le <ldy3087146292@gmail.com>
+Date: Sun, 7 Jun 2026 17:35:49 +0800
+Subject: libceph: bound get_version reply decode to front len
+
+From: Douya Le <ldy3087146292@gmail.com>
+
+commit d3c32939fa0e3ee9b883b9a0fd1972c5c444e3d0 upstream.
+
+handle_get_version_reply() uses msg->front_alloc_len as the decode
+boundary for MON_GET_VERSION_REPLY. That is the size of the reused
+reply buffer, not the number of bytes actually received.
+
+A truncated reply can therefore pass ceph_decode_need() and decode the
+second u64 from stale tail bytes left in the buffer by an earlier
+message, causing an uninitialized memory read.
+
+Use msg->front.iov_len as the receive-side decode boundary, matching
+other libceph reply handlers and limiting decoding to the bytes that
+were actually read from the wire.
+
+Cc: stable@vger.kernel.org
+Fixes: 513a8243d67f ("libceph: mon_get_version request infrastructure")
+Reported-by: Yuan Tan <yuantan098@gmail.com>
+Reported-by: Zhengchuan Liang <zcliangcn@gmail.com>
+Reported-by: Xin Liu <bird@lzu.edu.cn>
+Assisted-by: Codex:GPT-5.4
+Signed-off-by: Douya Le <ldy3087146292@gmail.com>
+Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
+Reviewed-by: Viacheslav Dubeyko <slava@dubeyko.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ceph/mon_client.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/ceph/mon_client.c
++++ b/net/ceph/mon_client.c
+@@ -821,7 +821,7 @@ static void handle_get_version_reply(str
+ struct ceph_mon_generic_request *req;
+ u64 tid = le64_to_cpu(msg->hdr.tid);
+ void *p = msg->front.iov_base;
+- void *end = p + msg->front_alloc_len;
++ void *const end = p + msg->front.iov_len;
+ u64 handle;
+
+ dout("%s msg %p tid %llu\n", __func__, msg, tid);
--- /dev/null
+From 98917a499ec7064c14fc56d180a4fd636fc2784c Mon Sep 17 00:00:00 2001
+From: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+Date: Wed, 27 May 2026 16:06:17 +0200
+Subject: libceph: Fix multiplication overflow in decode_new_up_state_weight()
+
+From: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+
+commit 98917a499ec7064c14fc56d180a4fd636fc2784c upstream.
+
+If a message of type CEPH_MSG_OSD_MAP contains a (maliciously) corrupted
+osdmap, out-of-bounds memory accesses may occur in
+decode_new_up_state_weight(). This happens because the bounds check for
+the new_state part is based on calculating its length depending on a len
+value read from the incoming message. This calculation may overflow
+leading to an incorrect bounds check. Subsequently, out-of-bounds reads
+may occur when decoding this part.
+
+This patch switches the multiplication to use check_mul_overflow() to
+abort processing the osdmap if an overflow occurred. Therefore,
+osdmaps/messages containing large values for len that result in a
+multiplication overflow are treated as invalid.
+
+[ idryomov: rename new_state_len -> new_state_item_size, formatting ]
+
+Cc: stable@vger.kernel.org
+Fixes: 930c53286977 ("libceph: apply new_state before new_up_client on incrementals")
+Signed-off-by: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ceph/osdmap.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/net/ceph/osdmap.c
++++ b/net/ceph/osdmap.c
+@@ -1830,6 +1830,8 @@ static int decode_new_up_state_weight(vo
+ void *new_up_client;
+ void *new_state;
+ void *new_weight_end;
++ const u32 new_state_item_size =
++ sizeof(u32) + (struct_v >= 5 ? sizeof(u32) : sizeof(u8));
+ u32 len;
+ int ret;
+ int i;
+@@ -1850,7 +1852,8 @@ static int decode_new_up_state_weight(vo
+
+ new_state = *p;
+ ceph_decode_32_safe(p, end, len, e_inval);
+- len *= sizeof(u32) + (struct_v >= 5 ? sizeof(u32) : sizeof(u8));
++ if (check_mul_overflow(len, new_state_item_size, &len))
++ goto e_inval;
+ ceph_decode_need(p, end, len, e_inval);
+ *p += len;
+
--- /dev/null
+From bbeae12fda3384a90fbebc8a19ba9d33f85b5361 Mon Sep 17 00:00:00 2001
+From: Zhao Zhang <zzhan461@ucr.edu>
+Date: Fri, 19 Jun 2026 15:40:03 +0800
+Subject: libceph: guard missing CRUSH type name lookup
+
+From: Zhao Zhang <zzhan461@ucr.edu>
+
+commit bbeae12fda3384a90fbebc8a19ba9d33f85b5361 upstream.
+
+Localized read selection can walk a parent bucket whose name exists in
+the CRUSH map while its type has no matching entry in type_names.
+get_immediate_parent() then dereferences a NULL type_cn and passes an
+invalid pointer into strcmp(), causing a null-ptr-deref.
+
+Skip such malformed parent buckets unless both the bucket name and type
+name metadata are present. This keeps malformed hierarchy data from
+crashing locality lookup and safely falls back to "not local".
+
+[ idryomov: add WARN_ON_ONCE ]
+
+Cc: stable@vger.kernel.org
+Fixes: 117d96a04f00 ("libceph: support for balanced and localized reads")
+Reported-by: Yuan Tan <yuantan098@gmail.com>
+Reported-by: Zhengchuan Liang <zcliangcn@gmail.com>
+Reported-by: Xin Liu <bird@lzu.edu.cn>
+Assisted-by: Codex:GPT-5.4
+Signed-off-by: Zhao Zhang <zzhan461@ucr.edu>
+Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
+Reviewed-by: Viacheslav Dubeyko <slava@dubeyko.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ceph/osdmap.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/net/ceph/osdmap.c
++++ b/net/ceph/osdmap.c
+@@ -3040,8 +3040,11 @@ static int get_immediate_parent(struct c
+ if (b->items[j] != id)
+ continue;
+
+- *parent_type_id = b->type;
+ type_cn = lookup_crush_name(&c->type_names, b->type);
++ if (WARN_ON_ONCE(!type_cn))
++ continue;
++
++ *parent_type_id = b->type;
+ parent_loc->cl_type_name = type_cn->cn_name;
+ parent_loc->cl_name = cn->cn_name;
+ return b->id;
--- /dev/null
+From 937d61f86d377a3aa578adae7a3dfcecdddf9d89 Mon Sep 17 00:00:00 2001
+From: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
+Date: Mon, 29 Jun 2026 13:14:22 -0400
+Subject: libceph: refresh auth->authorizer_buf{,_len} after authorizer update
+
+From: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
+
+commit 937d61f86d377a3aa578adae7a3dfcecdddf9d89 upstream.
+
+ceph_x_create_authorizer() caches au->buf->vec.iov_base and
+au->buf->vec.iov_len in struct ceph_auth_handshake. These
+cached values are then used by the messenger connect code when
+sending the authorizer.
+
+ceph_x_update_authorizer() can rebuild the authorizer when a newer
+service ticket is available. If the rebuilt authorizer no longer
+fits in the existing buffer, ceph_x_build_authorizer() drops its
+reference to au->buf and allocates a new one. If this is the final
+reference, ceph_buffer_put() frees the old ceph_buffer and its
+vec.iov_base, but auth->authorizer_buf still points at that freed
+memory.
+
+A subsequent msgr1 reconnect can therefore queue the stale pointer
+and trigger a KASAN slab-use-after-free in _copy_from_iter() while
+tcp_sendmsg() copies the authorizer.
+
+Refresh auth->authorizer_buf and auth->authorizer_buf_len after a
+successful authorizer rebuild so the messenger sends the current
+buffer.
+
+Cc: stable@vger.kernel.org
+Fixes: 0bed9b5c523d ("libceph: add update_authorizer auth method")
+Closes: https://lore.kernel.org/all/E378850E-106C-427B-A241-970EB2D054D7@gmail.com/
+Signed-off-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
+Reviewed-by: Alex Markuze <amarkuze@redhat.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ceph/auth_x.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+--- a/net/ceph/auth_x.c
++++ b/net/ceph/auth_x.c
+@@ -781,9 +781,16 @@ static int ceph_x_update_authorizer(
+
+ au = (struct ceph_x_authorizer *)auth->authorizer;
+ if (au->secret_id < th->secret_id) {
++ int ret;
++
+ dout("ceph_x_update_authorizer service %u secret %llu < %llu\n",
+ au->service, au->secret_id, th->secret_id);
+- return ceph_x_build_authorizer(ac, th, au);
++ ret = ceph_x_build_authorizer(ac, th, au);
++ if (ret)
++ return ret;
++
++ auth->authorizer_buf = au->buf->vec.iov_base;
++ auth->authorizer_buf_len = au->buf->vec.iov_len;
+ }
+ return 0;
+ }
--- /dev/null
+From 40480eee361ed9676b3f844d532ac28b47251634 Mon Sep 17 00:00:00 2001
+From: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+Date: Fri, 29 May 2026 09:42:57 +0200
+Subject: libceph: Reject monmaps advertising zero monitors
+
+From: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+
+commit 40480eee361ed9676b3f844d532ac28b47251634 upstream.
+
+A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a
+monitor to the client. This monmap contains information about the
+existing monitors in the cluster. Currently, a monmap indicating that
+there are zero monitors in the cluster is treated as valid. However, it
+is impossible to have zero monitors in the cluster and still receive a
+valid monmap from a monitor. Therefore, such a monmap must be corrupted
+and should be treated as invalid. Furthermore, a monmap with a monitor
+count of zero can subsequently crash the client when attempting to open
+a session with a monitor in __open_session(). This happens because the
+"BUG_ON(monc->monmap->num_mon < 1)" assertion in pick_new_mon() is
+triggered.
+
+This patch extends a check in ceph_monmap_decode() to also reject
+arriving mon_maps with num_mon == 0 rather than only with
+num_mon > CEPH_MAX_MON.
+
+[ idryomov: drop "log output for unusual values of num_mon" part ]
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ceph/mon_client.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/ceph/mon_client.c
++++ b/net/ceph/mon_client.c
+@@ -114,7 +114,7 @@ static struct ceph_monmap *ceph_monmap_d
+
+ dout("%s fsid %pU epoch %u num_mon %u\n", __func__, &fsid, epoch,
+ num_mon);
+- if (num_mon > CEPH_MAX_MON)
++ if (num_mon == 0 || num_mon > CEPH_MAX_MON)
+ goto e_inval;
+
+ monmap = kmalloc(struct_size(monmap, mon_inst, num_mon), GFP_NOIO);
--- /dev/null
+From 05f90284223381005d6bcddab3fda4a97f9c3401 Mon Sep 17 00:00:00 2001
+From: Douya Le <ldy3087146292@gmail.com>
+Date: Fri, 29 May 2026 16:11:44 +0800
+Subject: libceph: reject zero bucket types in crush_decode
+
+From: Douya Le <ldy3087146292@gmail.com>
+
+commit 05f90284223381005d6bcddab3fda4a97f9c3401 upstream.
+
+CRUSH bucket type 0 is reserved for devices. The mapper relies on
+that invariant and uses type 0 to identify leaf devices.
+
+If crush_decode() accepts a bucket with type 0, a malformed CRUSH map
+can make the mapper treat a negative bucket ID as a device and pass it
+to is_out(), which then indexes the OSD weight array with a negative
+value.
+
+Reject zero bucket types while decoding the CRUSH map so the invalid
+state never reaches the mapper.
+
+Cc: stable@vger.kernel.org
+Fixes: f24e9980eb86 ("ceph: OSD client")
+Reported-by: Yuan Tan <yuantan098@gmail.com>
+Reported-by: Zhengchuan Liang <zcliangcn@gmail.com>
+Reported-by: Xin Liu <bird@lzu.edu.cn>
+Assisted-by: Codex:GPT-5.4
+Signed-off-by: Douya Le <ldy3087146292@gmail.com>
+Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
+Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ceph/osdmap.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/net/ceph/osdmap.c
++++ b/net/ceph/osdmap.c
+@@ -504,6 +504,8 @@ static struct crush_map *crush_decode(vo
+ ceph_decode_need(p, end, 4*sizeof(u32), bad);
+ b->id = ceph_decode_32(p);
+ b->type = ceph_decode_16(p);
++ if (b->type == 0)
++ goto bad;
+ b->alg = ceph_decode_8(p);
+ if (b->alg != alg) {
+ b->alg = 0;
--- /dev/null
+From e4c804726c4afce3ba648b982d564f6af2cfa328 Mon Sep 17 00:00:00 2001
+From: Douya Le <ldy3087146292@gmail.com>
+Date: Mon, 15 Jun 2026 14:31:06 +0800
+Subject: libceph: remove debugfs files before client teardown
+
+From: Douya Le <ldy3087146292@gmail.com>
+
+commit e4c804726c4afce3ba648b982d564f6af2cfa328 upstream.
+
+ceph_destroy_client() tears down the monitor client before removing
+the per-client debugfs files. A concurrent read of the monmap debugfs
+file can enter monmap_show() after ceph_monc_stop() has freed
+monc->monmap, triggering a use-after-free.
+
+Remove the debugfs files before stopping the OSD and monitor clients.
+debugfs_remove() drains active handlers and prevents new accesses, so
+the debugfs callbacks can no longer race the rest of client teardown.
+
+Cc: stable@vger.kernel.org
+Fixes: 76aa844d5b2f ("ceph: debugfs")
+Reported-by: Yuan Tan <yuantan098@gmail.com>
+Reported-by: Zhengchuan Liang <zcliangcn@gmail.com>
+Reported-by: Xin Liu <bird@lzu.edu.cn>
+Assisted-by: Codex:GPT-5.4
+Signed-off-by: Douya Le <ldy3087146292@gmail.com>
+Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
+Reviewed-by: Viacheslav Dubeyko <slava@dubeyko.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ceph/ceph_common.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/net/ceph/ceph_common.c
++++ b/net/ceph/ceph_common.c
+@@ -783,13 +783,13 @@ void ceph_destroy_client(struct ceph_cli
+
+ atomic_set(&client->msgr.stopping, 1);
+
++ ceph_debugfs_client_cleanup(client);
++
+ /* unmount */
+ ceph_osdc_stop(&client->osdc);
+ ceph_monc_stop(&client->monc);
+ ceph_messenger_fini(&client->msgr);
+
+- ceph_debugfs_client_cleanup(client);
+-
+ ceph_destroy_options(client->options);
+
+ kfree(client);
--- /dev/null
+From 47a5116e56a6b6fe1e909f244e39cd0fc26ceee4 Mon Sep 17 00:00:00 2001
+From: Hidayath Khan <hidayath@linux.ibm.com>
+Date: Thu, 9 Jul 2026 21:17:32 +0200
+Subject: net/af_iucv: fix NULL deref in afiucv_hs_callback_syn()
+
+From: Hidayath Khan <hidayath@linux.ibm.com>
+
+commit 47a5116e56a6b6fe1e909f244e39cd0fc26ceee4 upstream.
+
+afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC.
+If the allocation fails, nsk is NULL.
+
+The connection-refused path is entered when the listen state check
+fails, the accept backlog is full, or nsk is NULL. The code
+unconditionally calls iucv_sock_kill(nsk) in that path.
+
+iucv_sock_kill() does not accept a NULL socket pointer and immediately
+dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL,
+calling iucv_sock_kill(nsk) results in a NULL pointer dereference.
+
+Only call iucv_sock_kill() when a child socket was successfully
+allocated.
+
+Fixes: 3881ac441f64 ("af_iucv: add HiperSockets transport")
+Cc: stable@vger.kernel.org
+Reviewed-by: Alexandra Winter <wintera@linux.ibm.com>
+Signed-off-by: Hidayath Khan <hidayath@linux.ibm.com>
+Link: https://patch.msgid.link/20260709191732.124092-1-hidayath@linux.ibm.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/iucv/af_iucv.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/net/iucv/af_iucv.c
++++ b/net/iucv/af_iucv.c
+@@ -1867,7 +1867,8 @@ static int afiucv_hs_callback_syn(struct
+ afiucv_swap_src_dest(skb);
+ trans_hdr->flags = AF_IUCV_FLAG_SYN | AF_IUCV_FLAG_FIN;
+ err = dev_queue_xmit(skb);
+- iucv_sock_kill(nsk);
++ if (nsk)
++ iucv_sock_kill(nsk);
+ bh_unlock_sock(sk);
+ goto out;
+ }
--- /dev/null
+From 14fa65d10f5696b063a7d8d26e8291ea84a2c6ed Mon Sep 17 00:00:00 2001
+From: Fan Wu <fanwu01@zju.edu.cn>
+Date: Sun, 12 Jul 2026 14:27:29 +0000
+Subject: net: hip04: fix RX buffer leak on build_skb failure
+
+From: Fan Wu <fanwu01@zju.edu.cn>
+
+commit 14fa65d10f5696b063a7d8d26e8291ea84a2c6ed upstream.
+
+When build_skb() fails in hip04_rx_poll(), the driver jumps to the
+refill path without releasing the current RX buffer and its DMA mapping.
+Installing a replacement buffer then overwrites the slot references and
+leaks both resources.
+
+Keep the current slot intact and return budget so NAPI retries the same
+buffer. Also free a newly allocated RX fragment when dma_map_single()
+fails.
+
+This issue was found by an in-house static analysis tool.
+
+Fixes: 701a0fd52318 ("hip04_eth: fix missing error handle for build_skb failed")
+Cc: stable@vger.kernel.org
+Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
+Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
+Link: https://patch.msgid.link/20260712142729.2057636-1-fanwu01@zju.edu.cn
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/hisilicon/hip04_eth.c | 11 ++++++++---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+--- a/drivers/net/ethernet/hisilicon/hip04_eth.c
++++ b/drivers/net/ethernet/hisilicon/hip04_eth.c
+@@ -594,7 +594,11 @@ static int hip04_rx_poll(struct napi_str
+ skb = build_skb(buf, priv->rx_buf_size);
+ if (unlikely(!skb)) {
+ net_dbg_ratelimited("build_skb failed\n");
+- goto refill;
++ /* Retain the slot; return budget so NAPI retries this
++ * buffer. Refill would overwrite rx_buf[]/rx_phys[]
++ * and leak them.
++ */
++ return budget;
+ }
+
+ dma_unmap_single(priv->dev, priv->rx_phys[priv->rx_head],
+@@ -622,14 +626,15 @@ static int hip04_rx_poll(struct napi_str
+ rx++;
+ }
+
+-refill:
+ buf = netdev_alloc_frag(priv->rx_buf_size);
+ if (!buf)
+ goto done;
+ phys = dma_map_single(priv->dev, buf,
+ RX_BUF_SIZE, DMA_FROM_DEVICE);
+- if (dma_mapping_error(priv->dev, phys))
++ if (dma_mapping_error(priv->dev, phys)) {
++ skb_free_frag(buf);
+ goto done;
++ }
+ priv->rx_buf[priv->rx_head] = buf;
+ priv->rx_phys[priv->rx_head] = phys;
+ hip04_set_recv_desc(priv, phys);
--- /dev/null
+From be7cc4656eb1f54029610e82d1f0fdd3f9b5ec0a Mon Sep 17 00:00:00 2001
+From: Bryam Vargas <hexlabsecurity@proton.me>
+Date: Tue, 7 Jul 2026 02:00:54 -0500
+Subject: net/iucv: fix use-after-free of a severed iucv_path
+
+From: Bryam Vargas <hexlabsecurity@proton.me>
+
+commit be7cc4656eb1f54029610e82d1f0fdd3f9b5ec0a upstream.
+
+af_iucv queues not-yet-received message notifications on iucv->message_q,
+each holding a raw pointer to the connection's iucv_path. When the peer
+severs the connection, iucv_sever_path() frees that path with
+iucv_path_free() but leaves the notifications queued. A later recvmsg()
+drains message_q via iucv_process_message_q() and hands the stale path to
+message_receive() -- a use-after-free of the freed iucv_path.
+
+Drop the queued notifications when the path is severed; once the path is
+gone they can no longer be received. This also frees the notifications
+leaked when a socket is closed with messages still queued.
+
+Fixes: f0703c80e515 ("[AF_IUCV]: postpone receival of iucv-packets")
+Closes: https://sashiko.dev/#/patchset/20260705-b4-disp-fc79c0dc-v1-1-d2cdcb57afa9@proton.me?part=1
+Cc: stable@vger.kernel.org
+Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
+Link: https://patch.msgid.link/20260707-b4-disp-783fedbb-v1-1-463b9dbda2ea@proton.me
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/iucv/af_iucv.c | 14 ++++++++++++++
+ 1 file changed, 14 insertions(+)
+
+--- a/net/iucv/af_iucv.c
++++ b/net/iucv/af_iucv.c
+@@ -335,6 +335,7 @@ static void iucv_sever_path(struct sock
+ unsigned char user_data[16];
+ struct iucv_sock *iucv = iucv_sk(sk);
+ struct iucv_path *path = iucv->path;
++ struct sock_msg_q *p, *n;
+
+ /* Whoever resets the path pointer, must sever and free it. */
+ if (xchg(&iucv->path, NULL)) {
+@@ -346,6 +347,19 @@ static void iucv_sever_path(struct sock
+ } else
+ pr_iucv->path_sever(path, NULL);
+ iucv_path_free(path);
++
++ /*
++ * Message notifications queued on message_q still reference
++ * the now freed path; drop them, otherwise a later recvmsg()
++ * would pass the freed iucv_path to message_receive() via
++ * iucv_process_message_q().
++ */
++ spin_lock_bh(&iucv->message_q.lock);
++ list_for_each_entry_safe(p, n, &iucv->message_q.list, list) {
++ list_del(&p->list);
++ kfree(p);
++ }
++ spin_unlock_bh(&iucv->message_q.lock);
+ }
+ }
+
--- /dev/null
+From ee7f9bb9320add61f7b367d7e6cd55e3a3a4d65d Mon Sep 17 00:00:00 2001
+From: Sungmin Kang <726ksm@gmail.com>
+Date: Sat, 18 Jul 2026 16:36:30 +0900
+Subject: net: slip: serialize receive against buffer reallocation
+
+From: Sungmin Kang <726ksm@gmail.com>
+
+commit ee7f9bb9320add61f7b367d7e6cd55e3a3a4d65d upstream.
+
+sl_realloc_bufs() replaces rbuff and updates buffsize while holding
+sl->lock. slip_receive_buf() reads those fields and writes through rbuff
+without holding the lock.
+
+An MTU change can therefore race with receive processing. An MTU shrink
+can expose the new smaller rbuff with the old larger bound, causing an
+out-of-bounds write. A receive callback which already loaded the old
+rbuff can instead continue writing after that buffer has been freed.
+
+Serialize receive processing with sl_realloc_bufs() by holding sl->lock
+while consuming each receive batch.
+
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Cc: stable@vger.kernel.org
+Signed-off-by: Sungmin Kang <726ksm@gmail.com>
+Link: https://patch.msgid.link/20260718073631.1674-1-726ksm@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/slip/slip.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/net/slip/slip.c
++++ b/drivers/net/slip/slip.c
+@@ -693,6 +693,8 @@ static void slip_receive_buf(struct tty_
+ if (!sl || sl->magic != SLIP_MAGIC || !netif_running(sl->dev))
+ return;
+
++ spin_lock_bh(&sl->lock);
++
+ /* Read the characters out of the buffer */
+ while (count--) {
+ if (fp && *fp++) {
+@@ -708,6 +710,8 @@ static void slip_receive_buf(struct tty_
+ #endif
+ slip_unesc(sl, *cp++);
+ }
++
++ spin_unlock_bh(&sl->lock);
+ }
+
+ /************************************
--- /dev/null
+From 5499e0602d2faafd42c580d25f615903c3fbe11b Mon Sep 17 00:00:00 2001
+From: David Lee <david.lee@trailofbits.com>
+Date: Mon, 13 Jul 2026 10:47:50 +0000
+Subject: net/x25: fix use-after-free in x25_kill_by_neigh()
+
+From: David Lee <david.lee@trailofbits.com>
+
+commit 5499e0602d2faafd42c580d25f615903c3fbe11b upstream.
+
+x25_kill_by_neigh() walks the global X.25 socket list looking for sockets
+attached to a terminating neighbour. x25_list_lock protects list membership
+while the lookup is in progress, but it does not pin a socket's lifetime
+after the lock is dropped.
+
+The function currently drops x25_list_lock before calling lock_sock(s). A
+concurrent close can run x25_release(), remove the same socket from
+x25_list, and drop the last socket reference in that window. The neighbour
+teardown path can then lock or inspect a freed struct sock/struct x25_sock.
+
+Take sock_hold(s) while x25_list_lock still proves that the list entry is
+live, then drop the temporary reference after the socket has been locked,
+rechecked, and released. Recheck x25_sk(s)->neighbour after lock_sock(),
+because another path may have disconnected the socket before this path
+acquired the socket lock. Restart the list walk after each disconnect
+because the list lock was dropped and the previous iterator state may no
+longer be valid.
+
+A QEMU/KASAN run against origin/master reproduced a slab-use-after-free in
+x25_kill_by_neigh().
+
+Fixes: 7781607938c8 ("net/x25: Fix null-ptr-deref caused by x25_disconnect")
+Cc: stable@vger.kernel.org
+Signed-off-by: David Lee <david.lee@trailofbits.com>
+Assisted-by: Codex:gpt-5.5
+Acked-by: Martin Schiller <ms@dev.tdt.de>
+Link: https://patch.msgid.link/20260713104752.241175-1-david.lee@trailofbits.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/x25/af_x25.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/net/x25/af_x25.c
++++ b/net/x25/af_x25.c
+@@ -1769,15 +1769,19 @@ void x25_kill_by_neigh(struct x25_neigh
+ {
+ struct sock *s;
+
++again:
+ write_lock_bh(&x25_list_lock);
+
+ sk_for_each(s, &x25_list) {
+ if (x25_sk(s)->neighbour == nb) {
++ sock_hold(s);
+ write_unlock_bh(&x25_list_lock);
+ lock_sock(s);
+- x25_disconnect(s, ENETUNREACH, 0, 0);
++ if (x25_sk(s)->neighbour == nb)
++ x25_disconnect(s, ENETUNREACH, 0, 0);
+ release_sock(s);
+- write_lock_bh(&x25_list_lock);
++ sock_put(s);
++ goto again;
+ }
+ }
+ write_unlock_bh(&x25_list_lock);
--- /dev/null
+From 0f71f852a96af9685858ce59fda34ecbf85c283d Mon Sep 17 00:00:00 2001
+From: Breno Leitao <leitao@debian.org>
+Date: Tue, 21 Jul 2026 01:58:45 -0700
+Subject: phonet: pep: fix use-after-free in pep_get_sb()
+
+From: Breno Leitao <leitao@debian.org>
+
+commit 0f71f852a96af9685858ce59fda34ecbf85c283d upstream.
+
+pep_get_sb() doesn't consider that pskb_may_pull() might have relocated
+the skb data, and continue to access the older pointer, causing UAF.
+
+Reproduced under KASAN:
+
+ BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0
+ Read of size 1 at addr ff11000105510f50 by task repro/157
+ pep_get_sb+0x234/0x3b0
+ pipe_handler_do_rcv+0x5f7/0xa10
+ pep_do_rcv+0x203/0x410
+ __sk_receive_skb+0x471/0x4a0
+ phonet_rcv+0x5b3/0x6c0
+ __netif_receive_skb+0xcc/0x1d0
+
+Refetch the header with skb_header_pointer() after pskb_may_pull(), so
+the possibly stale pointer is no longer dereferenced. There are better
+ways to solve this, but, this is the less instrusive one.
+
+Fixes: 9641458d3ec4 ("Phonet: Pipe End Point for Phonet Pipes protocol")
+Cc: stable@vger.kernel.org
+Signed-off-by: Breno Leitao <leitao@debian.org>
+Link: https://patch.msgid.link/20260721-phonet_get_sb_uaf-v1-1-95fd7881cc4e@debian.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/phonet/pep.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/net/phonet/pep.c
++++ b/net/phonet/pep.c
+@@ -55,6 +55,8 @@ static unsigned char *pep_get_sb(struct
+ ph = skb_header_pointer(skb, 0, 2, &h);
+ if (ph == NULL || ph->sb_len < 2 || !pskb_may_pull(skb, ph->sb_len))
+ return NULL;
++ /* pskb_may_pull() may have reallocated the head; refetch ph. */
++ ph = skb_header_pointer(skb, 0, 2, &h);
+ ph->sb_len -= 2;
+ *ptype = ph->sb_type;
+ *plen = ph->sb_len;
--- /dev/null
+From 425224c2d700391729be7fe6929a88ef4e2d7a4e Mon Sep 17 00:00:00 2001
+From: Jann Horn <jannh@google.com>
+Date: Mon, 6 Jul 2026 20:22:42 +0200
+Subject: proc: Fix broken error paths for namespace links
+
+From: Jann Horn <jannh@google.com>
+
+commit 425224c2d700391729be7fe6929a88ef4e2d7a4e upstream.
+
+Don't return the return value of down_read_killable() (0) when a ptrace
+access check fails, return -EACCES as intended.
+
+Reported-by: Magnus Lindholm <linmag7@gmail.com>
+Closes: https://lore.kernel.org/r/20260706170735.2941493-1-linmag7@gmail.com
+Fixes: 6650527444da ("proc: protect ptrace_may_access() with exec_update_lock (part 1)")
+Cc: stable@vger.kernel.org
+Signed-off-by: Jann Horn <jannh@google.com>
+Link: https://patch.msgid.link/20260706-procfs-ns-eacces-fix-v1-1-a69ab14c02e6@google.com
+Tested-by: Magnus Lindholm <linmag7@gmail.com>
+Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/proc/namespaces.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/fs/proc/namespaces.c
++++ b/fs/proc/namespaces.c
+@@ -46,7 +46,7 @@ static const char *proc_ns_get_link(stru
+ const struct proc_ns_operations *ns_ops = PROC_I(inode)->ns_ops;
+ struct task_struct *task;
+ struct path ns_path;
+- int error = -EACCES;
++ int error;
+
+ if (!dentry)
+ return ERR_PTR(-ECHILD);
+@@ -59,6 +59,7 @@ static const char *proc_ns_get_link(stru
+ if (error)
+ goto out_put_task;
+
++ error = -EACCES;
+ if (!ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS))
+ goto out;
+
+@@ -90,6 +91,7 @@ static int proc_ns_readlink(struct dentr
+ if (res)
+ goto out_put_task;
+
++ res = -EACCES;
+ if (ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS)) {
+ res = ns_get_name(name, sizeof(name), task, ns_ops);
+ if (res >= 0)
--- /dev/null
+From a6c4250b81bd30beae94e1b7a4b26fa1193ad2e4 Mon Sep 17 00:00:00 2001
+From: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+Date: Thu, 9 Jul 2026 13:26:20 +0200
+Subject: rbd: Reset positive result codes to zero in object map update path
+
+From: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+
+commit a6c4250b81bd30beae94e1b7a4b26fa1193ad2e4 upstream.
+
+In a reply message to an RBD request, a positive result code indicates
+a data payload, which is not allowed for writes. While
+rbd_osd_req_callback() already resets a positive result code for writes
+to zero, rbd_object_map_callback() does not. This allows a corrupted
+reply to an object map update to trigger the rbd_assert(*result < 0) in
+__rbd_obj_handle_request(). This happens, because
+rbd_object_map_callback() calls rbd_obj_handle_request() ->
+__rbd_obj_handle_request() and passes this positive result code. From
+__rbd_obj_handle_request(), rbd_obj_advance_write() is called, which
+leaves the positive result code unchanged and returns true. Therefore,
+the if(done && *result) branch is executed in __rbd_obj_handle_request()
+and the assertion triggers.
+
+This patch fixes the issue by adjusting the logic in the
+rbd_object_map_callback() path. A positive result code for an object map
+update is now reset to zero (similar to rbd_osd_req_callback()), and the
+message is subsequently handled the same way as if the result code was
+zero from the beginning. Additionally, a WARN_ON_ONCE() is added for
+this case.
+
+Cc: stable@vger.kernel.org
+Fixes: 22e8bd51bb04 ("rbd: support for object-map and fast-diff")
+Signed-off-by: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/block/rbd.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/drivers/block/rbd.c
++++ b/drivers/block/rbd.c
+@@ -1958,10 +1958,15 @@ static int rbd_object_map_update_finish(
+ bool has_current_state;
+ void *p;
+
+- if (osd_req->r_result)
++ if (osd_req->r_result < 0)
+ return osd_req->r_result;
+
+ /*
++ * Writes aren't allowed to return a data payload.
++ */
++ WARN_ON_ONCE(osd_req->r_result > 0);
++
++ /*
+ * Nothing to do for a snapshot object map.
+ */
+ if (osd_req->r_num_ops == 1)
--- /dev/null
+From 9b2854f86f0b56e9027d68e7a3fc909d1a9b566f Mon Sep 17 00:00:00 2001
+From: Jun Yang <junvyyang@tencent.com>
+Date: Tue, 21 Jul 2026 21:14:05 +0800
+Subject: sctp: don't free the ASCONF's own transport in DEL-IP processing
+
+From: Jun Yang <junvyyang@tencent.com>
+
+commit 9b2854f86f0b56e9027d68e7a3fc909d1a9b566f upstream.
+
+sctp_process_asconf() caches the transport the ASCONF chunk is processed
+against in asconf->transport (== chunk->transport, set once in sctp_rcv()).
+For an ASCONF located through its Address Parameter by
+__sctp_rcv_asconf_lookup(), that cached transport corresponds to the
+Address Parameter, which need not be the packet's source address.
+
+sctp_process_asconf_param() rejects a DEL-IP for the packet source address
+(ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport.
+A single ASCONF can therefore carry, in order:
+
+ [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0]
+
+where L differs from the source. The DEL-IP for L passes the D8 check and
+calls sctp_assoc_rm_peer() on the transport that asconf->transport still
+points at, freeing it (RCU-deferred). The following wildcard DEL-IP then
+reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and
+sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed
+transport (->ipaddr, ->state) and plants the dangling pointer into
+asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping
+only the pointer that is no longer on the list, removes every real
+transport, leaving the association with a transport_count of 0 and
+primary_path/active_path pointing at freed memory.
+
+Reject a DEL-IP that targets the transport the ASCONF is being processed
+against, mirroring the existing source-address guard, so the wildcard
+branch can never reuse a freed transport.
+
+Fixes: 42e30bf3463c ("[SCTP]: Handle the wildcard ADD-IP Address parameter")
+Cc: stable@kernel.org
+Signed-off-by: Jun Yang <junvyyang@tencent.com>
+Acked-by: Xin Long <lucien.xin@gmail.com>
+Link: https://patch.msgid.link/tencent_73762ED1DF08CC9D5F5F61954B01350CFE0A@qq.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/sctp/sm_make_chunk.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/net/sctp/sm_make_chunk.c
++++ b/net/sctp/sm_make_chunk.c
+@@ -3179,6 +3179,12 @@ static __be16 sctp_process_asconf_param(
+ if (!peer)
+ return SCTP_ERROR_DNS_FAILED;
+
++ /* Don't free asconf->transport; a later wildcard DEL-IP
++ * parameter reuses it.
++ */
++ if (peer == asconf->transport)
++ return SCTP_ERROR_REQ_REFUSED;
++
+ sctp_assoc_rm_peer(asoc, peer);
+ break;
+ case SCTP_PARAM_SET_PRIMARY:
--- /dev/null
+From 1a087033a6bad73b4140020b40e819b0933aafc3 Mon Sep 17 00:00:00 2001
+From: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
+Date: Fri, 17 Jul 2026 11:51:59 +0900
+Subject: selftests/ftrace: Reset triggers at top level before instance loop
+
+From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+
+commit 1a087033a6bad73b4140020b40e819b0933aafc3 upstream.
+
+When running instance tests, 'ftracetest' creates a new ftrace instance
+and runs the tests inside it. Before starting each test, it executes
+'initialize_system()' to reset the ftrace state to initial-state.
+
+However, since 'initialize_system()' is executed in the context of the
+instance directory, it only cleans up triggers and filters of that
+instance.
+Any triggers or dynamic events left behind in the top-level instance by
+previous failed top-level tests, are left completely untouched. These
+top-level leftovers can cause subsequent instance-based tests to fail
+or even crash the kernel.
+
+Fix this by executing 'initialize_system()' in the top-level tracing
+directory once before entering the instance loop.
+
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/178425671889.84440.9477850701738666404.stgit@devnote2
+Fixes: b5b77be812de ("selftests: ftrace: Allow some tests to be run in a tracing instance")
+Assisted-by: Antigravity:gemini-3.5-flash
+Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/testing/selftests/ftrace/ftracetest | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/tools/testing/selftests/ftrace/ftracetest
++++ b/tools/testing/selftests/ftrace/ftracetest
+@@ -423,6 +423,7 @@ for t in $TEST_CASES; do
+ done
+
+ # Test on instance loop
++(cd $TRACING_DIR; initialize_system)
+ INSTANCE=" (instance) "
+ for t in $TEST_CASES; do
+ test_on_instance $t || continue
arm64-syscall-ensure-saved-x0-is-kept-in-sync-with-tracer-updates.patch
revert-arm64-syscall-ensure-saved-x0-is-kept-in-sync-with-tracer-updates.patch
mptcp-only-set-data_fin-when-a-mapping-is-present.patch
+sctp-don-t-free-the-asconf-s-own-transport-in-del-ip-processing.patch
+ceph-fix-pre-auth-out-of-bounds-read-on-snaptrace-in-ceph_handle_caps.patch
+libceph-bound-get_version-reply-decode-to-front-len.patch
+libceph-fix-multiplication-overflow-in-decode_new_up_state_weight.patch
+libceph-guard-missing-crush-type-name-lookup.patch
+libceph-refresh-auth-authorizer_buf-_len-after-authorizer-update.patch
+libceph-reject-monmaps-advertising-zero-monitors.patch
+libceph-reject-zero-bucket-types-in-crush_decode.patch
+libceph-remove-debugfs-files-before-client-teardown.patch
+binfmt_elf_fdpic-only-honour-the-first-pt_interp.patch
+iommu-vt-d-disallow-sva-if-page-walk-is-not-coherent.patch
+phonet-pep-fix-use-after-free-in-pep_get_sb.patch
+vxlan-require-cap_net_admin-in-the-device-netns-for-changelink.patch
+net-slip-serialize-receive-against-buffer-reallocation.patch
+geneve-require-cap_net_admin-in-the-device-netns-for-changelink.patch
+net-af_iucv-fix-null-deref-in-afiucv_hs_callback_syn.patch
+net-iucv-fix-use-after-free-of-a-severed-iucv_path.patch
+net-x25-fix-use-after-free-in-x25_kill_by_neigh.patch
+net-hip04-fix-rx-buffer-leak-on-build_skb-failure.patch
+proc-fix-broken-error-paths-for-namespace-links.patch
+selftests-ftrace-reset-triggers-at-top-level-before-instance-loop.patch
+rbd-reset-positive-result-codes-to-zero-in-object-map-update-path.patch
--- /dev/null
+From 3a61bd9637f3d929aa846e4eb3d98b48c26fcb0e Mon Sep 17 00:00:00 2001
+From: Doruk Tan Ozturk <doruk@0sec.ai>
+Date: Thu, 16 Jul 2026 22:34:59 +0200
+Subject: vxlan: require CAP_NET_ADMIN in the device netns for changelink
+
+From: Doruk Tan Ozturk <doruk@0sec.ai>
+
+commit 3a61bd9637f3d929aa846e4eb3d98b48c26fcb0e upstream.
+
+A tunnel changelink() operates on at most two netns, dev_net(dev) and
+the sticky underlay netns vxlan->net. They differ once the device is
+created in or moved to a netns other than the one the request runs in.
+The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev),
+so a caller privileged there but not in vxlan->net can rewrite a vxlan
+device whose underlay lives in vxlan->net.
+
+vxlan_changelink() validates and applies the new configuration against
+vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the
+underlay socket in that netns, so the same reasoning as the tunnel
+changelink series applies here.
+
+Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of
+the op before any attribute is parsed, matching ipgre_changelink() and
+the rest of the "require CAP_NET_ADMIN in the device netns for
+changelink" series.
+
+Found by 0sec automated security-research tooling (https://0sec.ai).
+
+Fixes: 8bcdc4f3a20b ("vxlan: add changelink support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
+Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
+Link: https://patch.msgid.link/20260716203500.70573-2-doruk@0sec.ai
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/vxlan/vxlan_core.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/net/vxlan/vxlan_core.c
++++ b/drivers/net/vxlan/vxlan_core.c
+@@ -4259,6 +4259,9 @@ static int vxlan_changelink(struct net_d
+ struct vxlan_rdst *dst;
+ int err;
+
++ if (!rtnl_dev_link_net_capable(dev, vxlan->net))
++ return -EPERM;
++
+ dst = &vxlan->default_dst;
+ err = vxlan_nl2conf(tb, data, dev, &conf, true, extack);
+ if (err)
projects / thirdparty / kernel / stable-queue.git / commitdiff
