Since the new_metric and last_hop_metric variables can reach
the MAX_METRIC(0xffffffff) value, an integer overflow may occur
when multiplying them by 10/9. It can lead to incorrect behavior.
Found by InfoTeCS on behalf of Linux Verification Center
(linuxtesting.org) with SVACE.
Fixes: a8d418d9ac25 ("mac80211: mesh: only switch path when new metric is at least 10% better")
Cc: stable(a)vger.kernel.org
Signed-off-by: Ilia Gavrilov <Ilia.Gavrilov(a)infotecs.ru>
---
net/mac80211/mesh_hwmp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index 4e9546e998b6..7d367ff1efc2 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -458,7 +458,7 @@ static u32 hwmp_route_info_get(struct ieee80211_sub_if_data *sdata,
(mpath->sn == orig_sn &&
(rcu_access_pointer(mpath->next_hop) !=
sta ?
- mult_frac(new_metric, 10, 9) :
+ mult_frac((u64)new_metric, 10, 9) :
new_metric) >= mpath->metric)) {
process = false;
fresh_info = false;
@@ -533,7 +533,7 @@ static u32 hwmp_route_info_get(struct ieee80211_sub_if_data *sdata,
if ((mpath->flags & MESH_PATH_FIXED) ||
((mpath->flags & MESH_PATH_ACTIVE) &&
((rcu_access_pointer(mpath->next_hop) != sta ?
- mult_frac(last_hop_metric, 10, 9) :
+ mult_frac((u64)last_hop_metric, 10, 9) :
last_hop_metric) > mpath->metric)))
fresh_info = false;
} else {
--
2.39.5
The patch below does not apply to the 6.1-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-6.1.y
git checkout FETCH_HEAD
git cherry-pick -x c9a40292a44e78f71258b8522655bffaf5753bdb
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025011246-appealing-angler-4f22@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From c9a40292a44e78f71258b8522655bffaf5753bdb Mon Sep 17 00:00:00 2001
From: Jens Axboe <axboe(a)kernel.dk>
Date: Wed, 8 Jan 2025 10:28:05 -0700
Subject: [PATCH] io_uring/eventfd: ensure io_eventfd_signal() defers another
RCU period
io_eventfd_do_signal() is invoked from an RCU callback, but when
dropping the reference to the io_ev_fd, it calls io_eventfd_free()
directly if the refcount drops to zero. This isn't correct, as any
potential freeing of the io_ev_fd should be deferred another RCU grace
period.
Just call io_eventfd_put() rather than open-code the dec-and-test and
free, which will correctly defer it another RCU grace period.
Fixes: 21a091b970cd ("io_uring: signal registered eventfd to process deferred task work")
Reported-by: Jann Horn <jannh(a)google.com>
Cc: stable(a)vger.kernel.org
Tested-by: Li Zetao <lizetao1(a)huawei.com>
Reviewed-by: Li Zetao<lizetao1(a)huawei.com>
Reviewed-by: Prasanna Kumar T S M <ptsm(a)linux.microsoft.com>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
diff --git a/io_uring/eventfd.c b/io_uring/eventfd.c
index fab936d31ba8..100d5da94cb9 100644
--- a/io_uring/eventfd.c
+++ b/io_uring/eventfd.c
@@ -33,20 +33,18 @@ static void io_eventfd_free(struct rcu_head *rcu)
kfree(ev_fd);
}
+static void io_eventfd_put(struct io_ev_fd *ev_fd)
+{
+ if (refcount_dec_and_test(&ev_fd->refs))
+ call_rcu(&ev_fd->rcu, io_eventfd_free);
+}
+
static void io_eventfd_do_signal(struct rcu_head *rcu)
{
struct io_ev_fd *ev_fd = container_of(rcu, struct io_ev_fd, rcu);
eventfd_signal_mask(ev_fd->cq_ev_fd, EPOLL_URING_WAKE);
-
- if (refcount_dec_and_test(&ev_fd->refs))
- io_eventfd_free(rcu);
-}
-
-static void io_eventfd_put(struct io_ev_fd *ev_fd)
-{
- if (refcount_dec_and_test(&ev_fd->refs))
- call_rcu(&ev_fd->rcu, io_eventfd_free);
+ io_eventfd_put(ev_fd);
}
static void io_eventfd_release(struct io_ev_fd *ev_fd, bool put_ref)
For WCN6855, board ID specific NVM needs to be downloaded once board ID
is available, but the default NVM is always downloaded currently, and
the wrong NVM causes poor RF performance which effects user experience.
Fix by downloading board ID specific NVM if board ID is available.
Cc: Bjorn Andersson <bjorande(a)quicinc.com>
Cc: Aiqun Yu (Maria) <quic_aiquny(a)quicinc.com>
Cc: Cheng Jiang <quic_chejiang(a)quicinc.com>
Cc: Johan Hovold <johan(a)kernel.org>
Cc: Jens Glathe <jens.glathe(a)oldschoolsolutions.biz>
Cc: Steev Klimaszewski <steev(a)kali.org>
Cc: Paul Menzel <pmenzel(a)molgen.mpg.de>
Fixes: 095327fede00 ("Bluetooth: hci_qca: Add support for QTI Bluetooth chip wcn6855")
Cc: stable(a)vger.kernel.org # 6.4
Reviewed-by: Johan Hovold <johan+linaro(a)kernel.org>
Tested-by: Johan Hovold <johan+linaro(a)kernel.org>
Tested-by: Steev Klimaszewski <steev(a)kali.org>
Tested-by: Jens Glathe <jens.glathe(a)oldschoolsolutions.biz>
Signed-off-by: Zijun Hu <quic_zijuhu(a)quicinc.com>
---
Thank you Paul, Jens, Steev, Johan, Luiz for code review, various
verification, comments and suggestions. these comments and suggestions
are very good, and all of them are taken by this v2 patch.
Regarding the variant 'g', sorry for that i can say nothing due to
confidential information (CCI), but fortunately, we don't need to
care about its difference against one without 'g' from BT host
perspective, qca_get_hsp_nvm_name_generic() shows how to map BT chip
to firmware.
I will help to backport it to LTS kernels ASAP once this commit
is mainlined.
---
Changes in v2:
- Correct subject and commit message
- Temporarily add nvm fallback logic to speed up backport.
— Add fix/stable tags as suggested by Luiz and Johan
- Link to v1: https://lore.kernel.org/r/20241113-x13s_wcn6855_fix-v1-1-15af0aa2549c@quici…
---
drivers/bluetooth/btqca.c | 44 +++++++++++++++++++++++++++++++++++++++++---
1 file changed, 41 insertions(+), 3 deletions(-)
diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c
index dfbbac92242a..ddfe7e3c9b50 100644
--- a/drivers/bluetooth/btqca.c
+++ b/drivers/bluetooth/btqca.c
@@ -717,6 +717,29 @@ static void qca_generate_hsp_nvm_name(char *fwname, size_t max_size,
snprintf(fwname, max_size, "qca/hpnv%02x%s.%x", rom_ver, variant, bid);
}
+static void qca_get_hsp_nvm_name_generic(struct qca_fw_config *cfg,
+ struct qca_btsoc_version ver,
+ u8 rom_ver, u16 bid)
+{
+ const char *variant;
+
+ /* hsp gf chip */
+ if ((le32_to_cpu(ver.soc_id) & QCA_HSP_GF_SOC_MASK) == QCA_HSP_GF_SOC_ID)
+ variant = "g";
+ else
+ variant = "";
+
+ if (bid == 0x0)
+ snprintf(cfg->fwname, sizeof(cfg->fwname), "qca/hpnv%02x%s.bin",
+ rom_ver, variant);
+ else if (bid & 0xff00)
+ snprintf(cfg->fwname, sizeof(cfg->fwname), "qca/hpnv%02x%s.b%x",
+ rom_ver, variant, bid);
+ else
+ snprintf(cfg->fwname, sizeof(cfg->fwname), "qca/hpnv%02x%s.b%02x",
+ rom_ver, variant, bid);
+}
+
static inline void qca_get_nvm_name_generic(struct qca_fw_config *cfg,
const char *stem, u8 rom_ver, u16 bid)
{
@@ -810,8 +833,15 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate,
/* Give the controller some time to get ready to receive the NVM */
msleep(10);
- if (soc_type == QCA_QCA2066 || soc_type == QCA_WCN7850)
+ switch (soc_type) {
+ case QCA_QCA2066:
+ case QCA_WCN6855:
+ case QCA_WCN7850:
qca_read_fw_board_id(hdev, &boardid);
+ break;
+ default:
+ break;
+ }
/* Download NVM configuration */
config.type = TLV_TYPE_NVM;
@@ -848,8 +878,7 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate,
"qca/msnv%02x.bin", rom_ver);
break;
case QCA_WCN6855:
- snprintf(config.fwname, sizeof(config.fwname),
- "qca/hpnv%02x.bin", rom_ver);
+ qca_get_hsp_nvm_name_generic(&config, ver, rom_ver, boardid);
break;
case QCA_WCN7850:
qca_get_nvm_name_generic(&config, "hmt", rom_ver, boardid);
@@ -861,9 +890,18 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate,
}
}
+download_nvm:
err = qca_download_firmware(hdev, &config, soc_type, rom_ver);
if (err < 0) {
bt_dev_err(hdev, "QCA Failed to download NVM (%d)", err);
+ if (err == -ENOENT && boardid != 0 &&
+ soc_type == QCA_WCN6855) {
+ boardid = 0;
+ qca_get_hsp_nvm_name_generic(&config, ver,
+ rom_ver, boardid);
+ bt_dev_warn(hdev, "QCA fallback to default NVM");
+ goto download_nvm;
+ }
return err;
}
---
base-commit: e88b020190bf5bc3e7ce5bd8003fc39b23cc95fe
change-id: 20241113-x13s_wcn6855_fix-53c573ff7878
Best regards,
--
Zijun Hu <quic_zijuhu(a)quicinc.com>
Commit c7ff693fa2094ba0a9d0a20feb4ab1658eff9c33 ("module: Split
modules_install compression and in-kernel decompression") removed the
MODULE_COMPRESS_NONE, but left it loadpin's Kconfig, and removing it
Signed-off-by: Arulpandiyan Vadivel <arulpandiyan.vadivel(a)siemens.com>
---
security/loadpin/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/security/loadpin/Kconfig b/security/loadpin/Kconfig
index 848f8b4a60190..94348e2831db9 100644
--- a/security/loadpin/Kconfig
+++ b/security/loadpin/Kconfig
@@ -16,7 +16,7 @@ config SECURITY_LOADPIN_ENFORCE
depends on SECURITY_LOADPIN
# Module compression breaks LoadPin unless modules are decompressed in
# the kernel.
- depends on !MODULES || (MODULE_COMPRESS_NONE || MODULE_DECOMPRESS)
+ depends on !MODULES || MODULE_DECOMPRESS
help
If selected, LoadPin will enforce pinning at boot. If not
selected, it can be enabled at boot with the kernel parameter
--
2.39.5
Hi Maciej,
On 2025/1/13 1:49, Maciej Żenczykowski Wrote:
> (a) I think this looks like a bug on the sending Win10 side, rather
> than a parsing bug in Linux,
> with there being no ZLP, and no short (<512) frame, there's simply no
> way for the receiver to split at the right spot.
>
> Indeed, fixing this on the Linux/parsing side seems non-trivial...
> I guess we could try to treat the connection as simply a serial
> connection (ie. ignore frame boundaries), but then we might have
> issues with other senders...
>
> I guess the most likely 'correct' hack/fix would be to hold on to the
> extra 'N*512' bytes (it doesn't even have to be 1, though likely the N
> is odd), if it starts with a NTH header...
Make sence, it seems we only need to save the rest data beside
dwBlockLength for next unwrap if a hack is acceptable, otherwise I may
need to check if a custom host driver for Windows10 user feasible.
I didn't look carefully into the 1byte and padding stuff with Windows11
host yet, I will take a look then.
> (b) I notice the '512' not '1024', I think this implies a USB2
> connection instead of USB3
> -- could you try replicating this with a USB3 capable data cable (and
> USB3 ports), this should result in 1024 block size instead of 512.
>
> I'm wondering if the win10 stack is avoiding generating N*1024, but
> then hitting N*512 with odd N...
Yes, I am using USB2.0 connection to better capture the crime scene.
Normally the OUT transfer on USB3.0 SuperSpeed connection comes with a bunch
of 1024B Data Pakcet along with a Short Packet less than 1024B in the end from
the Lecroy trace.
It's also reproducible on USB3.0 SuperSpeed connection using dwc3 controller,
but it will cost more time and make it difficult to capture the online data
(limited tracer HW buffer), I can try using software tracing or custom logs
later:
[ 5] 26.00-27.00 sec 183 MBytes 1.54 Gbits/sec
[ 5] 27.00-28.00 sec 182 MBytes 1.53 Gbits/sec
[ 206.123935] configfs.gadget.2: Wrong NDP SIGN
[ 206.129785] configfs.gadget.2: Wrong NTH SIGN, skblen 12208
[ 206.136802] HEAD:0000000004f66a88: 80 06 bc f9 c0 a8 24 66 c0 a8 24 65 f7 24 14 51 aa 1a 30 d5 01 f8 01 26 50 10 20 14 27 3d 00 00
[ 5] 28.00-29.00 sec 128 MBytes 1.07 Gbits/sec
[ 5] 29.00-30.00 sec 191 MBytes 1.61 Gbits/sec
>
> Presumably '512' would be '64' with USB1.0/1.1, but I guess finding a
> USB1.x port/host to test against is likely to be near impossible...
>
> I'll try to see if I can find the source of the bug in the Win
> driver's sources (though based on it being Win10 only, may need to
> search history)
> It's great if you can analyze from the host driver.
I didn't know if the NCM driver open-sourced on github by M$ is the correspond
version. They said that only Win 11 officially support NCM in the issue on github
yet they do have a built-in driver in Win10 and 2004 tag there in the repo.