--- /dev/null
+From ce0123cbb4a40a2f1bbb815f292b26e96088639f Mon Sep 17 00:00:00 2001
+From: Max Kellermann <max.kellermann@ionos.com>
+Date: Fri, 5 Sep 2025 23:15:30 +0200
+Subject: ceph: fix i_nlink underrun during async unlink
+
+From: Max Kellermann <max.kellermann@ionos.com>
+
+commit ce0123cbb4a40a2f1bbb815f292b26e96088639f upstream.
+
+During async unlink, we drop the `i_nlink` counter before we receive
+the completion (that will eventually update the `i_nlink`) because "we
+assume that the unlink will succeed". That is not a bad idea, but it
+races against deletions by other clients (or against the completion of
+our own unlink) and can lead to an underrun which emits a WARNING like
+this one:
+
+ WARNING: CPU: 85 PID: 25093 at fs/inode.c:407 drop_nlink+0x50/0x68
+ Modules linked in:
+ CPU: 85 UID: 3221252029 PID: 25093 Comm: php-cgi8.1 Not tainted 6.14.11-cm4all1-ampere #655
+ Hardware name: Supermicro ARS-110M-NR/R12SPD-A, BIOS 1.1b 10/17/2023
+ pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
+ pc : drop_nlink+0x50/0x68
+ lr : ceph_unlink+0x6c4/0x720
+ sp : ffff80012173bc90
+ x29: ffff80012173bc90 x28: ffff086d0a45aaf8 x27: ffff0871d0eb5680
+ x26: ffff087f2a64a718 x25: 0000020000000180 x24: 0000000061c88647
+ x23: 0000000000000002 x22: ffff07ff9236d800 x21: 0000000000001203
+ x20: ffff07ff9237b000 x19: ffff088b8296afc0 x18: 00000000f3c93365
+ x17: 0000000000070000 x16: ffff08faffcbdfe8 x15: ffff08faffcbdfec
+ x14: 0000000000000000 x13: 45445f65645f3037 x12: 34385f6369706f74
+ x11: 0000a2653104bb20 x10: ffffd85f26d73290 x9 : ffffd85f25664f94
+ x8 : 00000000000000c0 x7 : 0000000000000000 x6 : 0000000000000002
+ x5 : 0000000000000081 x4 : 0000000000000481 x3 : 0000000000000000
+ x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff08727d3f91e8
+ Call trace:
+ drop_nlink+0x50/0x68 (P)
+ vfs_unlink+0xb0/0x2e8
+ do_unlinkat+0x204/0x288
+ __arm64_sys_unlinkat+0x3c/0x80
+ invoke_syscall.constprop.0+0x54/0xe8
+ do_el0_svc+0xa4/0xc8
+ el0_svc+0x18/0x58
+ el0t_64_sync_handler+0x104/0x130
+ el0t_64_sync+0x154/0x158
+
+In ceph_unlink(), a call to ceph_mdsc_submit_request() submits the
+CEPH_MDS_OP_UNLINK to the MDS, but does not wait for completion.
+
+Meanwhile, between this call and the following drop_nlink() call, a
+worker thread may process a CEPH_CAP_OP_IMPORT, CEPH_CAP_OP_GRANT or
+just a CEPH_MSG_CLIENT_REPLY (the latter of which could be our own
+completion). These will lead to a set_nlink() call, updating the
+`i_nlink` counter to the value received from the MDS. If that new
+`i_nlink` value happens to be zero, it is illegal to decrement it
+further. But that is exactly what ceph_unlink() will do then.
+
+The WARNING can be reproduced this way:
+
+1. Force async unlink; only the async code path is affected. Having
+ no real clue about Ceph internals, I was unable to find out why the
+ MDS wouldn't give me the "Fxr" capabilities, so I patched
+ get_caps_for_async_unlink() to always succeed.
+
+ (Note that the WARNING dump above was found on an unpatched kernel,
+ without this kludge - this is not a theoretical bug.)
+
+2. Add a sleep call after ceph_mdsc_submit_request() so the unlink
+ completion gets handled by a worker thread before drop_nlink() is
+ called. This guarantees that the `i_nlink` is already zero before
+ drop_nlink() runs.
+
+The solution is to skip the counter decrement when it is already zero,
+but doing so without a lock is still racy (TOCTOU). Since
+ceph_fill_inode() and handle_cap_grant() both hold the
+`ceph_inode_info.i_ceph_lock` spinlock while set_nlink() runs, this
+seems like the proper lock to protect the `i_nlink` updates.
+
+I found prior art in NFS and SMB (using `inode.i_lock`) and AFS (using
+`afs_vnode.cb_lock`). All three have the zero check as well.
+
+Cc: stable@vger.kernel.org
+Fixes: 2ccb45462aea ("ceph: perform asynchronous unlink if we have sufficient caps")
+Signed-off-by: Max Kellermann <max.kellermann@ionos.com>
+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/dir.c | 15 ++++++++++++++-
+ 1 file changed, 14 insertions(+), 1 deletion(-)
+
+--- a/fs/ceph/dir.c
++++ b/fs/ceph/dir.c
+@@ -1129,6 +1129,7 @@ static int ceph_unlink(struct inode *dir
+ struct ceph_fs_client *fsc = ceph_sb_to_client(dir->i_sb);
+ struct ceph_mds_client *mdsc = fsc->mdsc;
+ struct inode *inode = d_inode(dentry);
++ struct ceph_inode_info *ci = ceph_inode(inode);
+ struct ceph_mds_request *req;
+ bool try_async = ceph_test_mount_opt(fsc, ASYNC_DIROPS);
+ int err = -EROFS;
+@@ -1173,7 +1174,19 @@ retry:
+ * We have enough caps, so we assume that the unlink
+ * will succeed. Fix up the target inode and dcache.
+ */
+- drop_nlink(inode);
++
++ /*
++ * Protect the i_nlink update with i_ceph_lock
++ * to precent racing against ceph_fill_inode()
++ * handling our completion on a worker thread
++ * and don't decrement if i_nlink has already
++ * been updated to zero by this completion.
++ */
++ spin_lock(&ci->i_ceph_lock);
++ if (inode->i_nlink > 0)
++ drop_nlink(inode);
++ spin_unlock(&ci->i_ceph_lock);
++
+ d_delete(dentry);
+ } else if (err == -EJUKEBOX) {
+ try_async = false;
--- /dev/null
+From e113f0b46d19626ec15388bcb91432c9a4fd6261 Mon Sep 17 00:00:00 2001
+From: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
+Date: Fri, 13 Mar 2026 23:14:14 +0900
+Subject: kprobes: avoid crash when rmmod/insmod after ftrace killed
+
+From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+
+commit e113f0b46d19626ec15388bcb91432c9a4fd6261 upstream.
+
+After we hit ftrace is killed by some errors, the kernel crash if
+we remove modules in which kprobe probes.
+
+BUG: unable to handle page fault for address: fffffbfff805000d
+PGD 817fcc067 P4D 817fcc067 PUD 817fc8067 PMD 101555067 PTE 0
+Oops: Oops: 0000 [#1] SMP KASAN PTI
+CPU: 4 UID: 0 PID: 2012 Comm: rmmod Tainted: G W OE
+Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
+RIP: 0010:kprobes_module_callback+0x89/0x790
+RSP: 0018:ffff88812e157d30 EFLAGS: 00010a02
+RAX: 1ffffffff805000d RBX: dffffc0000000000 RCX: ffffffff86a8de90
+RDX: ffffed1025c2af9b RSI: 0000000000000008 RDI: ffffffffc0280068
+RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed1025c2af9a
+R10: ffff88812e157cd7 R11: 205d323130325420 R12: 0000000000000002
+R13: ffffffffc0290488 R14: 0000000000000002 R15: ffffffffc0280040
+FS: 00007fbc450dd740(0000) GS:ffff888420331000(0000) knlGS:0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: fffffbfff805000d CR3: 000000010f624000 CR4: 00000000000006f0
+Call Trace:
+ <TASK>
+ notifier_call_chain+0xc6/0x280
+ blocking_notifier_call_chain+0x60/0x90
+ __do_sys_delete_module.constprop.0+0x32a/0x4e0
+ do_syscall_64+0x5d/0xfa0
+ entry_SYSCALL_64_after_hwframe+0x76/0x7e
+
+This is because the kprobe on ftrace does not correctly handles
+the kprobe_ftrace_disabled flag set by ftrace_kill().
+
+To prevent this error, check kprobe_ftrace_disabled in
+__disarm_kprobe_ftrace() and skip all ftrace related operations.
+
+Link: https://lore.kernel.org/all/176473947565.1727781.13110060700668331950.stgit@mhiramat.tok.corp.google.com/
+
+Reported-by: Ye Bin <yebin10@huawei.com>
+Closes: https://lore.kernel.org/all/20251125020536.2484381-1-yebin@huaweicloud.com/
+Fixes: ae6aa16fdc16 ("kprobes: introduce ftrace based optimization")
+Cc: stable@vger.kernel.org
+Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/kprobes.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/kernel/kprobes.c
++++ b/kernel/kprobes.c
+@@ -1578,6 +1578,10 @@ static struct kprobe *__get_valid_kprobe
+ struct kprobe *ap, *list_p;
+
+ lockdep_assert_held(&kprobe_mutex);
++ if (unlikely(kprobe_ftrace_disabled)) {
++ /* Now ftrace is disabled forever, disarm is already done. */
++ return 0;
++ }
+
+ ap = get_kprobe(p->addr);
+ if (unlikely(!ap))
--- /dev/null
+From b282c43ed156ae15ea76748fc15cd5c39dc9ab72 Mon Sep 17 00:00:00 2001
+From: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+Date: Tue, 10 Mar 2026 15:28:15 +0100
+Subject: libceph: Fix potential out-of-bounds access in ceph_handle_auth_reply()
+
+From: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+
+commit b282c43ed156ae15ea76748fc15cd5c39dc9ab72 upstream.
+
+This patch fixes an out-of-bounds access in ceph_handle_auth_reply()
+that can be triggered by a message of type CEPH_MSG_AUTH_REPLY. In
+ceph_handle_auth_reply(), the value of the payload_len field of such a
+message is stored in a variable of type int. A value greater than
+INT_MAX leads to an integer overflow and is interpreted as a negative
+value. This leads to decrementing the pointer address by this value and
+subsequently accessing it because ceph_decode_need() only checks that
+the memory access does not exceed the end address of the allocation.
+
+This patch fixes the issue by changing the data type of payload_len to
+u32. Additionally, the data type of result_msg_len is changed to u32,
+as it is also a variable holding a non-negative length.
+
+Also, an additional layer of sanity checks is introduced, ensuring that
+directly after reading it from the message, payload_len and
+result_msg_len are not greater than the overall segment length.
+
+BUG: KASAN: slab-out-of-bounds in ceph_handle_auth_reply+0x642/0x7a0 [libceph]
+Read of size 4 at addr ffff88811404df14 by task kworker/20:1/262
+
+CPU: 20 UID: 0 PID: 262 Comm: kworker/20:1 Not tainted 6.19.2 #5 PREEMPT(voluntary)
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
+Workqueue: ceph-msgr ceph_con_workfn [libceph]
+Call Trace:
+ <TASK>
+ dump_stack_lvl+0x76/0xa0
+ print_report+0xd1/0x620
+ ? __pfx__raw_spin_lock_irqsave+0x10/0x10
+ ? kasan_complete_mode_report_info+0x72/0x210
+ kasan_report+0xe7/0x130
+ ? ceph_handle_auth_reply+0x642/0x7a0 [libceph]
+ ? ceph_handle_auth_reply+0x642/0x7a0 [libceph]
+ __asan_report_load_n_noabort+0xf/0x20
+ ceph_handle_auth_reply+0x642/0x7a0 [libceph]
+ mon_dispatch+0x973/0x23d0 [libceph]
+ ? apparmor_socket_recvmsg+0x6b/0xa0
+ ? __pfx_mon_dispatch+0x10/0x10 [libceph]
+ ? __kasan_check_write+0x14/0x30i
+ ? mutex_unlock+0x7f/0xd0
+ ? __pfx_mutex_unlock+0x10/0x10
+ ? __pfx_do_recvmsg+0x10/0x10 [libceph]
+ ceph_con_process_message+0x1f1/0x650 [libceph]
+ process_message+0x1e/0x450 [libceph]
+ ceph_con_v2_try_read+0x2e48/0x6c80 [libceph]
+ ? __pfx_ceph_con_v2_try_read+0x10/0x10 [libceph]
+ ? save_fpregs_to_fpstate+0xb0/0x230
+ ? raw_spin_rq_unlock+0x17/0xa0
+ ? finish_task_switch.isra.0+0x13b/0x760
+ ? __switch_to+0x385/0xda0
+ ? __kasan_check_write+0x14/0x30
+ ? mutex_lock+0x8d/0xe0
+ ? __pfx_mutex_lock+0x10/0x10
+ ceph_con_workfn+0x248/0x10c0 [libceph]
+ process_one_work+0x629/0xf80
+ ? __kasan_check_write+0x14/0x30
+ worker_thread+0x87f/0x1570
+ ? __pfx__raw_spin_lock_irqsave+0x10/0x10
+ ? __pfx_try_to_wake_up+0x10/0x10
+ ? kasan_print_address_stack_frame+0x1f7/0x280
+ ? __pfx_worker_thread+0x10/0x10
+ kthread+0x396/0x830
+ ? __pfx__raw_spin_lock_irq+0x10/0x10
+ ? __pfx_kthread+0x10/0x10
+ ? __kasan_check_write+0x14/0x30
+ ? recalc_sigpending+0x180/0x210
+ ? __pfx_kthread+0x10/0x10
+ ret_from_fork+0x3f7/0x610
+ ? __pfx_ret_from_fork+0x10/0x10
+ ? __switch_to+0x385/0xda0
+ ? __pfx_kthread+0x10/0x10
+ ret_from_fork_asm+0x1a/0x30
+ </TASK>
+
+[ idryomov: replace if statements with ceph_decode_need() for
+ payload_len and result_msg_len ]
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
+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/auth.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/net/ceph/auth.c
++++ b/net/ceph/auth.c
+@@ -185,9 +185,9 @@ int ceph_handle_auth_reply(struct ceph_a
+ s32 result;
+ u64 global_id;
+ void *payload, *payload_end;
+- int payload_len;
++ u32 payload_len;
+ char *result_msg;
+- int result_msg_len;
++ u32 result_msg_len;
+ int ret = -EINVAL;
+
+ mutex_lock(&ac->mutex);
+@@ -197,10 +197,12 @@ int ceph_handle_auth_reply(struct ceph_a
+ result = ceph_decode_32(&p);
+ global_id = ceph_decode_64(&p);
+ payload_len = ceph_decode_32(&p);
++ ceph_decode_need(&p, end, payload_len, bad);
+ payload = p;
+ p += payload_len;
+ ceph_decode_need(&p, end, sizeof(u32), bad);
+ result_msg_len = ceph_decode_32(&p);
++ ceph_decode_need(&p, end, result_msg_len, bad);
+ result_msg = p;
+ p += result_msg_len;
+ if (p != end)
--- /dev/null
+From 079c24d5690262e83ee476e2a548e416f3237511 Mon Sep 17 00:00:00 2001
+From: Kalesh Singh <kaleshsingh@google.com>
+Date: Thu, 19 Feb 2026 15:36:56 -0800
+Subject: mm/tracing: rss_stat: ensure curr is false from kthread context
+
+From: Kalesh Singh <kaleshsingh@google.com>
+
+commit 079c24d5690262e83ee476e2a548e416f3237511 upstream.
+
+The rss_stat trace event allows userspace tools, like Perfetto [1], to
+inspect per-process RSS metric changes over time.
+
+The curr field was introduced to rss_stat in commit e4dcad204d3a
+("rss_stat: add support to detect RSS updates of external mm"). Its
+intent is to indicate whether the RSS update is for the mm_struct of the
+current execution context; and is set to false when operating on a remote
+mm_struct (e.g., via kswapd or a direct reclaimer).
+
+However, an issue arises when a kernel thread temporarily adopts a user
+process's mm_struct. Kernel threads do not have their own mm_struct and
+normally have current->mm set to NULL. To operate on user memory, they
+can "borrow" a memory context using kthread_use_mm(), which sets
+current->mm to the user process's mm.
+
+This can be observed, for example, in the USB Function Filesystem (FFS)
+driver. The ffs_user_copy_worker() handles AIO completions and uses
+kthread_use_mm() to copy data to a user-space buffer. If a page fault
+occurs during this copy, the fault handler executes in the kthread's
+context.
+
+At this point, current is the kthread, but current->mm points to the user
+process's mm. Since the rss_stat event (from the page fault) is for that
+same mm, the condition current->mm == mm becomes true, causing curr to be
+incorrectly set to true when the trace event is emitted.
+
+This is misleading because it suggests the mm belongs to the kthread,
+confusing userspace tools that track per-process RSS changes and
+corrupting their mm_id-to-process association.
+
+Fix this by ensuring curr is always false when the trace event is emitted
+from a kthread context by checking for the PF_KTHREAD flag.
+
+Link: https://lkml.kernel.org/r/20260219233708.1971199-1-kaleshsingh@google.com
+Link: https://perfetto.dev/ [1]
+Fixes: e4dcad204d3a ("rss_stat: add support to detect RSS updates of external mm")
+Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
+Acked-by: Zi Yan <ziy@nvidia.com>
+Acked-by: SeongJae Park <sj@kernel.org>
+Reviewed-by: Pedro Falcato <pfalcato@suse.de>
+Cc: "David Hildenbrand (Arm)" <david@kernel.org>
+Cc: Joel Fernandes <joel@joelfernandes.org>
+Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
+Cc: Minchan Kim <minchan@kernel.org>
+Cc: Steven Rostedt <rostedt@goodmis.org>
+Cc: Suren Baghdasaryan <surenb@google.com>
+Cc: <stable@vger.kernel.org> [5.10+]
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/trace/events/kmem.h | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/include/trace/events/kmem.h
++++ b/include/trace/events/kmem.h
+@@ -352,7 +352,13 @@ TRACE_EVENT(rss_stat,
+
+ TP_fast_assign(
+ __entry->mm_id = mm_ptr_to_hash(mm);
+- __entry->curr = !!(current->mm == mm);
++ /*
++ * curr is true if the mm matches the current task's mm_struct.
++ * Since kthreads (PF_KTHREAD) have no mm_struct of their own
++ * but can borrow one via kthread_use_mm(), we must filter them
++ * out to avoid incorrectly attributing the RSS update to them.
++ */
++ __entry->curr = current->mm == mm && !(current->flags & PF_KTHREAD);
+ __entry->member = member;
+ __entry->size = (count << PAGE_SHIFT);
+ ),
--- /dev/null
+From af12e64ae0661546e8b4f5d30d55c5f53a11efe7 Mon Sep 17 00:00:00 2001
+From: Felix Gu <ustc.gu@gmail.com>
+Date: Tue, 20 Jan 2026 22:26:46 +0800
+Subject: mmc: mmci: Fix device_node reference leak in of_get_dml_pipe_index()
+
+From: Felix Gu <ustc.gu@gmail.com>
+
+commit af12e64ae0661546e8b4f5d30d55c5f53a11efe7 upstream.
+
+When calling of_parse_phandle_with_args(), the caller is responsible
+to call of_node_put() to release the reference of device node.
+In of_get_dml_pipe_index(), it does not release the reference.
+
+Fixes: 9cb15142d0e3 ("mmc: mmci: Add qcom dml support to the driver.")
+Signed-off-by: Felix Gu <gu_0233@qq.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mmc/host/mmci_qcom_dml.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/mmc/host/mmci_qcom_dml.c
++++ b/drivers/mmc/host/mmci_qcom_dml.c
+@@ -109,6 +109,7 @@ static int of_get_dml_pipe_index(struct
+ &dma_spec))
+ return -ENODEV;
+
++ of_node_put(dma_spec.np);
+ if (dma_spec.args_count)
+ return dma_spec.args[0];
+
usb-renesas_usbhs-fix-use-after-free-in-isr-during-device-removal.patch
usb-mdc800-handle-signal-and-read-racing.patch
usb-image-mdc800-kill-download-urb-on-timeout.patch
+mm-tracing-rss_stat-ensure-curr-is-false-from-kthread-context.patch
+mmc-mmci-fix-device_node-reference-leak-in-of_get_dml_pipe_index.patch
+tipc-fix-divide-by-zero-in-tipc_sk_filter_connect.patch
+libceph-fix-potential-out-of-bounds-access-in-ceph_handle_auth_reply.patch
+ceph-fix-i_nlink-underrun-during-async-unlink.patch
--- /dev/null
+From 6c5a9baa15de240e747263aba435a0951da8d8d2 Mon Sep 17 00:00:00 2001
+From: Mehul Rao <mehulrao@gmail.com>
+Date: Tue, 10 Mar 2026 13:07:30 -0400
+Subject: tipc: fix divide-by-zero in tipc_sk_filter_connect()
+
+From: Mehul Rao <mehulrao@gmail.com>
+
+commit 6c5a9baa15de240e747263aba435a0951da8d8d2 upstream.
+
+A user can set conn_timeout to any value via
+setsockopt(TIPC_CONN_TIMEOUT), including values less than 4. When a
+SYN is rejected with TIPC_ERR_OVERLOAD and the retry path in
+tipc_sk_filter_connect() executes:
+
+ delay %= (tsk->conn_timeout / 4);
+
+If conn_timeout is in the range [0, 3], the integer division yields 0,
+and the modulo operation triggers a divide-by-zero exception, causing a
+kernel oops/panic.
+
+Fix this by clamping conn_timeout to a minimum of 4 at the point of use
+in tipc_sk_filter_connect().
+
+Oops: divide error: 0000 [#1] SMP KASAN NOPTI
+CPU: 0 UID: 0 PID: 119 Comm: poc-F144 Not tainted 7.0.0-rc2+
+RIP: 0010:tipc_sk_filter_rcv (net/tipc/socket.c:2236 net/tipc/socket.c:2362)
+Call Trace:
+ tipc_sk_backlog_rcv (include/linux/instrumented.h:82 include/linux/atomic/atomic-instrumented.h:32 include/net/sock.h:2357 net/tipc/socket.c:2406)
+ __release_sock (include/net/sock.h:1185 net/core/sock.c:3213)
+ release_sock (net/core/sock.c:3797)
+ tipc_connect (net/tipc/socket.c:2570)
+ __sys_connect (include/linux/file.h:62 include/linux/file.h:83 net/socket.c:2098)
+
+Fixes: 6787927475e5 ("tipc: buffer overflow handling in listener socket")
+Cc: stable@vger.kernel.org
+Signed-off-by: Mehul Rao <mehulrao@gmail.com>
+Reviewed-by: Tung Nguyen <tung.quang.nguyen@est.tech>
+Link: https://patch.msgid.link/20260310170730.28841-1-mehulrao@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/tipc/socket.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/net/tipc/socket.c
++++ b/net/tipc/socket.c
+@@ -2233,6 +2233,8 @@ static bool tipc_sk_filter_connect(struc
+ if (skb_queue_empty(&sk->sk_write_queue))
+ break;
+ get_random_bytes(&delay, 2);
++ if (tsk->conn_timeout < 4)
++ tsk->conn_timeout = 4;
+ delay %= (tsk->conn_timeout / 4);
+ delay = msecs_to_jiffies(delay + 100);
+ sk_reset_timer(sk, &sk->sk_timer, jiffies + delay);
projects / thirdparty / kernel / stable-queue.git / commitdiff
