- Linux-stable-mirror - lists.linaro.org

[PATCH v1] arm64: dts: qcom: monaco-evk: Use correct sound card compatible to match SoC

by Mohammad Rafi Shaik

The Monaco-EVK board is based on Qualcomm's QCS8300 SoC. The DTS previously reused the sound card compatible as "qcom,qcs8275-sndcard", which is based on existing coverage. To maintain clarity and consistency, the naming conventions for the compatible should reflect actual SoC rather than the board. Therefore, update the sound card compatible as "qcom,qcs8300-sndcard" to avoid potential confusion. Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik(a)oss.qualcomm.com> --- This patch series depends on patch series: https://lore.kernel.org/linux-sound/20250905142647.2566951-1-mohammad.rafi.… --- arch/arm64/boot/dts/qcom/monaco-evk.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/qcom/monaco-evk.dts b/arch/arm64/boot/dts/qcom/monaco-evk.dts index f3c5d363921e..7187c1760ef5 100644 --- a/arch/arm64/boot/dts/qcom/monaco-evk.dts +++ b/arch/arm64/boot/dts/qcom/monaco-evk.dts @@ -38,7 +38,7 @@ max98357a: audio-codec-1 { }; sound { - compatible = "qcom,qcs8275-sndcard"; + compatible = "qcom,qcs8300-sndcard"; model = "MONACO-EVK"; pinctrl-0 = <&hs0_mi2s_active>, <&mi2s1_active>; -- 2.34.1

2 months

3
3
0 0

[PATCH net 0/3] mptcp: misc fixes for v6.17-rc6

by Matthieu Baerts (NGI0)

Here are various unrelated fixes: - Patch 1: Fix a wrong attribute type in the MPTCP Netlink specs. A fix for v6.7. - Patch 2: Avoid mentioning a deprecated MPTCP sysctl knob in the doc. A fix for v6.15. - Patch 3: Handle new warnings from ShellCheck v0.11.0. This prevents some warnings reported by some CIs. If it is not a good material for 'net', please drop it and I can resend it later, targeting 'net-next'. Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> --- Matthieu Baerts (NGI0) (3): netlink: specs: mptcp: fix if-idx attribute type doc: mptcp: net.mptcp.pm_type is deprecated selftests: mptcp: shellcheck: support v0.11.0 Documentation/netlink/specs/mptcp_pm.yaml | 2 +- Documentation/networking/mptcp.rst | 8 ++++---- tools/testing/selftests/net/mptcp/diag.sh | 2 +- tools/testing/selftests/net/mptcp/mptcp_connect.sh | 2 +- tools/testing/selftests/net/mptcp/mptcp_join.sh | 2 +- tools/testing/selftests/net/mptcp/mptcp_sockopt.sh | 2 +- tools/testing/selftests/net/mptcp/pm_netlink.sh | 5 +++-- tools/testing/selftests/net/mptcp/simult_flows.sh | 2 +- tools/testing/selftests/net/mptcp/userspace_pm.sh | 2 +- 9 files changed, 14 insertions(+), 13 deletions(-) --- base-commit: e2a10daba84968f6b5777d150985fd7d6abc9c84 change-id: 20250908-net-mptcp-misc-fixes-6-17-rc5-7550f5f90b66 Best regards, -- Matthieu Baerts (NGI0) <matttbe(a)kernel.org>

2 months

6
8
0 0

[PATCH] crypto: aspeed - Fix dma_unmap_sg() direction

by Thomas Fourier

It seems like everywhere in this file, when the request is not bidirectional, req->src is mapped with DMA_TO_DEVICE and req->src is mapped with DMA_FROM_DEVICE. Fixes: 62f58b1637b7 ("crypto: aspeed - add HACE crypto driver") Cc: <stable(a)vger.kernel.org> Signed-off-by: Thomas Fourier <fourier.thomas(a)gmail.com> --- drivers/crypto/aspeed/aspeed-hace-crypto.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/aspeed/aspeed-hace-crypto.c b/drivers/crypto/aspeed/aspeed-hace-crypto.c index a72dfebc53ff..fa201dae1f81 100644 --- a/drivers/crypto/aspeed/aspeed-hace-crypto.c +++ b/drivers/crypto/aspeed/aspeed-hace-crypto.c @@ -346,7 +346,7 @@ static int aspeed_sk_start_sg(struct aspeed_hace_dev *hace_dev) } else { dma_unmap_sg(hace_dev->dev, req->dst, rctx->dst_nents, - DMA_TO_DEVICE); + DMA_FROM_DEVICE); dma_unmap_sg(hace_dev->dev, req->src, rctx->src_nents, DMA_TO_DEVICE); } -- 2.43.0

2 months

2
1
0 0

OFFER

by MAJOR TRADE

2 months

1
0
0 0

New September Order. 73342 Wednesday, September 10, 2025 at 07:26:21 AM

by Info - Albinayah 397

Hi Stable, Please provide a quote for your products: Include: 1.Pricing (per unit) 2.Delivery cost & timeline 3.Quote expiry date Deadline: September Thanks! Kamal Prasad Albinayah Trading

2 months

1
0
0 0

+ zram-fix-slot-write-race-condition.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: zram: fix slot write race condition has been added to the -mm mm-hotfixes-unstable branch. Its filename is zram-fix-slot-write-race-condition.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Sergey Senozhatsky <senozhatsky(a)chromium.org> Subject: zram: fix slot write race condition Date: Tue, 9 Sep 2025 13:48:35 +0900 Parallel concurrent writes to the same zram index result in leaked zsmalloc handles. Schematically we can have something like this: CPU0 CPU1 zram_slot_lock() zs_free(handle) zram_slot_lock() zram_slot_lock() zs_free(handle) zram_slot_lock() compress compress handle = zs_malloc() handle = zs_malloc() zram_slot_lock zram_set_handle(handle) zram_slot_lock zram_slot_lock zram_set_handle(handle) zram_slot_lock Either CPU0 or CPU1 zsmalloc handle will leak because zs_free() is done too early. In fact, we need to reset zram entry right before we set its new handle, all under the same slot lock scope. Link: https://lkml.kernel.org/r/20250909045150.635345-1-senozhatsky@chromium.org Fixes: 71268035f5d73 ("zram: free slot memory early during write") Signed-off-by: Sergey Senozhatsky <senozhatsky(a)chromium.org> Reported-by: Changhui Zhong <czhong(a)redhat.com> Closes: https://lore.kernel.org/all/CAGVVp+UtpGoW5WEdEU7uVTtsSCjPN=ksN6EcvyypAtFDOU… Cc: Jens Axboe <axboe(a)kernel.dk> Cc: Minchan Kim <minchan(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- drivers/block/zram/zram_drv.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) --- a/drivers/block/zram/zram_drv.c~zram-fix-slot-write-race-condition +++ a/drivers/block/zram/zram_drv.c @@ -1795,6 +1795,7 @@ static int write_same_filled_page(struct u32 index) { zram_slot_lock(zram, index); + zram_free_page(zram, index); zram_set_flag(zram, index, ZRAM_SAME); zram_set_handle(zram, index, fill); zram_slot_unlock(zram, index); @@ -1832,6 +1833,7 @@ static int write_incompressible_page(str kunmap_local(src); zram_slot_lock(zram, index); + zram_free_page(zram, index); zram_set_flag(zram, index, ZRAM_HUGE); zram_set_handle(zram, index, handle); zram_set_obj_size(zram, index, PAGE_SIZE); @@ -1855,11 +1857,6 @@ static int zram_write_page(struct zram * unsigned long element; bool same_filled; - /* First, free memory allocated to this slot (if any) */ - zram_slot_lock(zram, index); - zram_free_page(zram, index); - zram_slot_unlock(zram, index); - mem = kmap_local_page(page); same_filled = page_same_filled(mem, &element); kunmap_local(mem); @@ -1901,6 +1898,7 @@ static int zram_write_page(struct zram * zcomp_stream_put(zstrm); zram_slot_lock(zram, index); + zram_free_page(zram, index); zram_set_handle(zram, index, handle); zram_set_obj_size(zram, index, comp_len); zram_slot_unlock(zram, index); _ Patches currently in -mm which might be from senozhatsky(a)chromium.org are zram-fix-slot-write-race-condition.patch zram-protect-recomp_algorithm_show-with-init_lock.patch panic-remove-redundant-panic-cpu-backtrace.patch

2 months

1
0
0 0

[PATCHv2] zram: fix slot write race condition

by Sergey Senozhatsky

Parallel concurrent writes to the same zram index result in leaked zsmalloc handles. Schematically we can have something like this: CPU0 CPU1 zram_slot_lock() zs_free(handle) zram_slot_lock() zram_slot_lock() zs_free(handle) zram_slot_lock() compress compress handle = zs_malloc() handle = zs_malloc() zram_slot_lock zram_set_handle(handle) zram_slot_lock zram_slot_lock zram_set_handle(handle) zram_slot_lock Either CPU0 or CPU1 zsmalloc handle will leak because zs_free() is done too early. In fact, we need to reset zram entry right before we set its new handle, all under the same slot lock scope. Cc: stable(a)vger.kernel.org Reported-by: Changhui Zhong <czhong(a)redhat.com> Closes: https://lore.kernel.org/all/CAGVVp+UtpGoW5WEdEU7uVTtsSCjPN=ksN6EcvyypAtFDOU… Fixes: 71268035f5d73 ("zram: free slot memory early during write") Signed-off-by: Sergey Senozhatsky <senozhatsky(a)chromium.org> --- drivers/block/zram/zram_drv.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c index 9ac271b82780..78b56cd7698e 100644 --- a/drivers/block/zram/zram_drv.c +++ b/drivers/block/zram/zram_drv.c @@ -1788,6 +1788,7 @@ static int write_same_filled_page(struct zram *zram, unsigned long fill, u32 index) { zram_slot_lock(zram, index); + zram_free_page(zram, index); zram_set_flag(zram, index, ZRAM_SAME); zram_set_handle(zram, index, fill); zram_slot_unlock(zram, index); @@ -1825,6 +1826,7 @@ static int write_incompressible_page(struct zram *zram, struct page *page, kunmap_local(src); zram_slot_lock(zram, index); + zram_free_page(zram, index); zram_set_flag(zram, index, ZRAM_HUGE); zram_set_handle(zram, index, handle); zram_set_obj_size(zram, index, PAGE_SIZE); @@ -1848,11 +1850,6 @@ static int zram_write_page(struct zram *zram, struct page *page, u32 index) unsigned long element; bool same_filled; - /* First, free memory allocated to this slot (if any) */ - zram_slot_lock(zram, index); - zram_free_page(zram, index); - zram_slot_unlock(zram, index); - mem = kmap_local_page(page); same_filled = page_same_filled(mem, &element); kunmap_local(mem); @@ -1894,6 +1891,7 @@ static int zram_write_page(struct zram *zram, struct page *page, u32 index) zcomp_stream_put(zstrm); zram_slot_lock(zram, index); + zram_free_page(zram, index); zram_set_handle(zram, index, handle); zram_set_obj_size(zram, index, comp_len); zram_slot_unlock(zram, index); -- 2.51.0.384.g4c02a37b29-goog

2 months

2
1
0 0

+ mm-hugetlb-fix-copy_hugetlb_page_range-to-use-pt_share_count.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/hugetlb: fix copy_hugetlb_page_range() to use ->pt_share_count has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-hugetlb-fix-copy_hugetlb_page_range-to-use-pt_share_count.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Jane Chu <jane.chu(a)oracle.com> Subject: mm/hugetlb: fix copy_hugetlb_page_range() to use ->pt_share_count Date: Tue, 9 Sep 2025 12:43:57 -0600 commit 59d9094df3d79 introduced ->pt_share_count dedicated to hugetlb PMD share count tracking, but omitted fixing copy_hugetlb_page_range(), leaving the function relying on page_count() for tracking that no longer works. When lazy page table copy for hugetlb is disabled (commit bcd51a3c679d), fork()'ing with hugetlb PMD sharing quickly locks up - [ 239.446559] watchdog: BUG: soft lockup - CPU#75 stuck for 27s! [ 239.446611] RIP: 0010:native_queued_spin_lock_slowpath+0x7e/0x2e0 [ 239.446631] Call Trace: [ 239.446633] <TASK> [ 239.446636] _raw_spin_lock+0x3f/0x60 [ 239.446639] copy_hugetlb_page_range+0x258/0xb50 [ 239.446645] copy_page_range+0x22b/0x2c0 [ 239.446651] dup_mmap+0x3e2/0x770 [ 239.446654] dup_mm.constprop.0+0x5e/0x230 [ 239.446657] copy_process+0xd17/0x1760 [ 239.446660] kernel_clone+0xc0/0x3e0 [ 239.446661] __do_sys_clone+0x65/0xa0 [ 239.446664] do_syscall_64+0x82/0x930 [ 239.446668] ? count_memcg_events+0xd2/0x190 [ 239.446671] ? syscall_trace_enter+0x14e/0x1f0 [ 239.446676] ? syscall_exit_work+0x118/0x150 [ 239.446677] ? arch_exit_to_user_mode_prepare.constprop.0+0x9/0xb0 [ 239.446681] ? clear_bhb_loop+0x30/0x80 [ 239.446684] ? clear_bhb_loop+0x30/0x80 [ 239.446686] entry_SYSCALL_64_after_hwframe+0x76/0x7e There are two options to resolve the potential latent issue: 1. remove the PMD sharing awareness from copy_hugetlb_page_range(), 2. fix it. This patch opts for the second option. Link: https://lkml.kernel.org/r/20250909184357.569259-1-jane.chu@oracle.com Fixes: 59d9094df3d79 ("mm: hugetlb: independent PMD page table shared count") Signed-off-by: Jane Chu <jane.chu(a)oracle.com> Cc: Cc: David Hildenbrand <david(a)redhat.com> Cc: Jane Chu <jane.chu(a)oracle.com> Cc: Liu Shixin <liushixin2(a)huawei.com> Cc: Muchun Song <muchun.song(a)linux.dev> Cc: Oscar Salvador <osalvador(a)suse.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/hugetlb.c | 13 ++++--------- 1 file changed, 4 insertions(+), 9 deletions(-) --- a/mm/hugetlb.c~mm-hugetlb-fix-copy_hugetlb_page_range-to-use-pt_share_count +++ a/mm/hugetlb.c @@ -5594,18 +5594,13 @@ int copy_hugetlb_page_range(struct mm_st break; } - /* - * If the pagetables are shared don't copy or take references. - * - * dst_pte == src_pte is the common case of src/dest sharing. - * However, src could have 'unshared' and dst shares with - * another vma. So page_count of ptep page is checked instead - * to reliably determine whether pte is shared. - */ - if (page_count(virt_to_page(dst_pte)) > 1) { +#ifdef CONFIG_HUGETLB_PMD_PAGE_TABLE_SHARING + /* If the pagetables are shared don't copy or take references. */ + if (ptdesc_pmd_pts_count(virt_to_ptdesc(dst_pte)) > 0) { addr |= last_addr_mask; continue; } +#endif dst_ptl = huge_pte_lock(h, dst, dst_pte); src_ptl = huge_pte_lockptr(h, src, src_pte); _ Patches currently in -mm which might be from jane.chu(a)oracle.com are mm-hugetlb-fix-copy_hugetlb_page_range-to-use-pt_share_count.patch

2 months

1
0
0 0

+ hung_task-fix-warnings-caused-by-unaligned-lock-pointers.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: hung_task: fix warnings caused by unaligned lock pointers has been added to the -mm mm-hotfixes-unstable branch. Its filename is hung_task-fix-warnings-caused-by-unaligned-lock-pointers.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Lance Yang <lance.yang(a)linux.dev> Subject: hung_task: fix warnings caused by unaligned lock pointers Date: Tue, 9 Sep 2025 22:52:43 +0800 The blocker tracking mechanism assumes that lock pointers are at least 4-byte aligned to use their lower bits for type encoding. However, as reported by Eero Tamminen, some architectures like m68k only guarantee 2-byte alignment of 32-bit values. This breaks the assumption and causes two related WARN_ON_ONCE checks to trigger. To fix this, the runtime checks are adjusted to silently ignore any lock that is not 4-byte aligned, effectively disabling the feature in such cases and avoiding the related warnings. Thanks to Geert Uytterhoeven for bisecting! Link: https://lkml.kernel.org/r/20250909145243.17119-1-lance.yang@linux.dev Fixes: e711faaafbe5 ("hung_task: replace blocker_mutex with encoded blocker") Signed-off-by: Lance Yang <lance.yang(a)linux.dev> Reported-by: Eero Tamminen <oak(a)helsinkinet.fi> Closes: https://lore.kernel.org/lkml/CAMuHMdW7Ab13DdGs2acMQcix5ObJK0O2dG_Fxzr8_g58R… Reviewed-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> Cc: John Paul Adrian Glaubitz <glaubitz(a)physik.fu-berlin.de> Cc: Anna Schumaker <anna.schumaker(a)oracle.com> Cc: Boqun Feng <boqun.feng(a)gmail.com> Cc: Finn Thain <fthain(a)linux-m68k.org> Cc: Geert Uytterhoeven <geert(a)linux-m68k.org> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Joel Granados <joel.granados(a)kernel.org> Cc: John Stultz <jstultz(a)google.com> Cc: Kent Overstreet <kent.overstreet(a)linux.dev> Cc: Lance Yang <lance.yang(a)linux.dev> Cc: Mingzhe Yang <mingzhe.yang(a)ly.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Sergey Senozhatsky <senozhatsky(a)chromium.org> Cc: Steven Rostedt <rostedt(a)goodmis.org> Cc: Tomasz Figa <tfiga(a)chromium.org> Cc: Waiman Long <longman(a)redhat.com> Cc: Will Deacon <will(a)kernel.org> Cc: Yongliang Gao <leonylgao(a)tencent.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/hung_task.h | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) --- a/include/linux/hung_task.h~hung_task-fix-warnings-caused-by-unaligned-lock-pointers +++ a/include/linux/hung_task.h @@ -20,6 +20,10 @@ * always zero. So we can use these bits to encode the specific blocking * type. * + * Note that on architectures where this is not guaranteed, or for any + * unaligned lock, this tracking mechanism is silently skipped for that + * lock. + * * Type encoding: * 00 - Blocked on mutex (BLOCKER_TYPE_MUTEX) * 01 - Blocked on semaphore (BLOCKER_TYPE_SEM) @@ -45,7 +49,7 @@ static inline void hung_task_set_blocker * If the lock pointer matches the BLOCKER_TYPE_MASK, return * without writing anything. */ - if (WARN_ON_ONCE(lock_ptr & BLOCKER_TYPE_MASK)) + if (lock_ptr & BLOCKER_TYPE_MASK) return; WRITE_ONCE(current->blocker, lock_ptr | type); @@ -53,8 +57,6 @@ static inline void hung_task_set_blocker static inline void hung_task_clear_blocker(void) { - WARN_ON_ONCE(!READ_ONCE(current->blocker)); - WRITE_ONCE(current->blocker, 0UL); } _ Patches currently in -mm which might be from lance.yang(a)linux.dev are maintainers-add-lance-yang-as-a-thp-reviewer.patch hung_task-fix-warnings-caused-by-unaligned-lock-pointers.patch mm-skip-mlocked-thps-that-are-underused-early-in-deferred_split_scan.patch

2 months

1
0
0 0

Re: [PATCH ath-current v2] wifi: ath10k: Fix connection after GTK rekeying

by Alexey Klimov

(add stable into c/c) On Tue Sep 2, 2025 at 3:32 PM BST, Loic Poulain wrote: > It appears that not all hardware/firmware implementations support > group key deletion correctly, which can lead to connection hangs > and deauthentication following GTK rekeying (delete and install). > > To avoid this issue, instead of attempting to delete the key using > the special WMI_CIPHER_NONE value, we now replace the key with an > invalid (random) value. > > This behavior has been observed with WCN39xx chipsets. > > Tested-on: WCN3990 hw1.0 WLAN.HL.3.3.7.c2-00931-QCAHLSWMTPLZ-1 > Reported-by: "Alexey Klimov" <alexey.klimov(a)linaro.org> > Closes: https://lore.kernel.org/all/DAWJQ2NIKY28.1XOG35E4A682G@linaro.org > Signed-off-by: Loic Poulain <loic.poulain(a)oss.qualcomm.com> The fix works great on RB1 board. Thank you. Tested-by: Alexey Klimov <alexey.klimov(a)linaro.org> # QRB2210 RB1 Difficult to say when this issue appeared initially. I'd say that around 6.6 it worked fine probably. But latest few kernel releases like 6.16, 6.15, 6.14 definetely had this issue. Maybe makes sense to add something like that: Cc: stable(a)vger.kernel.org # v6.14 > --- > v2: use random value instead of predictable zero value for key > Add Tested-on tag > > drivers/net/wireless/ath/ath10k/mac.c | 12 ++++++++++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c > index 24dd794e31ea..154ac7a70982 100644 > --- a/drivers/net/wireless/ath/ath10k/mac.c > +++ b/drivers/net/wireless/ath/ath10k/mac.c > @@ -16,6 +16,7 @@ > #include <linux/acpi.h> > #include <linux/of.h> > #include <linux/bitfield.h> > +#include <linux/random.h> > > #include "hif.h" > #include "core.h" > @@ -290,8 +291,15 @@ static int ath10k_send_key(struct ath10k_vif *arvif, > key->flags |= IEEE80211_KEY_FLAG_GENERATE_IV; > > if (cmd == DISABLE_KEY) { > - arg.key_cipher = ar->wmi_key_cipher[WMI_CIPHER_NONE]; > - arg.key_data = NULL; > + if (flags & WMI_KEY_GROUP) { > + /* Not all hardware handles group-key deletion operation > + * correctly. Replace the key with a junk value to invalidate it. > + */ > + get_random_bytes(key->key, key->keylen); > + } else { > + arg.key_cipher = ar->wmi_key_cipher[WMI_CIPHER_NONE]; > + arg.key_data = NULL; > + } > } > > return ath10k_wmi_vdev_install_key(arvif->ar, &arg); Best regards, Alexey

2 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror