January 2025 - Linux-stable-mirror

FAILED: patch "[PATCH] mptcp: be sure to send ack when mptcp-level window re-opens" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 2ca06a2f65310aeef30bb69b7405437a14766e4d # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025012037-siesta-sulfite-8b05@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 2ca06a2f65310aeef30bb69b7405437a14766e4d Mon Sep 17 00:00:00 2001 From: Paolo Abeni <pabeni(a)redhat.com> Date: Mon, 13 Jan 2025 16:44:56 +0100 Subject: [PATCH] mptcp: be sure to send ack when mptcp-level window re-opens mptcp_cleanup_rbuf() is responsible to send acks when the user-space reads enough data to update the receive windows significantly. It tries hard to avoid acquiring the subflow sockets locks by checking conditions similar to the ones implemented at the TCP level. To avoid too much code duplication - the MPTCP protocol can't reuse the TCP helpers as part of the relevant status is maintained into the msk socket - and multiple costly window size computation, mptcp_cleanup_rbuf uses a rough estimate for the most recently advertised window size: the MPTCP receive free space, as recorded as at last-ack time. Unfortunately the above does not allow mptcp_cleanup_rbuf() to detect a zero to non-zero win change in some corner cases, skipping the tcp_cleanup_rbuf call and leaving the peer stuck. After commit ea66758c1795 ("tcp: allow MPTCP to update the announced window"), MPTCP has actually cheap access to the announced window value. Use it in mptcp_cleanup_rbuf() for a more accurate ack generation. Fixes: e3859603ba13 ("mptcp: better msk receive window updates") Cc: stable(a)vger.kernel.org Reported-by: Jakub Kicinski <kuba(a)kernel.org> Closes: https://lore.kernel.org/20250107131845.5e5de3c5@kernel.org Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Link: https://patch.msgid.link/20250113-net-mptcp-connect-st-flakes-v1-1-0d986ee7… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/net/mptcp/options.c b/net/mptcp/options.c index a62bc874bf1e..123f3f297284 100644 --- a/net/mptcp/options.c +++ b/net/mptcp/options.c @@ -607,7 +607,6 @@ static bool mptcp_established_options_dss(struct sock *sk, struct sk_buff *skb, } opts->ext_copy.use_ack = 1; opts->suboptions = OPTION_MPTCP_DSS; - WRITE_ONCE(msk->old_wspace, __mptcp_space((struct sock *)msk)); /* Add kind/length/subtype/flag overhead if mapping is not populated */ if (dss_size == 0) @@ -1288,7 +1287,7 @@ static void mptcp_set_rwin(struct tcp_sock *tp, struct tcphdr *th) } MPTCP_INC_STATS(sock_net(ssk), MPTCP_MIB_RCVWNDCONFLICT); } - return; + goto update_wspace; } if (rcv_wnd_new != rcv_wnd_old) { @@ -1313,6 +1312,9 @@ static void mptcp_set_rwin(struct tcp_sock *tp, struct tcphdr *th) th->window = htons(new_win); MPTCP_INC_STATS(sock_net(ssk), MPTCP_MIB_RCVWNDSHARED); } + +update_wspace: + WRITE_ONCE(msk->old_wspace, tp->rcv_wnd); } __sum16 __mptcp_make_csum(u64 data_seq, u32 subflow_seq, u16 data_len, __wsum sum)

3 weeks, 6 days

2
1
0 0

[PATCH] usb: gadget: udc: renesas_usb3: Fix compiler warning

by guoren＠kernel.org

From: Guo Ren <guoren(a)linux.alibaba.com> drivers/usb/gadget/udc/renesas_usb3.c: In function 'renesas_usb3_probe': drivers/usb/gadget/udc/renesas_usb3.c:2638:73: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size 6 [-Wformat-truncation=] 2638 | snprintf(usb3_ep->ep_name, sizeof(usb3_ep->ep_name), "ep%d", i); ^~~~~~~~~~~~~~~~~~~~~~~~ ^~ ^ Fixes: 8292493c22c8 ("riscv: Kconfig.socs: Add ARCH_RENESAS kconfig option") Cc: stable(a)vger.kernel.org Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202501201409.BIQPtkeB-lkp@intel.com/ Signed-off-by: Guo Ren <guoren(a)linux.alibaba.com> Signed-off-by: Guo Ren <guoren(a)kernel.org> --- drivers/usb/gadget/udc/renesas_usb3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/udc/renesas_usb3.c b/drivers/usb/gadget/udc/renesas_usb3.c index fce5c41d9f29..89b304cf6d03 100644 --- a/drivers/usb/gadget/udc/renesas_usb3.c +++ b/drivers/usb/gadget/udc/renesas_usb3.c @@ -310,7 +310,7 @@ struct renesas_usb3_request { struct list_head queue; }; -#define USB3_EP_NAME_SIZE 8 +#define USB3_EP_NAME_SIZE 16 struct renesas_usb3_ep { struct usb_ep ep; struct renesas_usb3 *usb3; -- 2.40.1

3 weeks, 6 days

3
2
0 0

Patch "net/sched: Fix mirred deadlock on device recursion" should probably be ported to 5.4, 5.10 and 5.15 LTS.

by Xingyu Li

Hi, We noticed that the patch 0f022d32c3ec should be probably ported to 6.1 and 6.6 LTS according to the bug introducing commit. Also, it can be applied to the latest version of these two LTS branches without conflicts. Its bug introducing commit is 3bcb846ca4cf. According to our manual analysis, the vulnerability is a deadlock caused by recursive locking of the qdisc lock (`sch->q.lock`) when packets are redirected in a loop (e.g., mirroring or redirecting packets to the same device). This happens because the same qdisc lock is attempted to be acquired multiple times by the same CPU, leading to a deadlock. The commit 3bcb846ca4cf removes the `spin_trylock()` in `net_tx_action()` and replaces it with `spin_lock()`. By doing so, it eliminates the non-blocking lock attempt (`spin_trylock()`), which would fail if the lock was already held, preventing recursive locking. The `spin_lock()` will block (wait) if the lock is already held, allowing for the possibility of the same CPU attempting to acquire the same lock recursively, leading to a deadlock. The patch adds an `owner` field to the `Qdisc` structure to track the CPU that currently owns the qdisc. Before enqueueing a packet to the qdisc, it checks if the current CPU is the owner. If so, it drops the packet to prevent the recursive locking. This effectively prevents the deadlock by ensuring that the same CPU doesn't attempt to acquire the lock recursively. -- Yours sincerely, Xingyu

3 weeks, 6 days

2
2
0 0

Patch "tipc: fix kernel warning when sending SYN message" should be probably ported to 5.10 and 5.15 LTS

by Xingyu Li

Hi, We noticed that the patch 11a4d6f67cf5 should be ported to 5.10 and 5.15 LTS according to the bug introducing commit. Also, it can be applied to the latest version of these two LTS branches without conflicts. Its bug introducing commit is f25dcc7687d4. The kernel warning and stack trace indicate a problem when sending a SYN message in TIPC (Transparent Inter-Process Communication). The issue arises because `copy_from_iter()` is being called with an uninitialized `iov_iter` structure, leading to invalid memory operations. The commit (`f25dcc7687d4`) introduces the vulnerability by replacing the old data copying mechanisms with the new `copy_from_iter()` function without ensuring that the `iov_iter` structure is properly initialized in all code paths. The patch adds initialization of `iov_iter` with "iov_iter_kvec(&m.msg_iter, ITER_SOURCE, NULL, 0, 0);", which ensures that even when there's no data to send, the `iov_iter` is correctly set up, preventing the kernel warning/crash when `copy_from_iter()` is called. -- Yours sincerely, Xingyu

3 weeks, 6 days

2
1
0 0

Patch "net: flow_dissector: use DEBUG_NET_WARN_ON_ONCE" should probably be ported to 5.4, 5.10 and 5.15 LTS.

by Xingyu Li

Hi, We noticed that the patch 120f1c857a73 should be ported to 5.4, 5.10 and 5.15 LTS according to bug introducing commits. Also, they can be applied to the latest version of these three branches without conflicting. Its bug introducing commit is 9b52e3f267a6. According to our manual analysis, the commit (9b52e3f267a6) introduced a `WARN_ON_ONCE(!net);` statement in the `__skb_flow_dissect` function within `net/core/flow_dissector.c`. This change began triggering warnings (splat messages) when `net` is `NULL`, which can happen in legitimate use cases, such as when `__skb_get_hash()` is called by the nftables tracing infrastructure to identify packets in traces. The patch provided replaces this `WARN_ON_ONCE(!net);` with `DEBUG_NET_WARN_ON_ONCE(!net);`, which is more appropriate for situations where `net` can be `NULL` without it indicating a critical issue. This change prevents unnecessary warning messages from appearing, which can clutter logs and potentially mask real issues. Therefore, the prior commit introduced the issue (the unnecessary warnings when `net` is `NULL`), and the patch fixes this by adjusting the warning mechanism. -- Yours sincerely, Xingyu

3 weeks, 6 days

2
1
0 0

[PATCH 5.15.y] regmap: detach regmap from dev on regmap_exit

by Tzung-Bi Shih

From: Cosmin Tanislav <demonsingur(a)gmail.com> commit 3061e170381af96d1e66799d34264e6414d428a7 upstream. This is a reland commit: - f373a189817584d0af5f922e91cad40e45f12314 backported it incorrectly. - 7aee9bcc5c56086af6c063b4aaef59d4e42e0a69 reverted the wrong commit. - This re-backports it. At the end of __regmap_init(), if dev is not NULL, regmap_attach_dev() is called, which adds a devres reference to the regmap, to be able to retrieve a dev's regmap by name using dev_get_regmap(). When calling regmap_exit, the opposite does not happen, and the reference is kept until the dev is detached. Add a regmap_detach_dev() function and call it in regmap_exit() to make sure that the devres reference is not kept. Cc: stable(a)vger.kernel.org Fixes: 72b39f6f2b5a ("regmap: Implement dev_get_regmap()") Signed-off-by: Cosmin Tanislav <demonsingur(a)gmail.com> Rule: add Link: https://lore.kernel.org/stable/20241128130554.362486-1-demonsingur%40gmail.… Link: https://patch.msgid.link/20241128131625.363835-1-demonsingur@gmail.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Link: https://lore.kernel.org/r/20250115033314.2540588-1-tzungbi@kernel.org Link: https://lore.kernel.org/r/20250115033244.2540522-1-tzungbi@kernel.org Signed-off-by: Tzung-Bi Shih <tzungbi(a)kernel.org> --- drivers/base/regmap/regmap.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c index 85d324fd6a87..6d94ad8bf1eb 100644 --- a/drivers/base/regmap/regmap.c +++ b/drivers/base/regmap/regmap.c @@ -663,6 +663,17 @@ int regmap_attach_dev(struct device *dev, struct regmap *map, } EXPORT_SYMBOL_GPL(regmap_attach_dev); +static int dev_get_regmap_match(struct device *dev, void *res, void *data); + +static int regmap_detach_dev(struct device *dev, struct regmap *map) +{ + if (!dev) + return 0; + + return devres_release(dev, dev_get_regmap_release, + dev_get_regmap_match, (void *)map->name); +} + static enum regmap_endian regmap_get_reg_endian(const struct regmap_bus *bus, const struct regmap_config *config) { @@ -1531,6 +1542,7 @@ void regmap_exit(struct regmap *map) { struct regmap_async *async; + regmap_detach_dev(map->dev, map); regcache_exit(map); regmap_debugfs_exit(map); regmap_range_exit(map); -- 2.48.0.rc2.279.g1de40edade-goog

3 weeks, 6 days

1
0
0 0

[PATCH 6.1.y] regmap: detach regmap from dev on regmap_exit

by Tzung-Bi Shih

From: Cosmin Tanislav <demonsingur(a)gmail.com> commit 3061e170381af96d1e66799d34264e6414d428a7 upstream. This is a reland commit: - 48dc44f3c1afa29390cb2fbc8badad1b1111cea4 backported it incorrectly. - 276185236bd8281dca88863b751b481e027cada7 reverted the wrong commit. - This re-backports it. At the end of __regmap_init(), if dev is not NULL, regmap_attach_dev() is called, which adds a devres reference to the regmap, to be able to retrieve a dev's regmap by name using dev_get_regmap(). When calling regmap_exit, the opposite does not happen, and the reference is kept until the dev is detached. Add a regmap_detach_dev() function and call it in regmap_exit() to make sure that the devres reference is not kept. Cc: stable(a)vger.kernel.org Fixes: 72b39f6f2b5a ("regmap: Implement dev_get_regmap()") Signed-off-by: Cosmin Tanislav <demonsingur(a)gmail.com> Rule: add Link: https://lore.kernel.org/stable/20241128130554.362486-1-demonsingur%40gmail.… Link: https://patch.msgid.link/20241128131625.363835-1-demonsingur@gmail.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Link: https://lore.kernel.org/r/20250115033244.2540522-1-tzungbi@kernel.org Signed-off-by: Tzung-Bi Shih <tzungbi(a)kernel.org> --- drivers/base/regmap/regmap.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c index 15b37a4163d3..f0e314abcafc 100644 --- a/drivers/base/regmap/regmap.c +++ b/drivers/base/regmap/regmap.c @@ -652,6 +652,17 @@ int regmap_attach_dev(struct device *dev, struct regmap *map, } EXPORT_SYMBOL_GPL(regmap_attach_dev); +static int dev_get_regmap_match(struct device *dev, void *res, void *data); + +static int regmap_detach_dev(struct device *dev, struct regmap *map) +{ + if (!dev) + return 0; + + return devres_release(dev, dev_get_regmap_release, + dev_get_regmap_match, (void *)map->name); +} + static enum regmap_endian regmap_get_reg_endian(const struct regmap_bus *bus, const struct regmap_config *config) { @@ -1536,6 +1547,7 @@ void regmap_exit(struct regmap *map) { struct regmap_async *async; + regmap_detach_dev(map->dev, map); regcache_exit(map); regmap_debugfs_exit(map); regmap_range_exit(map); -- 2.48.0.rc2.279.g1de40edade-goog

3 weeks, 6 days

1
0
0 0

[PATCH] atm/fore200e: Fix possible data race in fore200e_open()

by Gui-Dong Han

Protect access to fore200e->available_cell_rate with rate_mtx lock to prevent potential data race. The field fore200e.available_cell_rate is generally protected by the lock fore200e.rate_mtx when accessed. In all other read and write cases, this field is consistently protected by the lock, except for this case and during initialization. This potential bug was detected by our experimental static analysis tool, which analyzes locking APIs and paired functions to identify data races and atomicity violations. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)vger.kernel.org Signed-off-by: Gui-Dong Han <2045gemini(a)gmail.com> --- drivers/atm/fore200e.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c index 4fea1149e003..f62e38571440 100644 --- a/drivers/atm/fore200e.c +++ b/drivers/atm/fore200e.c @@ -1374,7 +1374,9 @@ fore200e_open(struct atm_vcc *vcc) vcc->dev_data = NULL; + mutex_lock(&fore200e->rate_mtx); fore200e->available_cell_rate += vcc->qos.txtp.max_pcr; + mutex_unlock(&fore200e->rate_mtx); kfree(fore200e_vcc); return -EINVAL; -- 2.25.1

3 weeks, 6 days

3
4
0 0

[PATCH 0/4] media: nuvoton: Fix some reference handling issues

by Ricardo Ribalda

When trying out 6.13 cocci, some bugs were found. The fixes without using cleanup.h should be backported. The last two patches make use of cleanup.h to avoid this kind of errors in the future. Signed-off-by: Ricardo Ribalda <ribalda(a)chromium.org> --- Ricardo Ribalda (4): media: nuvoton: Fix reference handling of ece_pdev media: nuvoton: Fix reference handling of ece_node media: nuvoton: Use cleanup.h macros for device_node media: nuvoton: Use cleanup.h macros for put_device drivers/media/platform/nuvoton/npcm-video.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- base-commit: c4b7779abc6633677e6edb79e2809f4f61fde157 change-id: 20250121-nuvoton-fe870cbeffb6 Best regards, -- Ricardo Ribalda <ribalda(a)chromium.org>

4 weeks

1
2
0 0

[for-next][PATCH 1/2] ring-buffer: Do not allow events in NMI with generic atomic64 cmpxchg()

by Steven Rostedt

From: Steven Rostedt <rostedt(a)goodmis.org> Some architectures can not safely do atomic64 operations in NMI context. Since the ring buffer relies on atomic64 operations to do its time keeping, if an event is requested in NMI context, reject it for these architectures. Cc: stable(a)vger.kernel.org Cc: Mark Rutland <mark.rutland(a)arm.com> Cc: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Andreas Larsson <andreas(a)gaisler.com> Link: https://lore.kernel.org/20250120235721.407068250@goodmis.org Fixes: c84897c0ff592 ("ring-buffer: Remove 32bit timestamp logic") Closes: https://lore.kernel.org/all/86fb4f86-a0e4-45a2-a2df-3154acc4f086@gaisler.co… Reported-by: Ludwig Rydberg <ludwig.rydberg(a)gaisler.com> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Reviewed-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> --- kernel/trace/ring_buffer.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index 6d61ff78926b..b8e0ae15ca5b 100644 --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -4398,8 +4398,13 @@ rb_reserve_next_event(struct trace_buffer *buffer, int nr_loops = 0; int add_ts_default; - /* ring buffer does cmpxchg, make sure it is safe in NMI context */ - if (!IS_ENABLED(CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG) && + /* + * ring buffer does cmpxchg as well as atomic64 operations + * (which some archs use locking for atomic64), make sure this + * is safe in NMI context + */ + if ((!IS_ENABLED(CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG) || + IS_ENABLED(CONFIG_GENERIC_ATOMIC64)) && (unlikely(in_nmi()))) { return NULL; } -- 2.45.2

4 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2025