- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6 1/3] uapi/auxvec: Define AT_HWCAP3 and AT_HWCAP4 aux vector, entries
by Qi Xi 07 Jul '25

07 Jul '25

From: Peter Bergner <bergner(a)linux.ibm.com> mainline inclusion from mainline-v6.9-rc1 commit 3281366a8e79a512956382885091565db1036b64 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/IC76OZ CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------------------------------------------- Changes from v1: - Add Acked-by lines. The powerpc toolchain keeps a copy of the HWCAP bit masks in our TCB for fast access by the __builtin_cpu_supports built-in function. The TCB space for the HWCAP entries - which are created in pairs - is an ABI extension, so waiting to create the space for HWCAP3 and HWCAP4 until we need them is problematical. Define AT_HWCAP3 and AT_HWCAP4 in the generic uapi header so they can be used in glibc to reserve space in the powerpc TCB for their future use. I scanned through the Linux and GLIBC source codes looking for unused AT_* values and 29 and 30 did not seem to be used, so they are what I went with. This has received Acked-by's from both GLIBC and Linux kernel developers and no reservations or Nacks from anyone. Arnd, we seem to have consensus on the patch below. Is this something you could take and apply to your tree? Peter Signed-off-by: Peter Bergner <bergner(a)linux.ibm.com> Acked-by: Adhemerval Zanella <adhemerval.zanella(a)linaro.org> Acked-by: Nicholas Piggin <npiggin(a)gmail.com> Acked-by: Szabolcs Nagy <szabolcs.nagy(a)arm.com> Acked-by: Arnd Bergmann <arnd(a)arndb.de> Commit: Michael Ellerman <mpe(a)ellerman.id.au> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Link: https://msgid.link/a406b535-dc55-4856-8ae9-5a063644a1af@linux.ibm.com Signed-off-by: Hongye Lin <linhongye(a)h-partners.com> Signed-off-by: Qi Xi <xiqi2(a)huawei.com> --- include/uapi/linux/auxvec.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/uapi/linux/auxvec.h b/include/uapi/linux/auxvec.h index c7e502bf5a6f..f8e7677e48c4 100644 --- a/include/uapi/linux/auxvec.h +++ b/include/uapi/linux/auxvec.h @@ -30,6 +30,8 @@ * differ from AT_PLATFORM. */ #define AT_RANDOM 25 /* address of 16 random bytes */ #define AT_HWCAP2 26 /* extension of AT_HWCAP */ +#define AT_HWCAP3 29 /* extension of AT_HWCAP */ +#define AT_HWCAP4 30 /* extension of AT_HWCAP */ #define AT_EXECFN 31 /* filename of program */ -- 2.33.0

2 3

[PATCH openEuler-1.0-LTS] dm raid: fix address sanitizer warning in raid_status
by Zhang Qilong 07 Jul '25

07 Jul '25

From: Mikulas Patocka <mpatocka(a)redhat.com> stable inclusion from stable-v4.19.256 commit b856ce5f4b55f752144baf17e9d5c415072652c5 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICGAMW CVE: CVE-2022-50084 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- dm raid: fix address sanitizer warning in raid_status commit 1fbeea217d8f297fe0e0956a1516d14ba97d0396 upstream. There is this warning when using a kernel with the address sanitizer and running this testsuite: https://gitlab.com/cki-project/kernel-tests/-/tree/main/storage/swraid/scsi… ================================================================== BUG: KASAN: slab-out-of-bounds in raid_status+0x1747/0x2820 [dm_raid] Read of size 4 at addr ffff888079d2c7e8 by task lvcreate/13319 CPU: 0 PID: 13319 Comm: lvcreate Not tainted 5.18.0-0.rc3.<snip> #1 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 Call Trace: <TASK> dump_stack_lvl+0x6a/0x9c print_address_description.constprop.0+0x1f/0x1e0 print_report.cold+0x55/0x244 kasan_report+0xc9/0x100 raid_status+0x1747/0x2820 [dm_raid] dm_ima_measure_on_table_load+0x4b8/0xca0 [dm_mod] table_load+0x35c/0x630 [dm_mod] ctl_ioctl+0x411/0x630 [dm_mod] dm_ctl_ioctl+0xa/0x10 [dm_mod] __x64_sys_ioctl+0x12a/0x1a0 do_syscall_64+0x5b/0x80 The warning is caused by reading conf->max_nr_stripes in raid_status. The code in raid_status reads mddev->private, casts it to struct r5conf and reads the entry max_nr_stripes. However, if we have different raid type than 4/5/6, mddev->private doesn't point to struct r5conf; it may point to struct r0conf, struct r1conf, struct r10conf or struct mpconf. If we cast a pointer to one of these structs to struct r5conf, we will be reading invalid memory and KASAN warns about it. Fix this bug by reading struct r5conf only if raid type is 4, 5 or 6. Cc: stable(a)vger.kernel.org Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com> Signed-off-by: Mike Snitzer <snitzer(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/md/dm-raid.c [just context conflicts] Signed-off-by: Zhang Qilong <zhangqilong3(a)huawei.com> --- drivers/md/dm-raid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/md/dm-raid.c b/drivers/md/dm-raid.c index 49209dae7fdd..377a6c8205ba 100644 --- a/drivers/md/dm-raid.c +++ b/drivers/md/dm-raid.c @@ -3531,11 +3531,11 @@ static const char *__get_dev_name(struct dm_dev *dev) static void raid_status(struct dm_target *ti, status_type_t type, unsigned int status_flags, char *result, unsigned int maxlen) { struct raid_set *rs = ti->private; struct mddev *mddev = &rs->md; - struct r5conf *conf = mddev->private; + struct r5conf *conf = rs_is_raid456(rs) ? mddev->private : NULL; int i, max_nr_stripes = conf ? conf->max_nr_stripes : 0; unsigned long recovery; unsigned int raid_param_cnt = 1; /* at least 1 for chunksize */ unsigned int sz = 0; unsigned int rebuild_disks; -- 2.43.0

2 1

[PATCH openEuler-1.0-LTS] dm raid: fix address sanitizer warning in raid_status
by Zhang Qilong 07 Jul '25

07 Jul '25

From: Mikulas Patocka <mpatocka(a)redhat.com> stable inclusion from stable-v4.19.256 commit b856ce5f4b55f752144baf17e9d5c415072652c5 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICGAMW CVE: CVE-2022-50084 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- dm raid: fix address sanitizer warning in raid_status commit 1fbeea217d8f297fe0e0956a1516d14ba97d0396 upstream. There is this warning when using a kernel with the address sanitizer and running this testsuite: https://gitlab.com/cki-project/kernel-tests/-/tree/main/storage/swraid/scsi… ================================================================== BUG: KASAN: slab-out-of-bounds in raid_status+0x1747/0x2820 [dm_raid] Read of size 4 at addr ffff888079d2c7e8 by task lvcreate/13319 CPU: 0 PID: 13319 Comm: lvcreate Not tainted 5.18.0-0.rc3.<snip> #1 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 Call Trace: <TASK> dump_stack_lvl+0x6a/0x9c print_address_description.constprop.0+0x1f/0x1e0 print_report.cold+0x55/0x244 kasan_report+0xc9/0x100 raid_status+0x1747/0x2820 [dm_raid] dm_ima_measure_on_table_load+0x4b8/0xca0 [dm_mod] table_load+0x35c/0x630 [dm_mod] ctl_ioctl+0x411/0x630 [dm_mod] dm_ctl_ioctl+0xa/0x10 [dm_mod] __x64_sys_ioctl+0x12a/0x1a0 do_syscall_64+0x5b/0x80 The warning is caused by reading conf->max_nr_stripes in raid_status. The code in raid_status reads mddev->private, casts it to struct r5conf and reads the entry max_nr_stripes. However, if we have different raid type than 4/5/6, mddev->private doesn't point to struct r5conf; it may point to struct r0conf, struct r1conf, struct r10conf or struct mpconf. If we cast a pointer to one of these structs to struct r5conf, we will be reading invalid memory and KASAN warns about it. Fix this bug by reading struct r5conf only if raid type is 4, 5 or 6. Cc: stable(a)vger.kernel.org Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com> Signed-off-by: Mike Snitzer <snitzer(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/md/dm-raid.c [just context conflicts] Signed-off-by: Zhang Qilong <zhangqilong3(a)huawei.com> --- drivers/md/dm-raid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/md/dm-raid.c b/drivers/md/dm-raid.c index 49209dae7fdd..377a6c8205ba 100644 --- a/drivers/md/dm-raid.c +++ b/drivers/md/dm-raid.c @@ -3531,11 +3531,11 @@ static const char *__get_dev_name(struct dm_dev *dev) static void raid_status(struct dm_target *ti, status_type_t type, unsigned int status_flags, char *result, unsigned int maxlen) { struct raid_set *rs = ti->private; struct mddev *mddev = &rs->md; - struct r5conf *conf = mddev->private; + struct r5conf *conf = rs_is_raid456(rs) ? mddev->private : NULL; int i, max_nr_stripes = conf ? conf->max_nr_stripes : 0; unsigned long recovery; unsigned int raid_param_cnt = 1; /* at least 1 for chunksize */ unsigned int sz = 0; unsigned int rebuild_disks; -- 2.43.0

2 1

[PATCH openEuler-1.0-LTS] dm raid: fix address sanitizer warning in raid_status
by Zhang Qilong 07 Jul '25

07 Jul '25

From: Mikulas Patocka <mpatocka(a)redhat.com> mainline inclusion from mainline-v5.19-rc4 commit 49dba30638e091120256a9e89125340795f034dc category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICGAMW CVE: CVE-2022-50084 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- dm raid: fix address sanitizer warning in raid_status commit 1fbeea217d8f297fe0e0956a1516d14ba97d0396 upstream. There is this warning when using a kernel with the address sanitizer and running this testsuite: https://gitlab.com/cki-project/kernel-tests/-/tree/main/storage/swraid/scsi… ================================================================== BUG: KASAN: slab-out-of-bounds in raid_status+0x1747/0x2820 [dm_raid] Read of size 4 at addr ffff888079d2c7e8 by task lvcreate/13319 CPU: 0 PID: 13319 Comm: lvcreate Not tainted 5.18.0-0.rc3.<snip> #1 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 Call Trace: <TASK> dump_stack_lvl+0x6a/0x9c print_address_description.constprop.0+0x1f/0x1e0 print_report.cold+0x55/0x244 kasan_report+0xc9/0x100 raid_status+0x1747/0x2820 [dm_raid] dm_ima_measure_on_table_load+0x4b8/0xca0 [dm_mod] table_load+0x35c/0x630 [dm_mod] ctl_ioctl+0x411/0x630 [dm_mod] dm_ctl_ioctl+0xa/0x10 [dm_mod] __x64_sys_ioctl+0x12a/0x1a0 do_syscall_64+0x5b/0x80 The warning is caused by reading conf->max_nr_stripes in raid_status. The code in raid_status reads mddev->private, casts it to struct r5conf and reads the entry max_nr_stripes. However, if we have different raid type than 4/5/6, mddev->private doesn't point to struct r5conf; it may point to struct r0conf, struct r1conf, struct r10conf or struct mpconf. If we cast a pointer to one of these structs to struct r5conf, we will be reading invalid memory and KASAN warns about it. Fix this bug by reading struct r5conf only if raid type is 4, 5 or 6. Cc: stable(a)vger.kernel.org Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com> Signed-off-by: Mike Snitzer <snitzer(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/md/dm-raid.c [just context conflicts] Signed-off-by: Zhang Qilong <zhangqilong3(a)huawei.com> --- drivers/md/dm-raid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/md/dm-raid.c b/drivers/md/dm-raid.c index 9a5d65d2223b..d3dce6bcbec3 100644 --- a/drivers/md/dm-raid.c +++ b/drivers/md/dm-raid.c @@ -3531,11 +3531,11 @@ static const char *__get_dev_name(struct dm_dev *dev) static void raid_status(struct dm_target *ti, status_type_t type, unsigned int status_flags, char *result, unsigned int maxlen) { struct raid_set *rs = ti->private; struct mddev *mddev = &rs->md; - struct r5conf *conf = mddev->private; + struct r5conf *conf = rs_is_raid456(rs) ? mddev->private : NULL; int i, max_nr_stripes = conf ? conf->max_nr_stripes : 0; unsigned long recovery; unsigned int raid_param_cnt = 1; /* at least 1 for chunksize */ unsigned int sz = 0; unsigned int rebuild_disks; -- 2.43.0

2 1

[PATCH openEuler-1.0-LTS v2] bnxt_en: Fix out-of-bound memcpy() during ethtool -w
by Dong Chenchen 07 Jul '25

07 Jul '25

From: Shruti Parab <shruti.parab(a)broadcom.com> mainline inclusion from mainline-v6.15-rc5 commit 6b87bd94f34370bbf1dfa59352bed8efab5bf419 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IC991C CVE: CVE-2025-37911 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When retrieving the FW coredump using ethtool, it can sometimes cause memory corruption: BUG: KFENCE: memory corruption in __bnxt_get_coredump+0x3ef/0x670 [bnxt_en] Corrupted memory at 0x000000008f0f30e8 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (in kfence-#45): __bnxt_get_coredump+0x3ef/0x670 [bnxt_en] ethtool_get_dump_data+0xdc/0x1a0 __dev_ethtool+0xa1e/0x1af0 dev_ethtool+0xa8/0x170 dev_ioctl+0x1b5/0x580 sock_do_ioctl+0xab/0xf0 sock_ioctl+0x1ce/0x2e0 __x64_sys_ioctl+0x87/0xc0 do_syscall_64+0x5c/0xf0 entry_SYSCALL_64_after_hwframe+0x78/0x80 ... This happens when copying the coredump segment list in bnxt_hwrm_dbg_dma_data() with the HWRM_DBG_COREDUMP_LIST FW command. The info->dest_buf buffer is allocated based on the number of coredump segments returned by the FW. The segment list is then DMA'ed by the FW and the length of the DMA is returned by FW. The driver then copies this DMA'ed segment list to info->dest_buf. In some cases, this DMA length may exceed the info->dest_buf length and cause the above BUG condition. Fix it by capping the copy length to not exceed the length of info->dest_buf. The extra DMA data contains no useful information. This code path is shared for the HWRM_DBG_COREDUMP_LIST and the HWRM_DBG_COREDUMP_RETRIEVE FW commands. The buffering is different for these 2 FW commands. To simplify the logic, we need to move the line to adjust the buffer length for HWRM_DBG_COREDUMP_RETRIEVE up, so that the new check to cap the copy length will work for both commands. Fixes: c74751f4c392 ("bnxt_en: Return error if FW returns more data than dump length") Reviewed-by: Kalesh AP <kalesh-anakkur.purayil(a)broadcom.com> Signed-off-by: Shruti Parab <shruti.parab(a)broadcom.com> Signed-off-by: Michael Chan <michael.chan(a)broadcom.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Conflicts: drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c drivers/net/ethernet/broadcom/bnxt/bnxt_coredump.c [commit b032228e58ea is not backport] Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c index 0a409ba4012a..1288064f32af 100644 --- a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c @@ -2778,20 +2778,25 @@ static int bnxt_hwrm_dbg_dma_data(struct bnxt *bp, void *msg, int msg_len, } } + if (cmn_req->req_type == + cpu_to_le16(HWRM_DBG_COREDUMP_RETRIEVE)) + info->dest_buf_size += len; + if (info->dest_buf) { if ((info->seg_start + off + len) <= BNXT_COREDUMP_BUF_LEN(info->buf_len)) { - memcpy(info->dest_buf + off, dma_buf, len); + u16 copylen = min_t(u16, len, + info->dest_buf_size - off); + + memcpy(info->dest_buf + off, dma_buf, copylen); + if (copylen < len) + break; } else { rc = -ENOBUFS; break; } } - if (cmn_req->req_type == - cpu_to_le16(HWRM_DBG_COREDUMP_RETRIEVE)) - info->dest_buf_size += len; - if (!(cmn_resp->flags & HWRM_DBG_CMN_FLAGS_MORE)) break; -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] ipvlan: Fix out-of-bounds caused by unclear skb->cb in I2e mode
by Dong Chenchen 07 Jul '25

07 Jul '25

From: zhangqiumiao <zhangqiumiao1(a)huawei.com> openEuler inclusion category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7GVI1 CVE: CVE-2023-3090 Reference: https://gitee.com/openeuler/kernel/commit/f49546d265363c51a232f28f2aede5b42… -------------------------------- We should clear skb->cb before ip_local_out or ip6_local_out in l2e mode too. Fixes: 53f51b3cd1e4 ("ipvlan: Introduce l2e mode") Co-developed-by: "t.feng" <fengtao40(a)huawei.com> Signed-off-by: zhangqiumiao <zhangqiumiao1(a)huawei.com> Signed-off-by: dongchenchen <dongchenchen2(a)huawei.com> --- drivers/net/ipvlan/ipvlan_core.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/ipvlan/ipvlan_core.c b/drivers/net/ipvlan/ipvlan_core.c index 0a82752b28b5..57803d8196ed 100644 --- a/drivers/net/ipvlan/ipvlan_core.c +++ b/drivers/net/ipvlan/ipvlan_core.c @@ -578,6 +578,9 @@ static int ipvlan_process_v4_forward(struct sk_buff *skb) goto err; } skb_dst_set(skb, &rt->dst); + + memset(IPCB(skb), 0, sizeof(*IPCB(skb))); + err = ip_local_out(net, skb->sk, skb); if (unlikely(net_xmit_eval(err))) dev->stats.tx_errors++; @@ -615,6 +618,9 @@ static int ipvlan_process_v6_forward(struct sk_buff *skb) goto err; } skb_dst_set(skb, dst); + + memset(IP6CB(skb), 0, sizeof(*IP6CB(skb))); + err = ip6_local_out(net, skb->sk, skb); if (unlikely(net_xmit_eval(err))) dev->stats.tx_errors++; -- 2.25.1

2 1

[PATCH OLK-6.6 v2 0/4] CVE-2025-38099
by Pu Lehui 07 Jul '25

07 Jul '25

Pedro Nishiyama (4): Bluetooth: Add quirk for broken READ_VOICE_SETTING Bluetooth: Add quirk for broken READ_PAGE_SCAN_TYPE Bluetooth: Disable SCO support if READ_VOICE_SETTING is unsupported/broken Bluetooth: btusb: Fix regression in the initialization of fake Bluetooth controllers drivers/bluetooth/btusb.c | 2 ++ include/net/bluetooth/hci.h | 16 ++++++++++++++++ include/net/bluetooth/hci_core.h | 4 ++++ net/bluetooth/hci_event.c | 3 +++ net/bluetooth/hci_sync.c | 6 +++++- 5 files changed, 30 insertions(+), 1 deletion(-) -- 2.34.1

2 5

[PATCH OLK-6.6] crypto: null - Use spin lock instead of mutex
by Gu Bowen 07 Jul '25

07 Jul '25

From: Herbert Xu <herbert(a)gondor.apana.org.au> stable inclusion from stable-6.6.89 commit 1b66a5920b7fc7cc6251192a3fcad115b6d75dd5 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IC6BKL CVE: CVE-2025-37808 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit dcc47a028c24e793ce6d6efebfef1a1e92f80297 ] As the null algorithm may be freed in softirq context through af_alg, use spin locks instead of mutexes to protect the default null algorithm. Reported-by: syzbot+b3e02953598f447d4d2a(a)syzkaller.appspotmail.com Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Gu Bowen <gubowen5(a)huawei.com> --- crypto/crypto_null.c | 39 ++++++++++++++++++++++++++------------- 1 file changed, 26 insertions(+), 13 deletions(-) diff --git a/crypto/crypto_null.c b/crypto/crypto_null.c index 5b84b0f7cc17..337867028653 100644 --- a/crypto/crypto_null.c +++ b/crypto/crypto_null.c @@ -17,10 +17,10 @@ #include <crypto/internal/skcipher.h> #include <linux/init.h> #include <linux/module.h> -#include <linux/mm.h> +#include <linux/spinlock.h> #include <linux/string.h> -static DEFINE_MUTEX(crypto_default_null_skcipher_lock); +static DEFINE_SPINLOCK(crypto_default_null_skcipher_lock); static struct crypto_sync_skcipher *crypto_default_null_skcipher; static int crypto_default_null_skcipher_refcnt; @@ -152,23 +152,32 @@ MODULE_ALIAS_CRYPTO("cipher_null"); struct crypto_sync_skcipher *crypto_get_default_null_skcipher(void) { + struct crypto_sync_skcipher *ntfm = NULL; struct crypto_sync_skcipher *tfm; - mutex_lock(&crypto_default_null_skcipher_lock); + spin_lock_bh(&crypto_default_null_skcipher_lock); tfm = crypto_default_null_skcipher; if (!tfm) { - tfm = crypto_alloc_sync_skcipher("ecb(cipher_null)", 0, 0); - if (IS_ERR(tfm)) - goto unlock; - - crypto_default_null_skcipher = tfm; + spin_unlock_bh(&crypto_default_null_skcipher_lock); + + ntfm = crypto_alloc_sync_skcipher("ecb(cipher_null)", 0, 0); + if (IS_ERR(ntfm)) + return ntfm; + + spin_lock_bh(&crypto_default_null_skcipher_lock); + tfm = crypto_default_null_skcipher; + if (!tfm) { + tfm = ntfm; + ntfm = NULL; + crypto_default_null_skcipher = tfm; + } } crypto_default_null_skcipher_refcnt++; + spin_unlock_bh(&crypto_default_null_skcipher_lock); -unlock: - mutex_unlock(&crypto_default_null_skcipher_lock); + crypto_free_sync_skcipher(ntfm); return tfm; } @@ -176,12 +185,16 @@ EXPORT_SYMBOL_GPL(crypto_get_default_null_skcipher); void crypto_put_default_null_skcipher(void) { - mutex_lock(&crypto_default_null_skcipher_lock); + struct crypto_sync_skcipher *tfm = NULL; + + spin_lock_bh(&crypto_default_null_skcipher_lock); if (!--crypto_default_null_skcipher_refcnt) { - crypto_free_sync_skcipher(crypto_default_null_skcipher); + tfm = crypto_default_null_skcipher; crypto_default_null_skcipher = NULL; } - mutex_unlock(&crypto_default_null_skcipher_lock); + spin_unlock_bh(&crypto_default_null_skcipher_lock); + + crypto_free_sync_skcipher(tfm); } EXPORT_SYMBOL_GPL(crypto_put_default_null_skcipher); -- 2.25.1

2 1

[PATCH OLK-6.6 0/4] CVE-2025-38099
by Pu Lehui 07 Jul '25

07 Jul '25

Pedro Nishiyama (4): Bluetooth: Add quirk for broken READ_VOICE_SETTING Bluetooth: Add quirk for broken READ_PAGE_SCAN_TYPE Bluetooth: Disable SCO support if READ_VOICE_SETTING is unsupported/broken Bluetooth: btusb: Fix regression in the initialization of fake Bluetooth controllers drivers/bluetooth/btusb.c | 2 ++ include/net/bluetooth/hci.h | 16 ++++++++++++++++ include/net/bluetooth/hci_core.h | 4 ++++ net/bluetooth/hci_event.c | 3 +++ net/bluetooth/hci_sync.c | 6 +++++- 5 files changed, 30 insertions(+), 1 deletion(-) -- 2.34.1

2 5

[PATCH OLK-6.6] bpf: Check rcu_read_lock_trace_held() in bpf_map_lookup_percpu_elem()
by Liu Chuang 07 Jul '25

07 Jul '25

From: Hou Tao <houtao1(a)huawei.com> stable inclusion from stable-v6.6.95 commit 7bf4461f1c97207fda757014690d55a447ce859f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICK4OG CVE: CVE-2025-38022 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit d4965578267e2e81f67c86e2608481e77e9c8569 ] bpf_map_lookup_percpu_elem() helper is also available for sleepable bpf program. When BPF JIT is disabled or under 32-bit host, bpf_map_lookup_percpu_elem() will not be inlined. Using it in a sleepable bpf program will trigger the warning in bpf_map_lookup_percpu_elem(), because the bpf program only holds rcu_read_lock_trace lock. Therefore, add the missed check. Reported-by: syzbot+dce5aae19ae4d6399986(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/bpf/000000000000176a130617420310@google.com/ Signed-off-by: Hou Tao <houtao1(a)huawei.com> Link: https://lore.kernel.org/r/20250526062534.1105938-1-houtao@huaweicloud.com Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Chuang <liuchuang40(a)huawei.com> --- kernel/bpf/helpers.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c index 140097c8198e..643d2bf15c20 100644 --- a/kernel/bpf/helpers.c +++ b/kernel/bpf/helpers.c @@ -128,7 +128,8 @@ const struct bpf_func_proto bpf_map_peek_elem_proto = { BPF_CALL_3(bpf_map_lookup_percpu_elem, struct bpf_map *, map, void *, key, u32, cpu) { - WARN_ON_ONCE(!rcu_read_lock_held() && !rcu_read_lock_bh_held()); + WARN_ON_ONCE(!rcu_read_lock_held() && !rcu_read_lock_trace_held() && + !rcu_read_lock_bh_held()); return (unsigned long) map->ops->map_lookup_percpu_elem(map, key, cpu); } -- 2.34.1

2 1