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)
From: BH Hsieh <bhsieh(a)nvidia.com>
Observed VBUS_OVERRIDE & ID_OVERRIDE might be programmed
with unexpected value prior to XUSB PADCTL driver, this
could also occur in virtualization scenario.
For example, UEFI firmware programs ID_OVERRIDE=GROUNDED to set
a type-c port to host mode and keeps the value to kernel.
If the type-c port is connected a usb host, below errors can be
observed right after usb host mode driver gets probed. The errors
would keep until usb role class driver detects the type-c port
as device mode and notifies usb device mode driver to set both
ID_OVERRIDE and VBUS_OVERRIDE to correct value by XUSB PADCTL
driver.
[ 173.765814] usb usb3-port2: Cannot enable. Maybe the USB cable is bad?
[ 173.765837] usb usb3-port2: config error
Taking virtualization into account, asserting XUSB PADCTL
reset would break XUSB functions used by other guest OS,
hence only reset VBUS & ID OVERRIDE of the port in
utmi_phy_init.
Fixes: bbf711682cd5 ("phy: tegra: xusb: Add Tegra186 support")
Cc: stable(a)vger.kernel.org
Change-Id: Ic63058d4d49b4a1f8f9ab313196e20ad131cc591
Signed-off-by: BH Hsieh <bhsieh(a)nvidia.com>
Signed-off-by: Henry Lin <henryl(a)nvidia.com>
---
V1 -> V2: Only reset VBUS/ID OVERRIDE for otg/peripheral port
drivers/phy/tegra/xusb-tegra186.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/phy/tegra/xusb-tegra186.c b/drivers/phy/tegra/xusb-tegra186.c
index 0f60d5d1c167..fae6242aa730 100644
--- a/drivers/phy/tegra/xusb-tegra186.c
+++ b/drivers/phy/tegra/xusb-tegra186.c
@@ -928,6 +928,7 @@ static int tegra186_utmi_phy_init(struct phy *phy)
unsigned int index = lane->index;
struct device *dev = padctl->dev;
int err;
+ u32 reg;
port = tegra_xusb_find_usb2_port(padctl, index);
if (!port) {
@@ -935,6 +936,16 @@ static int tegra186_utmi_phy_init(struct phy *phy)
return -ENODEV;
}
+ if (port->mode == USB_DR_MODE_OTG ||
+ port->mode == USB_DR_MODE_PERIPHERAL) {
+ /* reset VBUS&ID OVERRIDE */
+ reg = padctl_readl(padctl, USB2_VBUS_ID);
+ reg &= ~VBUS_OVERRIDE;
+ reg &= ~ID_OVERRIDE(~0);
+ reg |= ID_OVERRIDE_FLOATING;
+ padctl_writel(padctl, reg, USB2_VBUS_ID);
+ }
+
if (port->supply && port->mode == USB_DR_MODE_HOST) {
err = regulator_enable(port->supply);
if (err) {
--
2.17.1
On the following path, flush_tlb_range() can be used for zapping normal
PMD entries (PMD entries that point to page tables) together with the PTE
entries in the pointed-to page table:
collapse_pte_mapped_thp
pmdp_collapse_flush
flush_tlb_range
The arm64 version of flush_tlb_range() has a comment describing that it can
be used for page table removal, and does not use any last-level
invalidation optimizations. Fix the X86 version by making it behave the
same way.
Currently, X86 only uses this information for the following two purposes,
which I think means the issue doesn't have much impact:
- In native_flush_tlb_multi() for checking if lazy TLB CPUs need to be
IPI'd to avoid issues with speculative page table walks.
- In Hyper-V TLB paravirtualization, again for lazy TLB stuff.
The patch "x86/mm: only invalidate final translations with INVLPGB" which
is currently under review (see
<https://lore.kernel.org/all/20241230175550.4046587-13-riel@surriel.com/>)
would probably be making the impact of this a lot worse.
Cc: stable(a)vger.kernel.org
Fixes: 016c4d92cd16 ("x86/mm/tlb: Add freed_tables argument to flush_tlb_mm_range")
Signed-off-by: Jann Horn <jannh(a)google.com>
---
arch/x86/include/asm/tlbflush.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index 02fc2aa06e9e0ecdba3fe948cafe5892b72e86c0..3da645139748538daac70166618d8ad95116eb74 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -242,7 +242,7 @@ void flush_tlb_multi(const struct cpumask *cpumask,
flush_tlb_mm_range((vma)->vm_mm, start, end, \
((vma)->vm_flags & VM_HUGETLB) \
? huge_page_shift(hstate_vma(vma)) \
- : PAGE_SHIFT, false)
+ : PAGE_SHIFT, true)
extern void flush_tlb_all(void);
extern void flush_tlb_mm_range(struct mm_struct *mm, unsigned long start,
---
base-commit: aa135d1d0902c49ed45bec98c61c1b4022652b7e
change-id: 20250103-x86-collapse-flush-fix-fa87ac4d5834
--
Jann Horn <jannh(a)google.com>
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
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
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
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