- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] nsh: Restore skb->{protocol,data,mac_header} for outer header in nsh_gso_segment().
by Ziyang Xuan 09 Jun '24

09 Jun '24

From: Kuniyuki Iwashima <kuniyu(a)amazon.com> stable inclusion from stable-v5.10.217 commit bbccf0caef2fa917d6d0692385a06ce3c262a216 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9U8MH CVE: CVE-2024-36933 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 4b911a9690d72641879ea6d13cce1de31d346d79 ] syzbot triggered various splats (see [0] and links) by a crafted GSO packet of VIRTIO_NET_HDR_GSO_UDP layering the following protocols: ETH_P_8021AD + ETH_P_NSH + ETH_P_IPV6 + IPPROTO_UDP NSH can encapsulate IPv4, IPv6, Ethernet, NSH, and MPLS. As the inner protocol can be Ethernet, NSH GSO handler, nsh_gso_segment(), calls skb_mac_gso_segment() to invoke inner protocol GSO handlers. nsh_gso_segment() does the following for the original skb before calling skb_mac_gso_segment() 1. reset skb->network_header 2. save the original skb->{mac_heaeder,mac_len} in a local variable 3. pull the NSH header 4. resets skb->mac_header 5. set up skb->mac_len and skb->protocol for the inner protocol. and does the following for the segmented skb 6. set ntohs(ETH_P_NSH) to skb->protocol 7. push the NSH header 8. restore skb->mac_header 9. set skb->mac_header + mac_len to skb->network_header 10. restore skb->mac_len There are two problems in 6-7 and 8-9. (a) After 6 & 7, skb->data points to the NSH header, so the outer header (ETH_P_8021AD in this case) is stripped when skb is sent out of netdev. Also, if NSH is encapsulated by NSH + Ethernet (so NSH-Ethernet-NSH), skb_pull() in the first nsh_gso_segment() will make skb->data point to the middle of the outer NSH or Ethernet header because the Ethernet header is not pulled by the second nsh_gso_segment(). (b) While restoring skb->{mac_header,network_header} in 8 & 9, nsh_gso_segment() does not assume that the data in the linear buffer is shifted. However, udp6_ufo_fragment() could shift the data and change skb->mac_header accordingly as demonstrated by syzbot. If this happens, even the restored skb->mac_header points to the middle of the outer header. It seems nsh_gso_segment() has never worked with outer headers so far. At the end of nsh_gso_segment(), the outer header must be restored for the segmented skb, instead of the NSH header. To do that, let's calculate the outer header position relatively from the inner header and set skb->{data,mac_header,protocol} properly. [0]: BUG: KMSAN: uninit-value in ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline] BUG: KMSAN: uninit-value in ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] BUG: KMSAN: uninit-value in ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668 ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668 ipvlan_start_xmit+0x5c/0x1a0 drivers/net/ipvlan/ipvlan_main.c:222 __netdev_start_xmit include/linux/netdevice.h:4989 [inline] netdev_start_xmit include/linux/netdevice.h:5003 [inline] xmit_one net/core/dev.c:3547 [inline] dev_hard_start_xmit+0x244/0xa10 net/core/dev.c:3563 __dev_queue_xmit+0x33ed/0x51c0 net/core/dev.c:4351 dev_queue_xmit include/linux/netdevice.h:3171 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook mm/slub.c:3819 [inline] slab_alloc_node mm/slub.c:3860 [inline] __do_kmalloc_node mm/slub.c:3980 [inline] __kmalloc_node_track_caller+0x705/0x1000 mm/slub.c:4001 kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582 __alloc_skb+0x352/0x790 net/core/skbuff.c:651 skb_segment+0x20aa/0x7080 net/core/skbuff.c:4647 udp6_ufo_fragment+0xcab/0x1150 net/ipv6/udp_offload.c:109 ipv6_gso_segment+0x14be/0x2ca0 net/ipv6/ip6_offload.c:152 skb_mac_gso_segment+0x3e8/0x760 net/core/gso.c:53 nsh_gso_segment+0x6f4/0xf70 net/nsh/nsh.c:108 skb_mac_gso_segment+0x3e8/0x760 net/core/gso.c:53 __skb_gso_segment+0x4b0/0x730 net/core/gso.c:124 skb_gso_segment include/net/gso.h:83 [inline] validate_xmit_skb+0x107f/0x1930 net/core/dev.c:3628 __dev_queue_xmit+0x1f28/0x51c0 net/core/dev.c:4343 dev_queue_xmit include/linux/netdevice.h:3171 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b CPU: 1 PID: 5101 Comm: syz-executor421 Not tainted 6.8.0-rc5-syzkaller-00297-gf2e367d6ad3b #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Fixes: c411ed854584 ("nsh: add GSO support") Reported-and-tested-by: syzbot+42a0dc856239de4de60e(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=42a0dc856239de4de60e Reported-and-tested-by: syzbot+c298c9f0e46a3c86332b(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c298c9f0e46a3c86332b Link: https://lore.kernel.org/netdev/20240415222041.18537-1-kuniyu@amazon.com/ Signed-off-by: Kuniyuki Iwashima <kuniyu(a)amazon.com> Link: https://lore.kernel.org/r/20240424023549.21862-1-kuniyu@amazon.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Ziyang Xuan <william.xuanziyang(a)huawei.com> --- net/nsh/nsh.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/net/nsh/nsh.c b/net/nsh/nsh.c index 0f23e5e8e03eb..3e0fc71d95a14 100644 --- a/net/nsh/nsh.c +++ b/net/nsh/nsh.c @@ -76,13 +76,15 @@ EXPORT_SYMBOL_GPL(nsh_pop); static struct sk_buff *nsh_gso_segment(struct sk_buff *skb, netdev_features_t features) { + unsigned int outer_hlen, mac_len, nsh_len; struct sk_buff *segs = ERR_PTR(-EINVAL); u16 mac_offset = skb->mac_header; - unsigned int nsh_len, mac_len; - __be16 proto; + __be16 outer_proto, proto; skb_reset_network_header(skb); + outer_proto = skb->protocol; + outer_hlen = skb_mac_header_len(skb); mac_len = skb->mac_len; if (unlikely(!pskb_may_pull(skb, NSH_BASE_HDR_LEN))) @@ -112,10 +114,10 @@ static struct sk_buff *nsh_gso_segment(struct sk_buff *skb, } for (skb = segs; skb; skb = skb->next) { - skb->protocol = htons(ETH_P_NSH); - __skb_push(skb, nsh_len); - skb->mac_header = mac_offset; - skb->network_header = skb->mac_header + mac_len; + skb->protocol = outer_proto; + __skb_push(skb, nsh_len + outer_hlen); + skb_reset_mac_header(skb); + skb_set_network_header(skb, outer_hlen); skb->mac_len = mac_len; } -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1 0/2] CVE-2024-36933
by Ziyang Xuan 09 Jun '24

09 Jun '24

Patchset of CVE-2024-36933. Dong Chenchen (1): net: nsh: Use correct mac_offset to unwind gso skb in nsh_gso_segment() Kuniyuki Iwashima (1): nsh: Restore skb->{protocol,data,mac_header} for outer header in nsh_gso_segment(). net/nsh/nsh.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) -- 2.25.1

2 3

[PATCH OLK-6.6 V1] scsi: lpfc: Move NPIV's transport unregistration to after resource clean up
by Cheng Yu 09 Jun '24

09 Jun '24

From: Justin Tee <justin.tee(a)broadcom.com> mainline inclusion from mainline-v6.9-rc2 commit 4ddf01f2f1504fa08b766e8cfeec558e9f8eef6c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9UMD0 CVE: CVE-2024-36952 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- There are cases after NPIV deletion where the fabric switch still believes the NPIV is logged into the fabric. This occurs when a vport is unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the fabric. Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including the fabric D_ID, removes the last ndlp reference and frees the ndlp rport object. This sometimes causes the race condition where the final DA_ID and LOGO are skipped from being sent to the fabric switch. Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID and LOGO are sent. Signed-off-by: Justin Tee <justin.tee(a)broadcom.com> Link: https://lore.kernel.org/r/20240305200503.57317-3-justintee8345@gmail.com Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Cheng Yu <serein.chengyu(a)huawei.com> --- drivers/scsi/lpfc/lpfc_vport.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_vport.c b/drivers/scsi/lpfc/lpfc_vport.c index 6c7559cf1a4b..9e0e9e02d2c4 100644 --- a/drivers/scsi/lpfc/lpfc_vport.c +++ b/drivers/scsi/lpfc/lpfc_vport.c @@ -683,10 +683,6 @@ lpfc_vport_delete(struct fc_vport *fc_vport) lpfc_free_sysfs_attr(vport); lpfc_debugfs_terminate(vport); - /* Remove FC host to break driver binding. */ - fc_remove_host(shost); - scsi_remove_host(shost); - /* Send the DA_ID and Fabric LOGO to cleanup Nameserver entries. */ ndlp = lpfc_findnode_did(vport, Fabric_DID); if (!ndlp) @@ -730,6 +726,10 @@ lpfc_vport_delete(struct fc_vport *fc_vport) skip_logo: + /* Remove FC host to break driver binding. */ + fc_remove_host(shost); + scsi_remove_host(shost); + lpfc_cleanup(vport); /* Remove scsi host now. The nodes are cleaned up. */ -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1 V1] scsi: lpfc: Move NPIV's transport unregistration to after resource clean up
by Cheng Yu 09 Jun '24

09 Jun '24

From: Justin Tee <justin.tee(a)broadcom.com> mainline inclusion from mainline-v6.9-rc2 commit 4ddf01f2f1504fa08b766e8cfeec558e9f8eef6c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9UMD0 CVE: CVE-2024-36952 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- There are cases after NPIV deletion where the fabric switch still believes the NPIV is logged into the fabric. This occurs when a vport is unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the fabric. Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including the fabric D_ID, removes the last ndlp reference and frees the ndlp rport object. This sometimes causes the race condition where the final DA_ID and LOGO are skipped from being sent to the fabric switch. Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID and LOGO are sent. Signed-off-by: Justin Tee <justin.tee(a)broadcom.com> Link: https://lore.kernel.org/r/20240305200503.57317-3-justintee8345@gmail.com Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Conflicts: drivers/scsi/lpfc/lpfc_vport.c [There are only context conficts, no code logic conflicts.] Signed-off-by: Cheng Yu <serein.chengyu(a)huawei.com> --- drivers/scsi/lpfc/lpfc_vport.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_vport.c b/drivers/scsi/lpfc/lpfc_vport.c index aa4e451d5dc1..02871d73a502 100644 --- a/drivers/scsi/lpfc/lpfc_vport.c +++ b/drivers/scsi/lpfc/lpfc_vport.c @@ -668,10 +668,6 @@ lpfc_vport_delete(struct fc_vport *fc_vport) ns_ndlp_referenced = true; } - /* Remove FC host and then SCSI host with the vport */ - fc_remove_host(shost); - scsi_remove_host(shost); - ndlp = lpfc_findnode_did(phba->pport, Fabric_DID); /* In case of driver unload, we shall not perform fabric logo as the @@ -774,6 +770,10 @@ lpfc_vport_delete(struct fc_vport *fc_vport) skip_logo: + /* Remove FC host and then SCSI host with the vport */ + fc_remove_host(shost); + scsi_remove_host(shost); + /* * If the NameServer ndlp has been incremented to allow the DA_ID CT * command to be sent, decrement the ndlp now. -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS V1] scsi: lpfc: Move NPIV's transport unregistration to after resource clean up
by Cheng Yu 09 Jun '24

09 Jun '24

From: Justin Tee <justin.tee(a)broadcom.com> mainline inclusion from mainline-v6.9-rc2 commit 4ddf01f2f1504fa08b766e8cfeec558e9f8eef6c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9UMD0 CVE: CVE-2024-36952 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- There are cases after NPIV deletion where the fabric switch still believes the NPIV is logged into the fabric. This occurs when a vport is unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the fabric. Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including the fabric D_ID, removes the last ndlp reference and frees the ndlp rport object. This sometimes causes the race condition where the final DA_ID and LOGO are skipped from being sent to the fabric switch. Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID and LOGO are sent. Signed-off-by: Justin Tee <justin.tee(a)broadcom.com> Link: https://lore.kernel.org/r/20240305200503.57317-3-justintee8345@gmail.com Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Conflicts: drivers/scsi/lpfc/lpfc_vport.c [There are only context conficts, no code logic conflicts.] Signed-off-by: Cheng Yu <serein.chengyu(a)huawei.com> --- drivers/scsi/lpfc/lpfc_vport.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_vport.c b/drivers/scsi/lpfc/lpfc_vport.c index 1ff0f7de9105..0b60ae657030 100644 --- a/drivers/scsi/lpfc/lpfc_vport.c +++ b/drivers/scsi/lpfc/lpfc_vport.c @@ -690,10 +690,6 @@ lpfc_vport_delete(struct fc_vport *fc_vport) ns_ndlp_referenced = true; } - /* Remove FC host and then SCSI host with the vport */ - fc_remove_host(shost); - scsi_remove_host(shost); - ndlp = lpfc_findnode_did(phba->pport, Fabric_DID); /* In case of driver unload, we shall not perform fabric logo as the @@ -796,6 +792,10 @@ lpfc_vport_delete(struct fc_vport *fc_vport) skip_logo: + /* Remove FC host and then SCSI host with the vport */ + fc_remove_host(shost); + scsi_remove_host(shost); + /* * If the NameServer ndlp has been incremented to allow the DA_ID CT * command to be sent, decrement the ndlp now. -- 2.25.1

2 1

[PATCH OLK-5.10 V1] scsi: lpfc: Move NPIV's transport unregistration to after resource clean up
by Cheng Yu 09 Jun '24

09 Jun '24

From: Justin Tee <justin.tee(a)broadcom.com> mainline inclusion from mainline-v6.9-rc2 commit 4ddf01f2f1504fa08b766e8cfeec558e9f8eef6c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9UMD0 CVE: CVE-2024-36952 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- There are cases after NPIV deletion where the fabric switch still believes the NPIV is logged into the fabric. This occurs when a vport is unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the fabric. Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including the fabric D_ID, removes the last ndlp reference and frees the ndlp rport object. This sometimes causes the race condition where the final DA_ID and LOGO are skipped from being sent to the fabric switch. Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID and LOGO are sent. Signed-off-by: Justin Tee <justin.tee(a)broadcom.com> Link: https://lore.kernel.org/r/20240305200503.57317-3-justintee8345@gmail.com Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Conflicts: drivers/scsi/lpfc/lpfc_vport.c [There are only context conficts, no code logic conflicts.] Signed-off-by: Cheng Yu <serein.chengyu(a)huawei.com> --- drivers/scsi/lpfc/lpfc_vport.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_vport.c b/drivers/scsi/lpfc/lpfc_vport.c index aa4e451d5dc1..02871d73a502 100644 --- a/drivers/scsi/lpfc/lpfc_vport.c +++ b/drivers/scsi/lpfc/lpfc_vport.c @@ -668,10 +668,6 @@ lpfc_vport_delete(struct fc_vport *fc_vport) ns_ndlp_referenced = true; } - /* Remove FC host and then SCSI host with the vport */ - fc_remove_host(shost); - scsi_remove_host(shost); - ndlp = lpfc_findnode_did(phba->pport, Fabric_DID); /* In case of driver unload, we shall not perform fabric logo as the @@ -774,6 +770,10 @@ lpfc_vport_delete(struct fc_vport *fc_vport) skip_logo: + /* Remove FC host and then SCSI host with the vport */ + fc_remove_host(shost); + scsi_remove_host(shost); + /* * If the NameServer ndlp has been incremented to allow the DA_ID CT * command to be sent, decrement the ndlp now. -- 2.25.1

2 1

[PATCH OLK-5.10] cvm_tsi: enhance security for cvm tsi
by Shengjie Li 09 Jun '24

09 Jun '24

virtcca inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9Q85J -------------------------------- enhance security for Confidential cVM tsi: Signed-off-by: Shengjie Li <lishengjie12(a)huawei.com> --- arch/arm64/include/asm/cvm_smc.h | 22 +++---- arch/arm64/include/uapi/asm/cvm_tsi.h | 11 ++-- arch/arm64/kernel/cvm_tsi.c | 89 ++++++++++++++------------- 3 files changed, 64 insertions(+), 58 deletions(-) diff --git a/arch/arm64/include/asm/cvm_smc.h b/arch/arm64/include/asm/cvm_smc.h index c4d56333e3..91688bc169 100644 --- a/arch/arm64/include/asm/cvm_smc.h +++ b/arch/arm64/include/asm/cvm_smc.h @@ -124,30 +124,30 @@ static inline unsigned long tsi_measurement_read(struct cvm_measurement *cvm_mea return res.a0; } -static inline unsigned long tsi_attestation_token_init(struct cvm_attestation_cmd *attest_cmd) +static inline unsigned long tsi_attestation_token_init(unsigned char *challenge) { struct arm_smccc_res res; - unsigned char *challenge; + unsigned char *buf; - challenge = kmalloc(CHALLENGE_SIZE, GFP_KERNEL); - if (!challenge) + buf = kmalloc(CHALLENGE_SIZE, GFP_KERNEL); + if (!buf) return -ENOMEM; - memcpy(challenge, attest_cmd->challenge, CHALLENGE_SIZE); + memcpy(buf, challenge, CHALLENGE_SIZE); - arm_smccc_1_1_smc(SMC_TSI_ATTESTATION_TOKEN_INIT, virt_to_phys(challenge), &res); - kfree(challenge); + arm_smccc_1_1_smc(SMC_TSI_ATTESTATION_TOKEN_INIT, virt_to_phys(buf), &res); + kfree(buf); return res.a0; } -static inline unsigned long tsi_attestation_token_continue(struct cvm_attestation_cmd *attest_cmd) +static inline unsigned long tsi_attestation_token_continue(struct cvm_token_granule *token_granule) { struct arm_smccc_res res; - arm_smccc_1_1_smc(SMC_TSI_ATTESTATION_TOKEN_CONTINUE, virt_to_phys(attest_cmd->granule_ipa), - attest_cmd->offset, attest_cmd->size, &res); + arm_smccc_1_1_smc(SMC_TSI_ATTESTATION_TOKEN_CONTINUE, virt_to_phys(token_granule->ipa), + token_granule->offset, token_granule->size, &res); - attest_cmd->num_wr_bytes = res.a1; + token_granule->num_wr_bytes = res.a1; return res.a0; } diff --git a/arch/arm64/include/uapi/asm/cvm_tsi.h b/arch/arm64/include/uapi/asm/cvm_tsi.h index 43e17a0da0..1ed4386db2 100644 --- a/arch/arm64/include/uapi/asm/cvm_tsi.h +++ b/arch/arm64/include/uapi/asm/cvm_tsi.h @@ -55,10 +55,13 @@ struct cvm_measurement_extend { struct cvm_attestation_cmd { unsigned char challenge[CHALLENGE_SIZE]; /* input: challenge value */ - unsigned long token_size; /* return: challenge value */ - void *granule_head; - void *granule_ipa; /* IPA of the Granule to which the token will be written */ - unsigned long granule_count; + unsigned long token_size; /* return: token size */ +}; + +struct cvm_token_granule { + void *head; + void *ipa; /* IPA of the Granule to which the token will be written */ + unsigned long count; unsigned long offset; /* Offset within Granule to start of buffer in bytes */ unsigned long size; /* Size of buffer in bytes */ unsigned long num_wr_bytes; /* Number of bytes written to buffer */ diff --git a/arch/arm64/kernel/cvm_tsi.c b/arch/arm64/kernel/cvm_tsi.c index b48e5b17f4..252fe5352a 100644 --- a/arch/arm64/kernel/cvm_tsi.c +++ b/arch/arm64/kernel/cvm_tsi.c @@ -4,6 +4,7 @@ #include <linux/slab.h> #include <linux/miscdevice.h> #include <linux/preempt.h> +#include <asm/cvm_guest.h> #include <asm/cvm_smc.h> #include <asm/cvm_tsi.h> @@ -16,20 +17,19 @@ struct attestation_token { static struct attestation_token token; +static DEFINE_SPINLOCK(lock); + static long tmm_tsi_ioctl(struct file *file, unsigned int cmd, unsigned long arg); -static int tmm_tsi_release(struct inode *inode, struct file *file); static ssize_t tmm_token_read(struct file *file, char __user *user_buffer, size_t size, loff_t *offset); static int tmm_get_tsi_version(struct cvm_tsi_version __user *arg); -static int tmm_get_attestation_token(struct cvm_attestation_cmd __user *arg, - struct attestation_token *attest_token); +static int tmm_get_attestation_token(struct cvm_attestation_cmd __user *arg); static int tmm_get_device_cert(struct cca_device_cert __user *arg); static const struct file_operations tmm_tsi_fops = { .owner = THIS_MODULE, .read = tmm_token_read, - .release = tmm_tsi_release, .unlocked_ioctl = tmm_tsi_ioctl }; @@ -44,6 +44,9 @@ static int __init tmm_tsi_init(void) unsigned long ver; int ret; + if (!is_cvm_world()) + return -EIO; + ver = tsi_get_version(); if (ver == SMCCC_RET_NOT_SUPPORTED) { pr_err("tmm_tsi: SMC return not supported!\n"); @@ -56,6 +59,11 @@ static int __init tmm_tsi_init(void) return ret; } + /* Allocate a large memory */ + token.buf = kmalloc(GRANULE_SIZE * MAX_TOKEN_GRANULE_PAGE, GFP_KERNEL); + if (!token.buf) + return -ENOMEM; + pr_warn("tmm_tsi: module loaded (version %lu.%lu).\n", TSI_ABI_VERSION_GET_MAJOR(ver), TSI_ABI_VERSION_GET_MINOR(ver)); @@ -65,8 +73,10 @@ static int __init tmm_tsi_init(void) static void __exit tmm_tsi_exit(void) { - if (token.buf != NULL) + if (token.buf != NULL) { + memset(token.buf, 0, GRANULE_SIZE * MAX_TOKEN_GRANULE_PAGE); kfree(token.buf); + } misc_deregister(&ioctl_dev); pr_warn("tmm_tsi: module unloaded.\n"); } @@ -80,7 +90,7 @@ static long tmm_tsi_ioctl(struct file *file, unsigned int cmd, unsigned long arg ret = tmm_get_tsi_version((struct cvm_tsi_version *)arg); break; case TMM_GET_ATTESTATION_TOKEN: - ret = tmm_get_attestation_token((struct cvm_attestation_cmd *)arg, &token); + ret = tmm_get_attestation_token((struct cvm_attestation_cmd *)arg); break; case TMM_GET_DEVICE_CERT: ret = tmm_get_device_cert((struct cca_device_cert *)arg); @@ -99,28 +109,25 @@ static ssize_t tmm_token_read(struct file *file, char __user *user_buffer, int ret; int to_copy; - if (*offset >= token.size) + spin_lock(&lock); + if (*offset >= token.size) { + spin_unlock(&lock); return 0; + } to_copy = min((int)size, (int)(token.size - *offset)); ret = copy_to_user(user_buffer, token.buf + *offset, to_copy); if (ret) { pr_err("tmm_tsi: copy token to user failed (%d)!\n", ret); + spin_unlock(&lock); return -1; } *offset += to_copy; + spin_unlock(&lock); return to_copy; } -static int tmm_tsi_release(struct inode *inode, struct file *file) -{ - if (token.buf != NULL) { - memset(token.buf, 0, GRANULE_SIZE * MAX_TOKEN_GRANULE_PAGE); - kfree(token.buf); - } - return 0; -} static int tmm_get_tsi_version(struct cvm_tsi_version __user *arg) { @@ -141,65 +148,61 @@ static int tmm_get_tsi_version(struct cvm_tsi_version __user *arg) return 0; } -static int tmm_get_attestation_token(struct cvm_attestation_cmd __user *arg, - struct attestation_token *attest_token) +static int tmm_get_attestation_token(struct cvm_attestation_cmd __user *arg) { unsigned long ret; - struct cvm_attestation_cmd cmd = {0}; + struct cvm_token_granule token_granule = {0}; + unsigned char challenge[CHALLENGE_SIZE]; - ret = copy_from_user(&(cmd.challenge), &(arg->challenge), sizeof(cmd.challenge)); + ret = copy_from_user(challenge, &(arg->challenge), CHALLENGE_SIZE); if (ret) { pr_err("tmm_tsi: copy data from user failed (%lu)!\n", ret); return -EFAULT; } - /* Allocate a large memory */ - attest_token->buf = kmalloc(GRANULE_SIZE * MAX_TOKEN_GRANULE_PAGE, GFP_KERNEL); - if (!attest_token->buf) - return -ENOMEM; - cmd.granule_head = attest_token->buf; - cmd.granule_ipa = cmd.granule_head; + spin_lock(&lock); + token_granule.head = token.buf; + token_granule.ipa = token_granule.head; - /* preempt_disable(); */ - - ret = tsi_attestation_token_init(&cmd); + ret = tsi_attestation_token_init(challenge); if (ret) { pr_err("tmm_tsi: tsi call tsi_attestation_token_init failed (%lu)!\n", ret); + spin_unlock(&lock); return -EIO; } do { /* Retrieve one Granule of data per loop iteration */ - cmd.granule_ipa = cmd.granule_head + - (unsigned long)(cmd.granule_count * GRANULE_SIZE); - cmd.offset = 0; + token_granule.ipa = token_granule.head + + (unsigned long)(token_granule.count * GRANULE_SIZE); + token_granule.offset = 0; do { /* Retrieve sub-Granule chunk of data per loop iteration */ - cmd.size = GRANULE_SIZE - cmd.offset; - ret = tsi_attestation_token_continue(&cmd); - cmd.offset += cmd.num_wr_bytes; - } while (ret == TSI_INCOMPLETE && cmd.offset < GRANULE_SIZE); + token_granule.size = GRANULE_SIZE - token_granule.offset; + ret = tsi_attestation_token_continue(&token_granule); + token_granule.offset += token_granule.num_wr_bytes; + } while (ret == TSI_INCOMPLETE && token_granule.offset < GRANULE_SIZE); - cmd.granule_count += 1; - if (cmd.granule_count >= MAX_TOKEN_GRANULE_PAGE && ret == TSI_INCOMPLETE) { + token_granule.count += 1; + if (token_granule.count >= MAX_TOKEN_GRANULE_PAGE && ret == TSI_INCOMPLETE) { pr_err("tmm_tsi: macro MAX_TOKEN_GRANULE_PAGE (%d) is too small!\n", MAX_TOKEN_GRANULE_PAGE); + spin_unlock(&lock); return -ENOMEM; } } while (ret == TSI_INCOMPLETE); - /* preempt_enable(); */ - /* Send to user space the total size of the token */ - cmd.granule_count = cmd.granule_count - 1; - cmd.token_size = (unsigned long)(GRANULE_SIZE * cmd.granule_count) + cmd.offset; - attest_token->size = cmd.token_size; + token_granule.count = token_granule.count - 1; + token.size = (unsigned long)(GRANULE_SIZE * token_granule.count) + token_granule.offset; - ret = copy_to_user(&(arg->token_size), &(cmd.token_size), sizeof(cmd.token_size)); + ret = copy_to_user(&(arg->token_size), &(token.size), sizeof(token.size)); if (ret) { pr_err("tmm_tsi: copy data to user failed (%lu)!\n", ret); + spin_unlock(&lock); return -EFAULT; } + spin_unlock(&lock); return 0; } -- 2.37.2.windows.2

2 1

[PATCH openEuler-22.03-LTS-SP1] net: core: reject skb_copy(_expand) for fraglist GSO skbs
by Ziyang Xuan 09 Jun '24

09 Jun '24

From: Felix Fietkau <nbd(a)nbd.name> stable inclusion from stable-v5.10.217 commit faa83a7797f06cefed86731ba4baa3b4dfdc06c1 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9U9P7 CVE: CVE-2024-36929 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit d091e579b864fa790dd6a0cd537a22c383126681 ] SKB_GSO_FRAGLIST skbs must not be linearized, otherwise they become invalid. Return NULL if such an skb is passed to skb_copy or skb_copy_expand, in order to prevent a crash on a potential later call to skb_gso_segment. Fixes: 3a1296a38d0c ("net: Support GRO/GSO fraglist chaining.") Signed-off-by: Felix Fietkau <nbd(a)nbd.name> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Ziyang Xuan <william.xuanziyang(a)huawei.com> --- net/core/skbuff.c | 27 +++++++++++++++++++-------- 1 file changed, 19 insertions(+), 8 deletions(-) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 5197b286ef18d..120290a9d2078 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -1534,11 +1534,17 @@ static inline int skb_alloc_rx_flag(const struct sk_buff *skb) struct sk_buff *skb_copy(const struct sk_buff *skb, gfp_t gfp_mask) { - int headerlen = skb_headroom(skb); - unsigned int size = skb_end_offset(skb) + skb->data_len; - struct sk_buff *n = __alloc_skb(size, gfp_mask, - skb_alloc_rx_flag(skb), NUMA_NO_NODE); + struct sk_buff *n; + unsigned int size; + int headerlen; + + if (WARN_ON_ONCE(skb_shinfo(skb)->gso_type & SKB_GSO_FRAGLIST)) + return NULL; + headerlen = skb_headroom(skb); + size = skb_end_offset(skb) + skb->data_len; + n = __alloc_skb(size, gfp_mask, + skb_alloc_rx_flag(skb), NUMA_NO_NODE); if (!n) return NULL; @@ -1799,12 +1805,17 @@ struct sk_buff *skb_copy_expand(const struct sk_buff *skb, /* * Allocate the copy buffer */ - struct sk_buff *n = __alloc_skb(newheadroom + skb->len + newtailroom, - gfp_mask, skb_alloc_rx_flag(skb), - NUMA_NO_NODE); - int oldheadroom = skb_headroom(skb); int head_copy_len, head_copy_off; + struct sk_buff *n; + int oldheadroom; + + if (WARN_ON_ONCE(skb_shinfo(skb)->gso_type & SKB_GSO_FRAGLIST)) + return NULL; + oldheadroom = skb_headroom(skb); + n = __alloc_skb(newheadroom + skb->len + newtailroom, + gfp_mask, skb_alloc_rx_flag(skb), + NUMA_NO_NODE); if (!n) return NULL; -- 2.25.1

2 1

[PATCH OLK-5.10] net: core: reject skb_copy(_expand) for fraglist GSO skbs
by Ziyang Xuan 09 Jun '24

09 Jun '24

From: Felix Fietkau <nbd(a)nbd.name> stable inclusion from stable-v5.10.217 commit faa83a7797f06cefed86731ba4baa3b4dfdc06c1 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9U9P7 CVE: CVE-2024-36929 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit d091e579b864fa790dd6a0cd537a22c383126681 ] SKB_GSO_FRAGLIST skbs must not be linearized, otherwise they become invalid. Return NULL if such an skb is passed to skb_copy or skb_copy_expand, in order to prevent a crash on a potential later call to skb_gso_segment. Fixes: 3a1296a38d0c ("net: Support GRO/GSO fraglist chaining.") Signed-off-by: Felix Fietkau <nbd(a)nbd.name> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Ziyang Xuan <william.xuanziyang(a)huawei.com> --- net/core/skbuff.c | 27 +++++++++++++++++++-------- 1 file changed, 19 insertions(+), 8 deletions(-) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 779a860e00731..de0229b8a920c 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -1540,11 +1540,17 @@ static inline int skb_alloc_rx_flag(const struct sk_buff *skb) struct sk_buff *skb_copy(const struct sk_buff *skb, gfp_t gfp_mask) { - int headerlen = skb_headroom(skb); - unsigned int size = skb_end_offset(skb) + skb->data_len; - struct sk_buff *n = __alloc_skb(size, gfp_mask, - skb_alloc_rx_flag(skb), NUMA_NO_NODE); + struct sk_buff *n; + unsigned int size; + int headerlen; + + if (WARN_ON_ONCE(skb_shinfo(skb)->gso_type & SKB_GSO_FRAGLIST)) + return NULL; + headerlen = skb_headroom(skb); + size = skb_end_offset(skb) + skb->data_len; + n = __alloc_skb(size, gfp_mask, + skb_alloc_rx_flag(skb), NUMA_NO_NODE); if (!n) return NULL; @@ -1856,12 +1862,17 @@ struct sk_buff *skb_copy_expand(const struct sk_buff *skb, /* * Allocate the copy buffer */ - struct sk_buff *n = __alloc_skb(newheadroom + skb->len + newtailroom, - gfp_mask, skb_alloc_rx_flag(skb), - NUMA_NO_NODE); - int oldheadroom = skb_headroom(skb); int head_copy_len, head_copy_off; + struct sk_buff *n; + int oldheadroom; + + if (WARN_ON_ONCE(skb_shinfo(skb)->gso_type & SKB_GSO_FRAGLIST)) + return NULL; + oldheadroom = skb_headroom(skb); + n = __alloc_skb(newheadroom + skb->len + newtailroom, + gfp_mask, skb_alloc_rx_flag(skb), + NUMA_NO_NODE); if (!n) return NULL; -- 2.25.1

2 1

[PATCH OLK-6.6] net: core: reject skb_copy(_expand) for fraglist GSO skbs
by Ziyang Xuan 09 Jun '24

09 Jun '24

From: Felix Fietkau <nbd(a)nbd.name> stable inclusion from stable-v6.6.31 commit cfe34d86ef9765c388f145039006bb79b6c81ac6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9U9P7 CVE: CVE-2024-36929 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit d091e579b864fa790dd6a0cd537a22c383126681 ] SKB_GSO_FRAGLIST skbs must not be linearized, otherwise they become invalid. Return NULL if such an skb is passed to skb_copy or skb_copy_expand, in order to prevent a crash on a potential later call to skb_gso_segment. Fixes: 3a1296a38d0c ("net: Support GRO/GSO fraglist chaining.") Signed-off-by: Felix Fietkau <nbd(a)nbd.name> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Ziyang Xuan <william.xuanziyang(a)huawei.com> --- net/core/skbuff.c | 27 +++++++++++++++++++-------- 1 file changed, 19 insertions(+), 8 deletions(-) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 60876262b3fb3..f0a9ef1aeaa29 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -1971,11 +1971,17 @@ static inline int skb_alloc_rx_flag(const struct sk_buff *skb) struct sk_buff *skb_copy(const struct sk_buff *skb, gfp_t gfp_mask) { - int headerlen = skb_headroom(skb); - unsigned int size = skb_end_offset(skb) + skb->data_len; - struct sk_buff *n = __alloc_skb(size, gfp_mask, - skb_alloc_rx_flag(skb), NUMA_NO_NODE); + struct sk_buff *n; + unsigned int size; + int headerlen; + + if (WARN_ON_ONCE(skb_shinfo(skb)->gso_type & SKB_GSO_FRAGLIST)) + return NULL; + headerlen = skb_headroom(skb); + size = skb_end_offset(skb) + skb->data_len; + n = __alloc_skb(size, gfp_mask, + skb_alloc_rx_flag(skb), NUMA_NO_NODE); if (!n) return NULL; @@ -2303,12 +2309,17 @@ struct sk_buff *skb_copy_expand(const struct sk_buff *skb, /* * Allocate the copy buffer */ - struct sk_buff *n = __alloc_skb(newheadroom + skb->len + newtailroom, - gfp_mask, skb_alloc_rx_flag(skb), - NUMA_NO_NODE); - int oldheadroom = skb_headroom(skb); int head_copy_len, head_copy_off; + struct sk_buff *n; + int oldheadroom; + + if (WARN_ON_ONCE(skb_shinfo(skb)->gso_type & SKB_GSO_FRAGLIST)) + return NULL; + oldheadroom = skb_headroom(skb); + n = __alloc_skb(newheadroom + skb->len + newtailroom, + gfp_mask, skb_alloc_rx_flag(skb), + NUMA_NO_NODE); if (!n) return NULL; -- 2.25.1

2 1

[openeuler:OLK-5.10] BUILD SUCCESS 9e1339f3705f9326a4594db2783ca5d7522d1a9c
by kernel test robot 09 Jun '24

09 Jun '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-5.10 branch HEAD: 9e1339f3705f9326a4594db2783ca5d7522d1a9c !8684 tcp: properly terminate timers for kernel sockets Warning ids grouped by kconfigs: clang_recent_errors `-- x86_64-allnoconfig |-- drivers-arm-spe-spe.c:linux-perf-arm_pmu.h-is-included-more-than-once. |-- drivers-net-ethernet-yunsilicon-xsc-net-main.c:common-qp.h-is-included-more-than-once. |-- drivers-ub-urma-ubcore-ubcore_cdev_file.c:linux-version.h-not-needed. |-- drivers-ub-urma-ubcore-ubcore_device.c:linux-version.h-not-needed. |-- drivers-ub-urma-ubcore-ubcore_genl.c:linux-version.h-not-needed. |-- drivers-ub-urma-ubcore-ubcore_genl_admin.c:linux-version.h-not-needed. |-- drivers-ub-urma-ubcore-ubcore_uvs_cmd.c:ubcore_device.h-is-included-more-than-once. `-- drivers-ub-urma-uburma-uburma_mmap.c:linux-version.h-not-needed. elapsed time: 1237m configs tested: 35 configs skipped: 131 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig clang arm64 allnoconfig gcc arm64 defconfig gcc arm64 randconfig-001-20240609 gcc arm64 randconfig-002-20240609 clang arm64 randconfig-003-20240609 gcc arm64 randconfig-004-20240609 gcc x86_64 allnoconfig clang x86_64 allyesconfig clang x86_64 buildonly-randconfig-001-20240609 clang x86_64 buildonly-randconfig-002-20240609 clang x86_64 buildonly-randconfig-003-20240609 clang x86_64 buildonly-randconfig-004-20240609 gcc x86_64 buildonly-randconfig-005-20240609 clang x86_64 buildonly-randconfig-006-20240609 gcc x86_64 defconfig gcc x86_64 randconfig-001-20240609 gcc x86_64 randconfig-002-20240609 clang x86_64 randconfig-003-20240609 gcc x86_64 randconfig-004-20240609 gcc x86_64 randconfig-005-20240609 clang x86_64 randconfig-006-20240609 clang x86_64 randconfig-011-20240609 gcc x86_64 randconfig-012-20240609 gcc x86_64 randconfig-013-20240609 clang x86_64 randconfig-014-20240609 gcc x86_64 randconfig-015-20240609 clang x86_64 randconfig-016-20240609 gcc x86_64 randconfig-071-20240609 clang x86_64 randconfig-072-20240609 clang x86_64 randconfig-073-20240609 gcc x86_64 randconfig-074-20240609 clang x86_64 randconfig-075-20240609 gcc x86_64 randconfig-076-20240609 gcc x86_64 rhel-8.3-rust clang -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6 V1] drm/vmwgfx: Fix invalid reads in fence signaled events
by Cheng Yu 09 Jun '24

09 Jun '24

From: Zack Rusin <zack.rusin(a)broadcom.com> mainline inclusion from mainline-v6.9-rc7 commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9UNUO CVE: CVE-2024-36960 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Correctly set the length of the drm_event to the size of the structure that's actually used. The length of the drm_event was set to the parent structure instead of to the drm_vmw_event_fence which is supposed to be read. drm_read uses the length parameter to copy the event to the user space thus resuling in oob reads. Signed-off-by: Zack Rusin <zack.rusin(a)broadcom.com> Fixes: 8b7de6aa8468 ("vmwgfx: Rework fence event action") Reported-by: zdi-disclosures(a)trendmicro.com # ZDI-CAN-23566 Cc: David Airlie <airlied(a)gmail.com> CC: Daniel Vetter <daniel(a)ffwll.ch> Cc: Zack Rusin <zack.rusin(a)broadcom.com> Cc: Broadcom internal kernel review list <bcm-kernel-feedback-list(a)broadcom.com> Cc: dri-devel(a)lists.freedesktop.org Cc: linux-kernel(a)vger.kernel.org Cc: <stable(a)vger.kernel.org> # v3.4+ Reviewed-by: Maaz Mombasawala <maaz.mombasawala(a)broadcom.com> Reviewed-by: Martin Krastev <martin.krastev(a)broadcom.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240425192748.1761522-1-zack… Signed-off-by: Cheng Yu <serein.chengyu(a)huawei.com> --- drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c index 2a0cda324703..5efc6a766f64 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c @@ -991,7 +991,7 @@ static int vmw_event_fence_action_create(struct drm_file *file_priv, } event->event.base.type = DRM_VMW_EVENT_FENCE_SIGNALED; - event->event.base.length = sizeof(*event); + event->event.base.length = sizeof(event->event); event->event.user_data = user_data; ret = drm_event_reserve_init(dev, file_priv, &event->base, &event->event.base); -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1 V1] drm/vmwgfx: Fix invalid reads in fence signaled events
by Cheng Yu 09 Jun '24

09 Jun '24

From: Zack Rusin <zack.rusin(a)broadcom.com> mainline inclusion from mainline-v6.9-rc7 commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9UNUO CVE: CVE-2024-36960 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Correctly set the length of the drm_event to the size of the structure that's actually used. The length of the drm_event was set to the parent structure instead of to the drm_vmw_event_fence which is supposed to be read. drm_read uses the length parameter to copy the event to the user space thus resuling in oob reads. Signed-off-by: Zack Rusin <zack.rusin(a)broadcom.com> Fixes: 8b7de6aa8468 ("vmwgfx: Rework fence event action") Reported-by: zdi-disclosures(a)trendmicro.com # ZDI-CAN-23566 Cc: David Airlie <airlied(a)gmail.com> CC: Daniel Vetter <daniel(a)ffwll.ch> Cc: Zack Rusin <zack.rusin(a)broadcom.com> Cc: Broadcom internal kernel review list <bcm-kernel-feedback-list(a)broadcom.com> Cc: dri-devel(a)lists.freedesktop.org Cc: linux-kernel(a)vger.kernel.org Cc: <stable(a)vger.kernel.org> # v3.4+ Reviewed-by: Maaz Mombasawala <maaz.mombasawala(a)broadcom.com> Reviewed-by: Martin Krastev <martin.krastev(a)broadcom.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240425192748.1761522-1-zack… Signed-off-by: Cheng Yu <serein.chengyu(a)huawei.com> --- drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c index 8bc41ec97d71..6bacdb7583df 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c @@ -1066,7 +1066,7 @@ static int vmw_event_fence_action_create(struct drm_file *file_priv, } event->event.base.type = DRM_VMW_EVENT_FENCE_SIGNALED; - event->event.base.length = sizeof(*event); + event->event.base.length = sizeof(event->event); event->event.user_data = user_data; ret = drm_event_reserve_init(dev, file_priv, &event->base, &event->event.base); -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS V1] drm/vmwgfx: Fix invalid reads in fence signaled events
by Cheng Yu 09 Jun '24

09 Jun '24

From: Zack Rusin <zack.rusin(a)broadcom.com> mainline inclusion from mainline-v6.9-rc7 commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9UNUO CVE: CVE-2024-36960 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Correctly set the length of the drm_event to the size of the structure that's actually used. The length of the drm_event was set to the parent structure instead of to the drm_vmw_event_fence which is supposed to be read. drm_read uses the length parameter to copy the event to the user space thus resuling in oob reads. Signed-off-by: Zack Rusin <zack.rusin(a)broadcom.com> Fixes: 8b7de6aa8468 ("vmwgfx: Rework fence event action") Reported-by: zdi-disclosures(a)trendmicro.com # ZDI-CAN-23566 Cc: David Airlie <airlied(a)gmail.com> CC: Daniel Vetter <daniel(a)ffwll.ch> Cc: Zack Rusin <zack.rusin(a)broadcom.com> Cc: Broadcom internal kernel review list <bcm-kernel-feedback-list(a)broadcom.com> Cc: dri-devel(a)lists.freedesktop.org Cc: linux-kernel(a)vger.kernel.org Cc: <stable(a)vger.kernel.org> # v3.4+ Reviewed-by: Maaz Mombasawala <maaz.mombasawala(a)broadcom.com> Reviewed-by: Martin Krastev <martin.krastev(a)broadcom.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240425192748.1761522-1-zack… Signed-off-by: Cheng Yu <serein.chengyu(a)huawei.com> --- drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c index 72a75316d472..e1b4f9612f5a 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c @@ -1064,7 +1064,7 @@ static int vmw_event_fence_action_create(struct drm_file *file_priv, } event->event.base.type = DRM_VMW_EVENT_FENCE_SIGNALED; - event->event.base.length = sizeof(*event); + event->event.base.length = sizeof(event->event); event->event.user_data = user_data; ret = drm_event_reserve_init(dev, file_priv, &event->base, &event->event.base); -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS V1] drm/vmwgfx: Fix invalid reads in fence signaled events
by Cheng Yu 09 Jun '24

09 Jun '24

From: Zack Rusin <zack.rusin(a)broadcom.com> mainline inclusion from mainline-v6.9-rc7 commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9UNUO CVE: CVE-2024-36960 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Correctly set the length of the drm_event to the size of the structure that's actually used. The length of the drm_event was set to the parent structure instead of to the drm_vmw_event_fence which is supposed to be read. drm_read uses the length parameter to copy the event to the user space thus resuling in oob reads. Signed-off-by: Zack Rusin <zack.rusin(a)broadcom.com> Fixes: 8b7de6aa8468 ("vmwgfx: Rework fence event action") Reported-by: zdi-disclosures(a)trendmicro.com # ZDI-CAN-23566 Cc: David Airlie <airlied(a)gmail.com> CC: Daniel Vetter <daniel(a)ffwll.ch> Cc: Zack Rusin <zack.rusin(a)broadcom.com> Cc: Broadcom internal kernel review list <bcm-kernel-feedback-list(a)broadcom.com> Cc: dri-devel(a)lists.freedesktop.org Cc: linux-kernel(a)vger.kernel.org Cc: <stable(a)vger.kernel.org> # v3.4+ Reviewed-by: Maaz Mombasawala <maaz.mombasawala(a)broadcom.com> Reviewed-by: Martin Krastev <martin.krastev(a)broadcom.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240425192748.1761522-1-zack… Signed-off-by: Cheng Yu <serein.chengyu(a)huawei.com> --- drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c index 72a75316d472..e1b4f9612f5a 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c @@ -1064,7 +1064,7 @@ static int vmw_event_fence_action_create(struct drm_file *file_priv, } event->event.base.type = DRM_VMW_EVENT_FENCE_SIGNALED; - event->event.base.length = sizeof(*event); + event->event.base.length = sizeof(event->event); event->event.user_data = user_data; ret = drm_event_reserve_init(dev, file_priv, &event->base, &event->event.base); -- 2.25.1

2 1

[PATCH OLK-6.6] xdp: use flags field to disambiguate broadcast redirect
by Ziyang Xuan 09 Jun '24

09 Jun '24

From: Toke Høiland-Jørgensen <toke(a)redhat.com> stable inclusion from stable-v6.6.31 commit e22e25820fa04ea5eaac4ef7ee200e9923f466a4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9UM46 CVE: CVE-2024-36937 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 5bcf0dcbf9066348058b88a510c57f70f384c92c ] When redirecting a packet using XDP, the bpf_redirect_map() helper will set up the redirect destination information in struct bpf_redirect_info (using the __bpf_xdp_redirect_map() helper function), and the xdp_do_redirect() function will read this information after the XDP program returns and pass the frame on to the right redirect destination. When using the BPF_F_BROADCAST flag to do multicast redirect to a whole map, __bpf_xdp_redirect_map() sets the 'map' pointer in struct bpf_redirect_info to point to the destination map to be broadcast. And xdp_do_redirect() reacts to the value of this map pointer to decide whether it's dealing with a broadcast or a single-value redirect. However, if the destination map is being destroyed before xdp_do_redirect() is called, the map pointer will be cleared out (by bpf_clear_redirect_map()) without waiting for any XDP programs to stop running. This causes xdp_do_redirect() to think that the redirect was to a single target, but the target pointer is also NULL (since broadcast redirects don't have a single target), so this causes a crash when a NULL pointer is passed to dev_map_enqueue(). To fix this, change xdp_do_redirect() to react directly to the presence of the BPF_F_BROADCAST flag in the 'flags' value in struct bpf_redirect_info to disambiguate between a single-target and a broadcast redirect. And only read the 'map' pointer if the broadcast flag is set, aborting if that has been cleared out in the meantime. This prevents the crash, while keeping the atomic (cmpxchg-based) clearing of the map pointer itself, and without adding any more checks in the non-broadcast fast path. Fixes: e624d4ed4aa8 ("xdp: Extend xdp_redirect_map with broadcast support") Reported-and-tested-by: syzbot+af9492708df9797198d6(a)syzkaller.appspotmail.com Signed-off-by: Toke Høiland-Jørgensen <toke(a)redhat.com> Acked-by: Stanislav Fomichev <sdf(a)google.com> Reviewed-by: Hangbin Liu <liuhangbin(a)gmail.com> Acked-by: Jesper Dangaard Brouer <hawk(a)kernel.org> Link: https://lore.kernel.org/r/20240418071840.156411-1-toke@redhat.com Signed-off-by: Martin KaFai Lau <martin.lau(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Ziyang Xuan <william.xuanziyang(a)huawei.com> --- net/core/filter.c | 42 ++++++++++++++++++++++++++++++++---------- 1 file changed, 32 insertions(+), 10 deletions(-) diff --git a/net/core/filter.c b/net/core/filter.c index 81cd6493c7d10..6ec353bf36f38 100644 --- a/net/core/filter.c +++ b/net/core/filter.c @@ -4334,10 +4334,12 @@ static __always_inline int __xdp_do_redirect_frame(struct bpf_redirect_info *ri, enum bpf_map_type map_type = ri->map_type; void *fwd = ri->tgt_value; u32 map_id = ri->map_id; + u32 flags = ri->flags; struct bpf_map *map; int err; ri->map_id = 0; /* Valid map id idr range: [1,INT_MAX[ */ + ri->flags = 0; ri->map_type = BPF_MAP_TYPE_UNSPEC; if (unlikely(!xdpf)) { @@ -4349,11 +4351,20 @@ static __always_inline int __xdp_do_redirect_frame(struct bpf_redirect_info *ri, case BPF_MAP_TYPE_DEVMAP: fallthrough; case BPF_MAP_TYPE_DEVMAP_HASH: - map = READ_ONCE(ri->map); - if (unlikely(map)) { + if (unlikely(flags & BPF_F_BROADCAST)) { + map = READ_ONCE(ri->map); + + /* The map pointer is cleared when the map is being torn + * down by bpf_clear_redirect_map() + */ + if (unlikely(!map)) { + err = -ENOENT; + break; + } + WRITE_ONCE(ri->map, NULL); err = dev_map_enqueue_multi(xdpf, dev, map, - ri->flags & BPF_F_EXCLUDE_INGRESS); + flags & BPF_F_EXCLUDE_INGRESS); } else { err = dev_map_enqueue(fwd, xdpf, dev); } @@ -4416,9 +4427,9 @@ EXPORT_SYMBOL_GPL(xdp_do_redirect_frame); static int xdp_do_generic_redirect_map(struct net_device *dev, struct sk_buff *skb, struct xdp_buff *xdp, - struct bpf_prog *xdp_prog, - void *fwd, - enum bpf_map_type map_type, u32 map_id) + struct bpf_prog *xdp_prog, void *fwd, + enum bpf_map_type map_type, u32 map_id, + u32 flags) { struct bpf_redirect_info *ri = this_cpu_ptr(&bpf_redirect_info); struct bpf_map *map; @@ -4428,11 +4439,20 @@ static int xdp_do_generic_redirect_map(struct net_device *dev, case BPF_MAP_TYPE_DEVMAP: fallthrough; case BPF_MAP_TYPE_DEVMAP_HASH: - map = READ_ONCE(ri->map); - if (unlikely(map)) { + if (unlikely(flags & BPF_F_BROADCAST)) { + map = READ_ONCE(ri->map); + + /* The map pointer is cleared when the map is being torn + * down by bpf_clear_redirect_map() + */ + if (unlikely(!map)) { + err = -ENOENT; + break; + } + WRITE_ONCE(ri->map, NULL); err = dev_map_redirect_multi(dev, skb, xdp_prog, map, - ri->flags & BPF_F_EXCLUDE_INGRESS); + flags & BPF_F_EXCLUDE_INGRESS); } else { err = dev_map_generic_redirect(fwd, skb, xdp_prog); } @@ -4469,9 +4489,11 @@ int xdp_do_generic_redirect(struct net_device *dev, struct sk_buff *skb, enum bpf_map_type map_type = ri->map_type; void *fwd = ri->tgt_value; u32 map_id = ri->map_id; + u32 flags = ri->flags; int err; ri->map_id = 0; /* Valid map id idr range: [1,INT_MAX[ */ + ri->flags = 0; ri->map_type = BPF_MAP_TYPE_UNSPEC; if (map_type == BPF_MAP_TYPE_UNSPEC && map_id == INT_MAX) { @@ -4491,7 +4513,7 @@ int xdp_do_generic_redirect(struct net_device *dev, struct sk_buff *skb, return 0; } - return xdp_do_generic_redirect_map(dev, skb, xdp, xdp_prog, fwd, map_type, map_id); + return xdp_do_generic_redirect_map(dev, skb, xdp, xdp_prog, fwd, map_type, map_id, flags); err: _trace_xdp_redirect_err(dev, xdp_prog, ri->tgt_index, err); return err; -- 2.25.1

2 1

[PATCH OLK-5.10 V1] drm/vmwgfx: Fix invalid reads in fence signaled events
by Cheng Yu 09 Jun '24

09 Jun '24

From: Zack Rusin <zack.rusin(a)broadcom.com> mainline inclusion from mainline-v6.9-rc7 commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9UNUO CVE: CVE-2024-36960 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Correctly set the length of the drm_event to the size of the structure that's actually used. The length of the drm_event was set to the parent structure instead of to the drm_vmw_event_fence which is supposed to be read. drm_read uses the length parameter to copy the event to the user space thus resuling in oob reads. Signed-off-by: Zack Rusin <zack.rusin(a)broadcom.com> Fixes: 8b7de6aa8468 ("vmwgfx: Rework fence event action") Reported-by: zdi-disclosures(a)trendmicro.com # ZDI-CAN-23566 Cc: David Airlie <airlied(a)gmail.com> CC: Daniel Vetter <daniel(a)ffwll.ch> Cc: Zack Rusin <zack.rusin(a)broadcom.com> Cc: Broadcom internal kernel review list <bcm-kernel-feedback-list(a)broadcom.com> Cc: dri-devel(a)lists.freedesktop.org Cc: linux-kernel(a)vger.kernel.org Cc: <stable(a)vger.kernel.org> # v3.4+ Reviewed-by: Maaz Mombasawala <maaz.mombasawala(a)broadcom.com> Reviewed-by: Martin Krastev <martin.krastev(a)broadcom.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240425192748.1761522-1-zack… Signed-off-by: Cheng Yu <serein.chengyu(a)huawei.com> --- drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c index 8bc41ec97d71..6bacdb7583df 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c @@ -1066,7 +1066,7 @@ static int vmw_event_fence_action_create(struct drm_file *file_priv, } event->event.base.type = DRM_VMW_EVENT_FENCE_SIGNALED; - event->event.base.length = sizeof(*event); + event->event.base.length = sizeof(event->event); event->event.user_data = user_data; ret = drm_event_reserve_init(dev, file_priv, &event->base, &event->event.base); -- 2.25.1

2 1

[openeuler:openEuler-1.0-LTS 18952/22827] mm/shmem.c:1601:19: sparse: sparse: invalid assignment: |=
by kernel test robot 09 Jun '24

09 Jun '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 6a98543755cf2f636ae3169f3774d226d328d2cf commit: 3a3a1f75d885bc1d1a25bb753dd2cf9111c457f7 [18952/22827] shmem: Introduce shmem reliable config: arm64-randconfig-r123-20240607 (https://download.01.org/0day-ci/archive/20240609/202406090739.J3hAY6q8-lkp@…) compiler: aarch64-linux-gcc (GCC) 13.2.0 reproduce: (https://download.01.org/0day-ci/archive/20240609/202406090739.J3hAY6q8-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202406090739.J3hAY6q8-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) >> mm/shmem.c:1601:19: sparse: sparse: invalid assignment: |= mm/shmem.c:1601:19: sparse: left side has type restricted gfp_t mm/shmem.c:1601:19: sparse: right side has type unsigned int mm/shmem.c: note: in included file (through include/linux/percpu_counter.h, include/linux/quota.h, include/linux/fs.h): include/linux/gfp.h:457:34: sparse: sparse: restricted gfp_t degrades to integer mm/shmem.c: In function 'shmem_fh_to_dentry': mm/shmem.c:3403:24: warning: array subscript 2 is outside array bounds of '__u32[0]' {aka 'unsigned int[]'} [-Warray-bounds=] 3403 | inum = fid->raw[2]; | ~~~~~~~~^~~ In file included from mm/shmem.c:53: include/linux/exportfs.h:129:23: note: while referencing 'raw' 129 | __u32 raw[0]; | ^~~ mm/shmem.c:3404:39: warning: array subscript 1 is outside array bounds of '__u32[0]' {aka 'unsigned int[]'} [-Warray-bounds=] 3404 | inum = (inum << 32) | fid->raw[1]; | ~~~~~~~~^~~ include/linux/exportfs.h:129:23: note: while referencing 'raw' 129 | __u32 raw[0]; | ^~~ mm/shmem.c:3406:61: warning: array subscript 0 is outside array bounds of '__u32[0]' {aka 'unsigned int[]'} [-Warray-bounds=] 3406 | inode = ilookup5(sb, (unsigned long)(inum + fid->raw[0]), | ~~~~~~~~^~~ include/linux/exportfs.h:129:23: note: while referencing 'raw' 129 | __u32 raw[0]; | ^~~ vim +1601 mm/shmem.c 1595 1596 static inline void shmem_prepare_alloc(gfp_t *gfp_mask) 1597 { 1598 if (!shmem_reliable_is_enabled()) 1599 return; 1600 > 1601 *gfp_mask |= ___GFP_RELIABILITY; 1602 } 1603 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:openEuler-1.0-LTS] BUILD REGRESSION 6a98543755cf2f636ae3169f3774d226d328d2cf
by kernel test robot 09 Jun '24

09 Jun '24

tree/branch: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS branch HEAD: 6a98543755cf2f636ae3169f3774d226d328d2cf !8628 erspan: make sure erspan_base_hdr is present in skb->head Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202406081538.GZO9E4bP-lkp@intel.com https://lore.kernel.org/oe-kbuild-all/202406090015.Dx2VIQ1d-lkp@intel.com https://lore.kernel.org/oe-kbuild-all/202406090419.Or3DQ4pF-lkp@intel.com Error/Warning: (recently discovered and may have been fixed) mm/khugepaged.c:974:21: sparse: sparse: invalid assignment: |= Unverified Error/Warning (likely false positive, please contact us if interested): drivers/scsi/ufs/ufs-qcom.c:1665: error: Cannot parse struct or union! super.c:(.exit.text+0x7c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `netlink_kernel_release' super.c:(.init.text+0x6b38): relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21 against undefined symbol `init_net' super.c:(.init.text+0x6b48): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `__netlink_kernel_create' super.c:(.text+0x130dc): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `__alloc_skb' super.c:(.text+0x13144): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `__nlmsg_put' super.c:(.text+0x131b4): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `netlink_broadcast' super.c:(.text+0x131d8): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `kfree_skb' Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- arm64-allmodconfig | `-- drivers-gpu-drm-nouveau-nvkm-core-object.c:warning:ISO-C90-forbids-mixed-declarations-and-code |-- arm64-defconfig | `-- drivers-gpu-drm-nouveau-nvkm-core-object.c:warning:ISO-C90-forbids-mixed-declarations-and-code |-- arm64-randconfig-004-20240608 | |-- drivers-scsi-ufs-ufs-qcom.c:error:Cannot-parse-struct-or-union | |-- super.c:(.exit.text):relocation-truncated-to-fit:R_AARCH64_CALL26-against-undefined-symbol-netlink_kernel_release | |-- super.c:(.init.text):relocation-truncated-to-fit:R_AARCH64_ADR_PREL_PG_HI21-against-undefined-symbol-init_net | |-- super.c:(.init.text):relocation-truncated-to-fit:R_AARCH64_CALL26-against-undefined-symbol-__netlink_kernel_create | |-- super.c:(.text):relocation-truncated-to-fit:R_AARCH64_CALL26-against-undefined-symbol-__alloc_skb | |-- super.c:(.text):relocation-truncated-to-fit:R_AARCH64_CALL26-against-undefined-symbol-__nlmsg_put | |-- super.c:(.text):relocation-truncated-to-fit:R_AARCH64_CALL26-against-undefined-symbol-kfree_skb | `-- super.c:(.text):relocation-truncated-to-fit:R_AARCH64_CALL26-against-undefined-symbol-netlink_broadcast |-- arm64-randconfig-r123-20240607 | |-- drivers-remoteproc-qcom_adsp_pil.c:sparse:sparse:incorrect-type-in-assignment-(different-address-spaces)-expected-void-mem_region-got-void-noderef-asn | |-- drivers-remoteproc-qcom_q6v5_pil.c:sparse:sparse:incorrect-type-in-assignment-(different-address-spaces)-expected-void-mba_region-got-void-noderef-asn | |-- drivers-remoteproc-qcom_q6v5_pil.c:sparse:sparse:incorrect-type-in-assignment-(different-address-spaces)-expected-void-mpss_region-got-void-noderef-asn | |-- drivers-remoteproc-qcom_wcnss.c:sparse:sparse:incorrect-type-in-assignment-(different-address-spaces)-expected-void-mem_region-got-void-noderef-asn | |-- mm-khugepaged.c:sparse:sparse:invalid-assignment: | `-- net-netfilter-nft_counter.c:sparse:sparse:incorrect-type-in-argument-(different-address-spaces)-expected-struct-nft_counter_percpu_priv-noderef-asn-priv-got-struct-nft_counter_percpu_priv-priv |-- x86_64-buildonly-randconfig-004-20240609 | `-- fs-f2fs-.tmp_recovery.o:warning:objtool:missing-symbol-for-section-.init.text |-- x86_64-buildonly-randconfig-006-20240609 | |-- drivers-gpu-drm-nouveau-nvkm-core-object.c:warning:ISO-C90-forbids-mixed-declarations-and-code | `-- fs-f2fs-recovery.o:warning:objtool:missing-symbol-for-section-.init.text `-- x86_64-randconfig-001-20240609 `-- drivers-gpu-drm-nouveau-nvkm-core-object.c:warning:ISO-C90-forbids-mixed-declarations-and-code clang_recent_errors |-- x86_64-allyesconfig | |-- drivers-gpu-drm-nouveau-nvkm-core-object.c:warning:mixing-declarations-and-code-is-a-C99-extension | `-- fs-f2fs-.tmp_recovery.o:warning:objtool:missing-symbol-for-section-.init.text |-- x86_64-buildonly-randconfig-002-20240609 | `-- fs-f2fs-recovery.o:warning:objtool:missing-symbol-for-section-.init.text `-- x86_64-buildonly-randconfig-005-20240609 |-- drivers-gpu-drm-nouveau-nvkm-core-object.c:warning:mixing-declarations-and-code-is-a-C99-extension `-- fs-f2fs-recovery.o:warning:objtool:missing-symbol-for-section-.init.text elapsed time: 1126m configs tested: 16 configs skipped: 131 tested configs: arm64 allmodconfig gcc arm64 allnoconfig gcc arm64 defconfig gcc arm64 randconfig-003-20240609 gcc x86_64 allnoconfig clang x86_64 allyesconfig clang x86_64 buildonly-randconfig-001-20240609 clang x86_64 buildonly-randconfig-002-20240609 clang x86_64 buildonly-randconfig-003-20240609 clang x86_64 buildonly-randconfig-004-20240609 gcc x86_64 buildonly-randconfig-005-20240609 clang x86_64 buildonly-randconfig-006-20240609 gcc x86_64 defconfig gcc x86_64 randconfig-001-20240609 gcc x86_64 randconfig-002-20240609 clang x86_64 rhel-8.3-rust clang -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:openEuler-1.0-LTS 18949/22827] mm/khugepaged.c:974:21: sparse: sparse: invalid assignment: |=
by kernel test robot 09 Jun '24

09 Jun '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 6a98543755cf2f636ae3169f3774d226d328d2cf commit: ff0fb9e816fac221fa24a1810dd895745406070b [18949/22827] mm: thp: Add memory reliable support for hugepaged collapse config: arm64-randconfig-r123-20240607 (https://download.01.org/0day-ci/archive/20240609/202406090419.Or3DQ4pF-lkp@…) compiler: aarch64-linux-gcc (GCC) 13.2.0 reproduce: (https://download.01.org/0day-ci/archive/20240609/202406090419.Or3DQ4pF-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202406090419.Or3DQ4pF-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) >> mm/khugepaged.c:974:21: sparse: sparse: invalid assignment: |= mm/khugepaged.c:974:21: sparse: left side has type restricted gfp_t mm/khugepaged.c:974:21: sparse: right side has type unsigned int mm/khugepaged.c:1352:21: sparse: sparse: invalid assignment: |= mm/khugepaged.c:1352:21: sparse: left side has type restricted gfp_t mm/khugepaged.c:1352:21: sparse: right side has type unsigned int mm/khugepaged.c:1378:9: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void **slot @@ got void [noderef] <asn:4> ** @@ mm/khugepaged.c:1378:9: sparse: expected void **slot mm/khugepaged.c:1378:9: sparse: got void [noderef] <asn:4> ** mm/khugepaged.c:1378:9: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void **slot @@ got void [noderef] <asn:4> ** @@ mm/khugepaged.c:1378:9: sparse: expected void **slot mm/khugepaged.c:1378:9: sparse: got void [noderef] <asn:4> ** mm/khugepaged.c:1409:56: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void [noderef] <asn:4> **slot @@ got void **slot @@ mm/khugepaged.c:1409:56: sparse: expected void [noderef] <asn:4> **slot mm/khugepaged.c:1409:56: sparse: got void **slot mm/khugepaged.c:1458:22: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void **slot @@ got void [noderef] <asn:4> ** @@ mm/khugepaged.c:1458:22: sparse: expected void **slot mm/khugepaged.c:1458:22: sparse: got void [noderef] <asn:4> ** mm/khugepaged.c:1459:17: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void [noderef] <asn:4> **slot @@ got void **slot @@ mm/khugepaged.c:1459:17: sparse: expected void [noderef] <asn:4> **slot mm/khugepaged.c:1459:17: sparse: got void **slot mm/khugepaged.c:1483:60: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void [noderef] <asn:4> **slot @@ got void **slot @@ mm/khugepaged.c:1483:60: sparse: expected void [noderef] <asn:4> **slot mm/khugepaged.c:1483:60: sparse: got void **slot mm/khugepaged.c:1486:47: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void [noderef] <asn:4> **slot @@ got void **slot @@ mm/khugepaged.c:1486:47: sparse: expected void [noderef] <asn:4> **slot mm/khugepaged.c:1486:47: sparse: got void **slot mm/khugepaged.c:1486:22: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void **slot @@ got void [noderef] <asn:4> ** @@ mm/khugepaged.c:1486:22: sparse: expected void **slot mm/khugepaged.c:1486:22: sparse: got void [noderef] <asn:4> ** mm/khugepaged.c:1378:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void [noderef] <asn:4> **slot @@ got void **slot @@ mm/khugepaged.c:1378:9: sparse: expected void [noderef] <asn:4> **slot mm/khugepaged.c:1378:9: sparse: got void **slot mm/khugepaged.c:1378:9: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void **slot @@ got void [noderef] <asn:4> ** @@ mm/khugepaged.c:1378:9: sparse: expected void **slot mm/khugepaged.c:1378:9: sparse: got void [noderef] <asn:4> ** mm/khugepaged.c:1578:17: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void **slot @@ got void [noderef] <asn:4> ** @@ mm/khugepaged.c:1578:17: sparse: expected void **slot mm/khugepaged.c:1578:17: sparse: got void [noderef] <asn:4> ** mm/khugepaged.c:1578:17: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void **slot @@ got void [noderef] <asn:4> ** @@ mm/khugepaged.c:1578:17: sparse: expected void **slot mm/khugepaged.c:1578:17: sparse: got void [noderef] <asn:4> ** mm/khugepaged.c:1597:68: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void [noderef] <asn:4> **slot @@ got void **slot @@ mm/khugepaged.c:1597:68: sparse: expected void [noderef] <asn:4> **slot mm/khugepaged.c:1597:68: sparse: got void **slot mm/khugepaged.c:1598:55: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void [noderef] <asn:4> **slot @@ got void **slot @@ mm/khugepaged.c:1598:55: sparse: expected void [noderef] <asn:4> **slot mm/khugepaged.c:1598:55: sparse: got void **slot mm/khugepaged.c:1598:30: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void **slot @@ got void [noderef] <asn:4> ** @@ mm/khugepaged.c:1598:30: sparse: expected void **slot mm/khugepaged.c:1598:30: sparse: got void [noderef] <asn:4> ** mm/khugepaged.c:1578:17: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void [noderef] <asn:4> **slot @@ got void **slot @@ mm/khugepaged.c:1578:17: sparse: expected void [noderef] <asn:4> **slot mm/khugepaged.c:1578:17: sparse: got void **slot mm/khugepaged.c:1578:17: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void **slot @@ got void [noderef] <asn:4> ** @@ mm/khugepaged.c:1578:17: sparse: expected void **slot mm/khugepaged.c:1578:17: sparse: got void [noderef] <asn:4> ** mm/khugepaged.c:1633:9: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void **slot @@ got void [noderef] <asn:4> ** @@ mm/khugepaged.c:1633:9: sparse: expected void **slot mm/khugepaged.c:1633:9: sparse: got void [noderef] <asn:4> ** mm/khugepaged.c:1633:9: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void **slot @@ got void [noderef] <asn:4> ** @@ mm/khugepaged.c:1633:9: sparse: expected void **slot mm/khugepaged.c:1633:9: sparse: got void [noderef] <asn:4> ** mm/khugepaged.c:1637:46: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void [noderef] <asn:4> **slot @@ got void **slot @@ mm/khugepaged.c:1637:46: sparse: expected void [noderef] <asn:4> **slot mm/khugepaged.c:1637:46: sparse: got void **slot mm/khugepaged.c:1639:30: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void **slot @@ got void [noderef] <asn:4> ** @@ mm/khugepaged.c:1639:30: sparse: expected void **slot mm/khugepaged.c:1639:30: sparse: got void [noderef] <asn:4> ** mm/khugepaged.c:1682:55: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void [noderef] <asn:4> **slot @@ got void **slot @@ mm/khugepaged.c:1682:55: sparse: expected void [noderef] <asn:4> **slot mm/khugepaged.c:1682:55: sparse: got void **slot mm/khugepaged.c:1682:30: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void **slot @@ got void [noderef] <asn:4> ** @@ mm/khugepaged.c:1682:30: sparse: expected void **slot mm/khugepaged.c:1682:30: sparse: got void [noderef] <asn:4> ** mm/khugepaged.c:1633:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void [noderef] <asn:4> **slot @@ got void **slot @@ mm/khugepaged.c:1633:9: sparse: expected void [noderef] <asn:4> **slot mm/khugepaged.c:1633:9: sparse: got void **slot mm/khugepaged.c:1633:9: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void **slot @@ got void [noderef] <asn:4> ** @@ mm/khugepaged.c:1633:9: sparse: expected void **slot mm/khugepaged.c:1633:9: sparse: got void [noderef] <asn:4> ** mm/khugepaged.c: note: in included file (through include/linux/mm.h): include/linux/gfp.h:457:34: sparse: sparse: restricted gfp_t degrades to integer mm/khugepaged.c:1336: warning: Function parameter or member 'mm' not described in 'collapse_shmem' mm/khugepaged.c:1336: warning: Function parameter or member 'mapping' not described in 'collapse_shmem' mm/khugepaged.c:1336: warning: Function parameter or member 'start' not described in 'collapse_shmem' mm/khugepaged.c:1336: warning: Function parameter or member 'hpage' not described in 'collapse_shmem' mm/khugepaged.c:1336: warning: Function parameter or member 'node' not described in 'collapse_shmem' mm/khugepaged.c:1336: warning: Function parameter or member 'reliable' not described in 'collapse_shmem' vim +974 mm/khugepaged.c 949 950 static void collapse_huge_page(struct mm_struct *mm, 951 unsigned long address, 952 struct page **hpage, 953 int node, int referenced, int unmapped, 954 bool reliable) 955 { 956 pmd_t *pmd, _pmd; 957 pte_t *pte; 958 pgtable_t pgtable; 959 struct page *new_page; 960 spinlock_t *pmd_ptl, *pte_ptl; 961 int isolated = 0, result = 0; 962 struct mem_cgroup *memcg; 963 struct vm_area_struct *vma; 964 unsigned long mmun_start; /* For mmu_notifiers */ 965 unsigned long mmun_end; /* For mmu_notifiers */ 966 gfp_t gfp; 967 968 VM_BUG_ON(address & ~HPAGE_PMD_MASK); 969 970 /* Only allocate from the target node */ 971 gfp = alloc_hugepage_khugepaged_gfpmask() | __GFP_THISNODE; 972 973 if (reliable) > 974 gfp |= ___GFP_RELIABILITY; 975 976 /* 977 * Before allocating the hugepage, release the mmap_sem read lock. 978 * The allocation can take potentially a long time if it involves 979 * sync compaction, and we do not need to hold the mmap_sem during 980 * that. We will recheck the vma after taking it again in write mode. 981 */ 982 up_read(&mm->mmap_sem); 983 new_page = khugepaged_alloc_page(hpage, gfp, node); 984 if (!new_page) { 985 result = SCAN_ALLOC_HUGE_PAGE_FAIL; 986 goto out_nolock; 987 } 988 989 if (unlikely(mem_cgroup_try_charge(new_page, mm, gfp, &memcg, true))) { 990 result = SCAN_CGROUP_CHARGE_FAIL; 991 goto out_nolock; 992 } 993 994 down_read(&mm->mmap_sem); 995 result = hugepage_vma_revalidate(mm, address, &vma); 996 if (result) { 997 mem_cgroup_cancel_charge(new_page, memcg, true); 998 up_read(&mm->mmap_sem); 999 goto out_nolock; 1000 } 1001 1002 pmd = mm_find_pmd(mm, address); 1003 if (!pmd) { 1004 result = SCAN_PMD_NULL; 1005 mem_cgroup_cancel_charge(new_page, memcg, true); 1006 up_read(&mm->mmap_sem); 1007 goto out_nolock; 1008 } 1009 1010 /* 1011 * __collapse_huge_page_swapin always returns with mmap_sem locked. 1012 * If it fails, we release mmap_sem and jump out_nolock. 1013 * Continuing to collapse causes inconsistency. 1014 */ 1015 if (unmapped && !__collapse_huge_page_swapin(mm, vma, address, 1016 pmd, referenced)) { 1017 mem_cgroup_cancel_charge(new_page, memcg, true); 1018 up_read(&mm->mmap_sem); 1019 goto out_nolock; 1020 } 1021 1022 up_read(&mm->mmap_sem); 1023 /* 1024 * Prevent all access to pagetables with the exception of 1025 * gup_fast later handled by the ptep_clear_flush and the VM 1026 * handled by the anon_vma lock + PG_lock. 1027 */ 1028 down_write(&mm->mmap_sem); 1029 result = hugepage_vma_revalidate(mm, address, &vma); 1030 if (result) 1031 goto out; 1032 /* check if the pmd is still valid */ 1033 if (mm_find_pmd(mm, address) != pmd) 1034 goto out; 1035 1036 anon_vma_lock_write(vma->anon_vma); 1037 1038 pte = pte_offset_map(pmd, address); 1039 pte_ptl = pte_lockptr(mm, pmd); 1040 1041 mmun_start = address; 1042 mmun_end = address + HPAGE_PMD_SIZE; 1043 mmu_notifier_invalidate_range_start(mm, mmun_start, mmun_end); 1044 pmd_ptl = pmd_lock(mm, pmd); /* probably unnecessary */ 1045 /* 1046 * After this gup_fast can't run anymore. This also removes 1047 * any huge TLB entry from the CPU so we won't allow 1048 * huge and small TLB entries for the same virtual address 1049 * to avoid the risk of CPU bugs in that area. 1050 */ 1051 _pmd = pmdp_collapse_flush(vma, address, pmd); 1052 spin_unlock(pmd_ptl); 1053 mmu_notifier_invalidate_range_end(mm, mmun_start, mmun_end); 1054 1055 spin_lock(pte_ptl); 1056 isolated = __collapse_huge_page_isolate(vma, address, pte); 1057 spin_unlock(pte_ptl); 1058 1059 if (unlikely(!isolated)) { 1060 pte_unmap(pte); 1061 spin_lock(pmd_ptl); 1062 BUG_ON(!pmd_none(*pmd)); 1063 /* 1064 * We can only use set_pmd_at when establishing 1065 * hugepmds and never for establishing regular pmds that 1066 * points to regular pagetables. Use pmd_populate for that 1067 */ 1068 pmd_populate(mm, pmd, pmd_pgtable(_pmd)); 1069 spin_unlock(pmd_ptl); 1070 anon_vma_unlock_write(vma->anon_vma); 1071 result = SCAN_FAIL; 1072 goto out; 1073 } 1074 1075 /* 1076 * All pages are isolated and locked so anon_vma rmap 1077 * can't run anymore. 1078 */ 1079 anon_vma_unlock_write(vma->anon_vma); 1080 1081 __collapse_huge_page_copy(pte, new_page, vma, address, pte_ptl); 1082 pte_unmap(pte); 1083 __SetPageUptodate(new_page); 1084 pgtable = pmd_pgtable(_pmd); 1085 1086 _pmd = mk_huge_pmd(new_page, vma->vm_page_prot); 1087 _pmd = maybe_pmd_mkwrite(pmd_mkdirty(_pmd), vma); 1088 1089 /* 1090 * spin_lock() below is not the equivalent of smp_wmb(), so 1091 * this is needed to avoid the copy_huge_page writes to become 1092 * visible after the set_pmd_at() write. 1093 */ 1094 smp_wmb(); 1095 1096 spin_lock(pmd_ptl); 1097 BUG_ON(!pmd_none(*pmd)); 1098 page_add_new_anon_rmap(new_page, vma, address, true); 1099 mem_cgroup_commit_charge(new_page, memcg, false, true); 1100 count_memcg_events(memcg, THP_COLLAPSE_ALLOC, 1); 1101 lru_cache_add_active_or_unevictable(new_page, vma); 1102 pgtable_trans_huge_deposit(mm, pmd, pgtable); 1103 set_pmd_at(mm, address, pmd, _pmd); 1104 update_mmu_cache_pmd(vma, address, pmd); 1105 spin_unlock(pmd_ptl); 1106 1107 *hpage = NULL; 1108 1109 khugepaged_pages_collapsed++; 1110 result = SCAN_SUCCEED; 1111 out_up_write: 1112 up_write(&mm->mmap_sem); 1113 out_nolock: 1114 trace_mm_collapse_huge_page(mm, isolated, result); 1115 return; 1116 out: 1117 mem_cgroup_cancel_charge(new_page, memcg, true); 1118 goto out_up_write; 1119 } 1120 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:openEuler-1.0-LTS 5421/22827] drivers/remoteproc/qcom_adsp_pil.c:246:26: sparse: sparse: incorrect type in assignment (different address spaces)
by kernel test robot 09 Jun '24

09 Jun '24

Hi Paulo, First bad commit (maybe != root cause): tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 6a98543755cf2f636ae3169f3774d226d328d2cf commit: 71e217e85c3dff8a9151707ed3afc7b4b054a2d4 [5421/22827] selinux: use kernel linux/socket.h for genheaders and mdp config: arm64-randconfig-r123-20240607 (https://download.01.org/0day-ci/archive/20240609/202406090015.Dx2VIQ1d-lkp@…) compiler: aarch64-linux-gcc (GCC) 13.2.0 reproduce: (https://download.01.org/0day-ci/archive/20240609/202406090015.Dx2VIQ1d-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202406090015.Dx2VIQ1d-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) >> drivers/remoteproc/qcom_adsp_pil.c:246:26: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void *mem_region @@ got void [noderef] <asn:2> * @@ drivers/remoteproc/qcom_adsp_pil.c:246:26: sparse: expected void *mem_region drivers/remoteproc/qcom_adsp_pil.c:246:26: sparse: got void [noderef] <asn:2> * -- >> drivers/remoteproc/qcom_q6v5_pil.c:1096:27: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void *mba_region @@ got void [noderef] <asn:2> * @@ drivers/remoteproc/qcom_q6v5_pil.c:1096:27: sparse: expected void *mba_region drivers/remoteproc/qcom_q6v5_pil.c:1096:27: sparse: got void [noderef] <asn:2> * >> drivers/remoteproc/qcom_q6v5_pil.c:1114:28: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void *mpss_region @@ got void [noderef] <asn:2> * @@ drivers/remoteproc/qcom_q6v5_pil.c:1114:28: sparse: expected void *mpss_region drivers/remoteproc/qcom_q6v5_pil.c:1114:28: sparse: got void [noderef] <asn:2> * drivers/remoteproc/qcom_q6v5_pil.c: In function 'q6v5_mpss_load': drivers/remoteproc/qcom_q6v5_pil.c:741:70: warning: '%02d' directive output may be truncated writing between 2 and 11 bytes into a region of size 3 [-Wformat-truncation=] 741 | snprintf(seg_name, sizeof(seg_name), "modem.b%02d", i); | ^~~~ drivers/remoteproc/qcom_q6v5_pil.c:741:62: note: directive argument in the range [-2147483641, 65534] 741 | snprintf(seg_name, sizeof(seg_name), "modem.b%02d", i); | ^~~~~~~~~~~~~ drivers/remoteproc/qcom_q6v5_pil.c:741:25: note: 'snprintf' output between 10 and 19 bytes into a destination of size 10 741 | snprintf(seg_name, sizeof(seg_name), "modem.b%02d", i); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- >> drivers/remoteproc/qcom_wcnss.c:456:27: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void *mem_region @@ got void [noderef] <asn:2> * @@ drivers/remoteproc/qcom_wcnss.c:456:27: sparse: expected void *mem_region drivers/remoteproc/qcom_wcnss.c:456:27: sparse: got void [noderef] <asn:2> * -- >> net/netfilter/nft_counter.c:158:35: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct nft_counter_percpu_priv [noderef] <asn:3> *priv @@ got struct nft_counter_percpu_priv *priv @@ net/netfilter/nft_counter.c:158:35: sparse: expected struct nft_counter_percpu_priv [noderef] <asn:3> *priv net/netfilter/nft_counter.c:158:35: sparse: got struct nft_counter_percpu_priv *priv net/netfilter/nft_counter.c:113:20: sparse: sparse: dereference of noderef expression vim +246 drivers/remoteproc/qcom_adsp_pil.c b9e718e950c3df Bjorn Andersson 2016-08-22 227 b9e718e950c3df Bjorn Andersson 2016-08-22 228 static int adsp_alloc_memory_region(struct qcom_adsp *adsp) b9e718e950c3df Bjorn Andersson 2016-08-22 229 { b9e718e950c3df Bjorn Andersson 2016-08-22 230 struct device_node *node; b9e718e950c3df Bjorn Andersson 2016-08-22 231 struct resource r; b9e718e950c3df Bjorn Andersson 2016-08-22 232 int ret; b9e718e950c3df Bjorn Andersson 2016-08-22 233 b9e718e950c3df Bjorn Andersson 2016-08-22 234 node = of_parse_phandle(adsp->dev->of_node, "memory-region", 0); b9e718e950c3df Bjorn Andersson 2016-08-22 235 if (!node) { b9e718e950c3df Bjorn Andersson 2016-08-22 236 dev_err(adsp->dev, "no memory-region specified\n"); b9e718e950c3df Bjorn Andersson 2016-08-22 237 return -EINVAL; b9e718e950c3df Bjorn Andersson 2016-08-22 238 } b9e718e950c3df Bjorn Andersson 2016-08-22 239 b9e718e950c3df Bjorn Andersson 2016-08-22 240 ret = of_address_to_resource(node, 0, &r); b9e718e950c3df Bjorn Andersson 2016-08-22 241 if (ret) b9e718e950c3df Bjorn Andersson 2016-08-22 242 return ret; b9e718e950c3df Bjorn Andersson 2016-08-22 243 b9e718e950c3df Bjorn Andersson 2016-08-22 244 adsp->mem_phys = adsp->mem_reloc = r.start; b9e718e950c3df Bjorn Andersson 2016-08-22 245 adsp->mem_size = resource_size(&r); b9e718e950c3df Bjorn Andersson 2016-08-22 @246 adsp->mem_region = devm_ioremap_wc(adsp->dev, adsp->mem_phys, adsp->mem_size); b9e718e950c3df Bjorn Andersson 2016-08-22 247 if (!adsp->mem_region) { b9e718e950c3df Bjorn Andersson 2016-08-22 248 dev_err(adsp->dev, "unable to map memory region: %pa+%zx\n", b9e718e950c3df Bjorn Andersson 2016-08-22 249 &r.start, adsp->mem_size); b9e718e950c3df Bjorn Andersson 2016-08-22 250 return -EBUSY; b9e718e950c3df Bjorn Andersson 2016-08-22 251 } b9e718e950c3df Bjorn Andersson 2016-08-22 252 b9e718e950c3df Bjorn Andersson 2016-08-22 253 return 0; b9e718e950c3df Bjorn Andersson 2016-08-22 254 } b9e718e950c3df Bjorn Andersson 2016-08-22 255 :::::: The code at line 246 was first introduced by commit :::::: b9e718e950c3dfa458bbf9180a8d8691e55413ae remoteproc: Introduce Qualcomm ADSP PIL :::::: TO: Bjorn Andersson <bjorn.andersson(a)sonymobile.com> :::::: CC: Bjorn Andersson <bjorn.andersson(a)linaro.org> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6] bpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue
by Liu Jian 08 Jun '24

08 Jun '24

From: Jason Xing <kernelxing(a)tencent.com> stable inclusion from stable-v6.6.31 commit b397a0ab8582c533ec0c6b732392f141fc364f87 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9U1UZ CVE: CVE-2024-3693 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit 6648e613226e18897231ab5e42ffc29e63fa3365 ] Fix NULL pointer data-races in sk_psock_skb_ingress_enqueue() which syzbot reported [1]. [1] BUG: KCSAN: data-race in sk_psock_drop / sk_psock_skb_ingress_enqueue write to 0xffff88814b3278b8 of 8 bytes by task 10724 on cpu 1: sk_psock_stop_verdict net/core/skmsg.c:1257 [inline] sk_psock_drop+0x13e/0x1f0 net/core/skmsg.c:843 sk_psock_put include/linux/skmsg.h:459 [inline] sock_map_close+0x1a7/0x260 net/core/sock_map.c:1648 unix_release+0x4b/0x80 net/unix/af_unix.c:1048 __sock_release net/socket.c:659 [inline] sock_close+0x68/0x150 net/socket.c:1421 __fput+0x2c1/0x660 fs/file_table.c:422 __fput_sync+0x44/0x60 fs/file_table.c:507 __do_sys_close fs/open.c:1556 [inline] __se_sys_close+0x101/0x1b0 fs/open.c:1541 __x64_sys_close+0x1f/0x30 fs/open.c:1541 do_syscall_64+0xd3/0x1d0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 read to 0xffff88814b3278b8 of 8 bytes by task 10713 on cpu 0: sk_psock_data_ready include/linux/skmsg.h:464 [inline] sk_psock_skb_ingress_enqueue+0x32d/0x390 net/core/skmsg.c:555 sk_psock_skb_ingress_self+0x185/0x1e0 net/core/skmsg.c:606 sk_psock_verdict_apply net/core/skmsg.c:1008 [inline] sk_psock_verdict_recv+0x3e4/0x4a0 net/core/skmsg.c:1202 unix_read_skb net/unix/af_unix.c:2546 [inline] unix_stream_read_skb+0x9e/0xf0 net/unix/af_unix.c:2682 sk_psock_verdict_data_ready+0x77/0x220 net/core/skmsg.c:1223 unix_stream_sendmsg+0x527/0x860 net/unix/af_unix.c:2339 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x140/0x180 net/socket.c:745 ____sys_sendmsg+0x312/0x410 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x1e9/0x280 net/socket.c:2667 __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x46/0x50 net/socket.c:2674 do_syscall_64+0xd3/0x1d0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 value changed: 0xffffffff83d7feb0 -> 0x0000000000000000 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 10713 Comm: syz-executor.4 Tainted: G W 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 Prior to this, commit 4cd12c6065df ("bpf, sockmap: Fix NULL pointer dereference in sk_psock_verdict_data_ready()") fixed one NULL pointer similarly due to no protection of saved_data_ready. Here is another different caller causing the same issue because of the same reason. So we should protect it with sk_callback_lock read lock because the writer side in the sk_psock_drop() uses "write_lock_bh(&sk->sk_callback_lock);". To avoid errors that could happen in future, I move those two pairs of lock into the sk_psock_data_ready(), which is suggested by John Fastabend. Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface") Reported-by: syzbot+aa8c8ec2538929f18f2d(a)syzkaller.appspotmail.com Signed-off-by: Jason Xing <kernelxing(a)tencent.com> Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Reviewed-by: John Fastabend <john.fastabend(a)gmail.com> Closes: https://syzkaller.appspot.com/bug?extid=aa8c8ec2538929f18f2d Link: https://lore.kernel.org/all/20240329134037.92124-1-kerneljasonxing@gmail.com Link: https://lore.kernel.org/bpf/20240404021001.94815-1-kerneljasonxing@gmail.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- include/linux/skmsg.h | 2 ++ net/core/skmsg.c | 5 +---- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/include/linux/skmsg.h b/include/linux/skmsg.h index f69af3de0da0..fdedb7a29c0e 100644 --- a/include/linux/skmsg.h +++ b/include/linux/skmsg.h @@ -467,10 +467,12 @@ static inline void sk_psock_put(struct sock *sk, struct sk_psock *psock) static inline void sk_psock_data_ready(struct sock *sk, struct sk_psock *psock) { + read_lock_bh(&sk->sk_callback_lock); if (psock->saved_data_ready) psock->saved_data_ready(sk); else sk->sk_data_ready(sk); + read_unlock_bh(&sk->sk_callback_lock); } static inline void psock_set_prog(struct bpf_prog **pprog, diff --git a/net/core/skmsg.c b/net/core/skmsg.c index 6f774de8f6b2..f2e7ce81fef0 100644 --- a/net/core/skmsg.c +++ b/net/core/skmsg.c @@ -1234,11 +1234,8 @@ static void sk_psock_verdict_data_ready(struct sock *sk) rcu_read_lock(); psock = sk_psock(sk); - if (psock) { - read_lock_bh(&sk->sk_callback_lock); + if (psock) sk_psock_data_ready(sk, psock); - read_unlock_bh(&sk->sk_callback_lock); - } rcu_read_unlock(); } } -- 2.34.1

2 1

[PATCH OLK-6.6] ipv6: prevent NULL dereference in ip6_output()
by Liu Jian 08 Jun '24

08 Jun '24

From: Eric Dumazet <edumazet(a)google.com> mainline inclusion from mainline-v6.9 commit 4db783d68b9b39a411a96096c10828ff5dfada7a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9UO9S CVE: CVE-2024-36901 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- According to syzbot, there is a chance that ip6_dst_idev() returns NULL in ip6_output(). Most places in IPv6 stack deal with a NULL idev just fine, but not here. syzbot reported: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7] CPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237 Code: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202 RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000 RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48 RBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad R10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0 R13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000 FS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358 sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248 sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653 sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783 sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline] sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169 sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73 __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 778d80be5269 ("ipv6: Add disable_ipv6 sysctl to disable IPv6 operaion on specific interface.") Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Eric Dumazet <edumazet(a)google.com> Reviewed-by: Larysa Zaremba <larysa.zaremba(a)intel.com> Link: https://lore.kernel.org/r/20240507161842.773961-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: net/ipv6/ip6_output.c [Did not backport d289ab65b89c.] Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/ipv6/ip6_output.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c index 53fe1375b147..412a16932341 100644 --- a/net/ipv6/ip6_output.c +++ b/net/ipv6/ip6_output.c @@ -227,7 +227,7 @@ int ip6_output(struct net *net, struct sock *sk, struct sk_buff *skb) skb->protocol = htons(ETH_P_IPV6); skb->dev = dev; - if (unlikely(idev->cnf.disable_ipv6)) { + if (unlikely(!idev || idev->cnf.disable_ipv6)) { IP6_INC_STATS(net, idev, IPSTATS_MIB_OUTDISCARDS); kfree_skb_reason(skb, SKB_DROP_REASON_IPV6DISABLED); return 0; -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] ipv6: prevent NULL dereference in ip6_output()
by Liu Jian 08 Jun '24

08 Jun '24

From: Eric Dumazet <edumazet(a)google.com> mainline inclusion from mainline-v6.9 commit 4db783d68b9b39a411a96096c10828ff5dfada7a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9UO9S CVE: CVE-2024-36901 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- According to syzbot, there is a chance that ip6_dst_idev() returns NULL in ip6_output(). Most places in IPv6 stack deal with a NULL idev just fine, but not here. syzbot reported: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7] CPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237 Code: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202 RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000 RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48 RBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad R10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0 R13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000 FS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358 sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248 sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653 sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783 sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline] sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169 sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73 __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 778d80be5269 ("ipv6: Add disable_ipv6 sysctl to disable IPv6 operaion on specific interface.") Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Eric Dumazet <edumazet(a)google.com> Reviewed-by: Larysa Zaremba <larysa.zaremba(a)intel.com> Link: https://lore.kernel.org/r/20240507161842.773961-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: net/ipv6/ip6_output.c [Did not backport d289ab65b89c.] Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/ipv6/ip6_output.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c index 968b2602c400..179fe599efba 100644 --- a/net/ipv6/ip6_output.c +++ b/net/ipv6/ip6_output.c @@ -206,7 +206,7 @@ int ip6_output(struct net *net, struct sock *sk, struct sk_buff *skb) skb->protocol = htons(ETH_P_IPV6); skb->dev = dev; - if (unlikely(idev->cnf.disable_ipv6)) { + if (unlikely(!idev || idev->cnf.disable_ipv6)) { IP6_INC_STATS(net, idev, IPSTATS_MIB_OUTDISCARDS); kfree_skb(skb); return 0; -- 2.34.1

2 1

[PATCH OLK-5.10] ipv6: prevent NULL dereference in ip6_output()
by Liu Jian 08 Jun '24

08 Jun '24

From: Eric Dumazet <edumazet(a)google.com> mainline inclusion from mainline-v6.9 commit 4db783d68b9b39a411a96096c10828ff5dfada7a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9UO9S CVE: CVE-2024-36901 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- According to syzbot, there is a chance that ip6_dst_idev() returns NULL in ip6_output(). Most places in IPv6 stack deal with a NULL idev just fine, but not here. syzbot reported: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7] CPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237 Code: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202 RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000 RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48 RBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad R10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0 R13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000 FS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358 sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248 sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653 sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783 sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline] sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169 sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73 __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 778d80be5269 ("ipv6: Add disable_ipv6 sysctl to disable IPv6 operaion on specific interface.") Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Eric Dumazet <edumazet(a)google.com> Reviewed-by: Larysa Zaremba <larysa.zaremba(a)intel.com> Link: https://lore.kernel.org/r/20240507161842.773961-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: net/ipv6/ip6_output.c [Did not backport d289ab65b89c.] Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/ipv6/ip6_output.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c index 6adf0b536473..6d9571cb317d 100644 --- a/net/ipv6/ip6_output.c +++ b/net/ipv6/ip6_output.c @@ -240,7 +240,7 @@ int ip6_output(struct net *net, struct sock *sk, struct sk_buff *skb) skb->protocol = htons(ETH_P_IPV6); skb->dev = dev; - if (unlikely(idev->cnf.disable_ipv6)) { + if (unlikely(!idev || idev->cnf.disable_ipv6)) { IP6_INC_STATS(net, idev, IPSTATS_MIB_OUTDISCARDS); kfree_skb(skb); return 0; -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] ipv6: prevent NULL dereference in ip6_output()
by Liu Jian 08 Jun '24

08 Jun '24

From: Eric Dumazet <edumazet(a)google.com> mainline inclusion from mainline-v6.9 commit 4db783d68b9b39a411a96096c10828ff5dfada7a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9UO9S CVE: CVE-2024-36901 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- According to syzbot, there is a chance that ip6_dst_idev() returns NULL in ip6_output(). Most places in IPv6 stack deal with a NULL idev just fine, but not here. syzbot reported: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7] CPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237 Code: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202 RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000 RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48 RBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad R10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0 R13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000 FS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358 sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248 sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653 sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783 sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline] sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169 sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73 __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 778d80be5269 ("ipv6: Add disable_ipv6 sysctl to disable IPv6 operaion on specific interface.") Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Eric Dumazet <edumazet(a)google.com> Reviewed-by: Larysa Zaremba <larysa.zaremba(a)intel.com> Link: https://lore.kernel.org/r/20240507161842.773961-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: net/ipv6/ip6_output.c [Did not backport d289ab65b89c.] Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/ipv6/ip6_output.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c index f30cc72887a3..f0c94aaa039f 100644 --- a/net/ipv6/ip6_output.c +++ b/net/ipv6/ip6_output.c @@ -234,7 +234,7 @@ int ip6_output(struct net *net, struct sock *sk, struct sk_buff *skb) skb->protocol = htons(ETH_P_IPV6); skb->dev = dev; - if (unlikely(idev->cnf.disable_ipv6)) { + if (unlikely(!idev || idev->cnf.disable_ipv6)) { IP6_INC_STATS(net, idev, IPSTATS_MIB_OUTDISCARDS); kfree_skb(skb); return 0; -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] staging: rtl8712: fix use-after-free in rtl8712_dl_fw
by Jialin Zhang 08 Jun '24

08 Jun '24

From: Pavel Skripkin <paskripkin(a)gmail.com> mainline inclusion from mainline-v5.16-rc1 commit c052cc1a069c3e575619cf64ec427eb41176ca70 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9RCV5 CVE: CVE-2021-47479 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Syzbot reported use-after-free in rtl8712_dl_fw(). The problem was in race condition between r871xu_dev_remove() ->ndo_open() callback. It's easy to see from crash log, that driver accesses released firmware in ->ndo_open() callback. It may happen, since driver was releasing firmware _before_ unregistering netdev. Fix it by moving unregister_netdev() before cleaning up resources. Call Trace: ... rtl871x_open_fw drivers/staging/rtl8712/hal_init.c:83 [inline] rtl8712_dl_fw+0xd95/0xe10 drivers/staging/rtl8712/hal_init.c:170 rtl8712_hal_init drivers/staging/rtl8712/hal_init.c:330 [inline] rtl871x_hal_init+0xae/0x180 drivers/staging/rtl8712/hal_init.c:394 netdev_open+0xe6/0x6c0 drivers/staging/rtl8712/os_intfs.c:380 __dev_open+0x2bc/0x4d0 net/core/dev.c:1484 Freed by task 1306: ... release_firmware+0x1b/0x30 drivers/base/firmware_loader/main.c:1053 r871xu_dev_remove+0xcc/0x2c0 drivers/staging/rtl8712/usb_intf.c:599 usb_unbind_interface+0x1d8/0x8d0 drivers/usb/core/driver.c:458 Fixes: 8c213fa59199 ("staging: r8712u: Use asynchronous firmware loading") Cc: stable <stable(a)vger.kernel.org> Reported-and-tested-by: syzbot+c55162be492189fb4f51(a)syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin <paskripkin(a)gmail.com> Link: https://lore.kernel.org/r/20211019211718.26354-1-paskripkin@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/staging/rtl8712/usb_intf.c [The conflict occurs because commit b4383c971bc5("staging: rtl8712: handle firmware load failure") is not merged] Signed-off-by: Jialin Zhang <zhangjialin11(a)huawei.com> --- drivers/staging/rtl8712/usb_intf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8712/usb_intf.c b/drivers/staging/rtl8712/usb_intf.c index 5e2cdc25401b..709d687180bf 100644 --- a/drivers/staging/rtl8712/usb_intf.c +++ b/drivers/staging/rtl8712/usb_intf.c @@ -623,13 +623,13 @@ static void r871xu_dev_remove(struct usb_interface *pusb_intf) if (pnetdev) { struct _adapter *padapter = netdev_priv(pnetdev); + unregister_netdev(pnetdev); /* will call netdev_close() */ usb_set_intfdata(pusb_intf, NULL); release_firmware(padapter->fw); /* never exit with a firmware callback pending */ wait_for_completion(&padapter->rtl8712_fw_ready); if (drvpriv.drv_registered) padapter->bSurpriseRemoved = true; - unregister_netdev(pnetdev); /* will call netdev_close() */ flush_scheduled_work(); udelay(1); /* Stop driver mlme relation timer */ -- 2.25.1

2 1

[PATCH OLK-6.6] tcp: Use refcount_inc_not_zero() in tcp_twsk_unique().
by Zhengchao Shao 08 Jun '24

08 Jun '24

From: Kuniyuki Iwashima <kuniyu(a)amazon.com> stable inclusion from stable-v6.6.31 commit 6e48faad92be13166184d21506e4e54c79c13adc category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9U4LA CVE: CVE-2024-36904 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit f2db7230f73a80dbb179deab78f88a7947f0ab7e ] Anderson Nascimento reported a use-after-free splat in tcp_twsk_unique() with nice analysis. Since commit ec94c2696f0b ("tcp/dccp: avoid one atomic operation for timewait hashdance"), inet_twsk_hashdance() sets TIME-WAIT socket's sk_refcnt after putting it into ehash and releasing the bucket lock. Thus, there is a small race window where other threads could try to reuse the port during connect() and call sock_hold() in tcp_twsk_unique() for the TIME-WAIT socket with zero refcnt. If that happens, the refcnt taken by tcp_twsk_unique() is overwritten and sock_put() will cause underflow, triggering a real use-after-free somewhere else. To avoid the use-after-free, we need to use refcount_inc_not_zero() in tcp_twsk_unique() and give up on reusing the port if it returns false. [0]: refcount_t: addition on 0; use-after-free. WARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110 CPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x86_64 #1 Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023 RIP: 0010:refcount_warn_saturate+0xe5/0x110 Code: 42 8e ff 0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea 01 01 e8 7b 42 8e ff <0f> 0b c3 cc cc cc cc 48 c7 c7 50 8f b7 82 c6 05 7a 13 ea 01 01 e8 RSP: 0018:ffffc90006b43b60 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027 RDX: ffff88807be218c8 RSI: 0000000000000001 RDI: ffff88807be218c0 RBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0 R10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84 R13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0 FS: 00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0 PKRU: 55555554 Call Trace: <TASK> ? refcount_warn_saturate+0xe5/0x110 ? __warn+0x81/0x130 ? refcount_warn_saturate+0xe5/0x110 ? report_bug+0x171/0x1a0 ? refcount_warn_saturate+0xe5/0x110 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? refcount_warn_saturate+0xe5/0x110 tcp_twsk_unique+0x186/0x190 __inet_check_established+0x176/0x2d0 __inet_hash_connect+0x74/0x7d0 ? __pfx___inet_check_established+0x10/0x10 tcp_v4_connect+0x278/0x530 __inet_stream_connect+0x10f/0x3d0 inet_stream_connect+0x3a/0x60 __sys_connect+0xa8/0xd0 __x64_sys_connect+0x18/0x20 do_syscall_64+0x83/0x170 entry_SYSCALL_64_after_hwframe+0x78/0x80 RIP: 0033:0x7f62c11a885d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a3 45 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007f62c1091e58 EFLAGS: 00000296 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000020ccb004 RCX: 00007f62c11a885d RDX: 0000000000000010 RSI: 0000000020ccb000 RDI: 0000000000000003 RBP: 00007f62c1091e90 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 00007f62c10926c0 R13: ffffffffffffff88 R14: 0000000000000000 R15: 00007ffe237885b0 </TASK> Fixes: ec94c2696f0b ("tcp/dccp: avoid one atomic operation for timewait hashdance") Reported-by: Anderson Nascimento <anderson(a)allelesecurity.com> Closes: https://lore.kernel.org/netdev/37a477a6-d39e-486b-9577-3463f655a6b7@alleles… Suggested-by: Eric Dumazet <edumazet(a)google.com> Signed-off-by: Kuniyuki Iwashima <kuniyu(a)amazon.com> Reviewed-by: Eric Dumazet <edumazet(a)google.com> Link: https://lore.kernel.org/r/20240501213145.62261-1-kuniyu@amazon.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/ipv4/tcp_ipv4.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c index 39f324bdd576..fce757159ad5 100644 --- a/net/ipv4/tcp_ipv4.c +++ b/net/ipv4/tcp_ipv4.c @@ -154,6 +154,12 @@ int tcp_twsk_unique(struct sock *sk, struct sock *sktw, void *twp) if (tcptw->tw_ts_recent_stamp && (!twp || (reuse && time_after32(ktime_get_seconds(), tcptw->tw_ts_recent_stamp)))) { + /* inet_twsk_hashdance() sets sk_refcnt after putting twsk + * and releasing the bucket lock. + */ + if (unlikely(!refcount_inc_not_zero(&sktw->sk_refcnt))) + return 0; + /* In case of repair and re-using TIME-WAIT sockets we still * want to be sure that it is safe as above but honor the * sequence numbers and time stamps set as part of the repair @@ -174,7 +180,7 @@ int tcp_twsk_unique(struct sock *sk, struct sock *sktw, void *twp) tp->rx_opt.ts_recent = tcptw->tw_ts_recent; tp->rx_opt.ts_recent_stamp = tcptw->tw_ts_recent_stamp; } - sock_hold(sktw); + return 1; } -- 2.34.1

2 1

[PATCH OLK-6.6 v2] blk-iocost: do not WARN if iocg was already offlined
by Li Nan 08 Jun '24

08 Jun '24

mainline inclusion from mainline-v6.9-rc5 commit 01bc4fda9ea0a6b52f12326486f07a4910666cf6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9UABH CVE: CVE-2024-36908 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In iocg_pay_debt(), warn is triggered if 'active_list' is empty, which is intended to confirm iocg is active when it has debt. However, warn can be triggered during a blkcg or disk removal, if iocg_waitq_timer_fn() is run at that time: WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocg_pay_debt+0x14c/0x190 Call trace: iocg_pay_debt+0x14c/0x190 iocg_kick_waitq+0x438/0x4c0 iocg_waitq_timer_fn+0xd8/0x130 __run_hrtimer+0x144/0x45c __hrtimer_run_queues+0x16c/0x244 hrtimer_interrupt+0x2cc/0x7b0 The warn in this situation is meaningless. Since this iocg is being removed, the state of the 'active_list' is irrelevant, and 'waitq_timer' is canceled after removing 'active_list' in ioc_pd_free(), which ensures iocg is freed after iocg_waitq_timer_fn() returns. Therefore, add the check if iocg was already offlined to avoid warn when removing a blkcg or disk. Signed-off-by: Li Nan <linan122(a)huawei.com> Reviewed-by: Yu Kuai <yukuai3(a)huawei.com> Acked-by: Tejun Heo <tj(a)kernel.org> Link: https://lore.kernel.org/r/20240419093257.3004211-1-linan666@huaweicloud.com Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Conflict: block/blk-iocost.c Mainline checks 'pd.online', but there is no member online of pd in 5.10. Check 'iocg->online' instead. Signed-off-by: Li Nan <linan122(a)huawei.com> --- v2: fix bugzilla block/blk-iocost.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/block/blk-iocost.c b/block/blk-iocost.c index 6a3e8a21c0fc..3b9710ce77e5 100644 --- a/block/blk-iocost.c +++ b/block/blk-iocost.c @@ -1439,8 +1439,11 @@ static void iocg_pay_debt(struct ioc_gq *iocg, u64 abs_vpay, lockdep_assert_held(&iocg->ioc->lock); lockdep_assert_held(&iocg->waitq.lock); - /* make sure that nobody messed with @iocg */ - WARN_ON_ONCE(list_empty(&iocg->active_list)); + /* + * make sure that nobody messed with @iocg. Check iocg->online + * to avoid warn when removing blkcg or disk. + */ + WARN_ON_ONCE(list_empty(&iocg->active_list) && iocg->online); WARN_ON_ONCE(iocg->inuse > 1); iocg->abs_vdebt -= min(abs_vpay, iocg->abs_vdebt); -- 2.39.2

2 1

[PATCH OLK-6.6] blk-iocost: do not WARN if iocg was already offlined
by Li Nan 08 Jun '24

08 Jun '24

mainline inclusion from mainline-v6.9-rc5 commit 01bc4fda9ea0a6b52f12326486f07a4910666cf6 category: bugfix bugzilla: 189809 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In iocg_pay_debt(), warn is triggered if 'active_list' is empty, which is intended to confirm iocg is active when it has debt. However, warn can be triggered during a blkcg or disk removal, if iocg_waitq_timer_fn() is run at that time: WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocg_pay_debt+0x14c/0x190 Call trace: iocg_pay_debt+0x14c/0x190 iocg_kick_waitq+0x438/0x4c0 iocg_waitq_timer_fn+0xd8/0x130 __run_hrtimer+0x144/0x45c __hrtimer_run_queues+0x16c/0x244 hrtimer_interrupt+0x2cc/0x7b0 The warn in this situation is meaningless. Since this iocg is being removed, the state of the 'active_list' is irrelevant, and 'waitq_timer' is canceled after removing 'active_list' in ioc_pd_free(), which ensures iocg is freed after iocg_waitq_timer_fn() returns. Therefore, add the check if iocg was already offlined to avoid warn when removing a blkcg or disk. Signed-off-by: Li Nan <linan122(a)huawei.com> Reviewed-by: Yu Kuai <yukuai3(a)huawei.com> Acked-by: Tejun Heo <tj(a)kernel.org> Link: https://lore.kernel.org/r/20240419093257.3004211-1-linan666@huaweicloud.com Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Conflict: block/blk-iocost.c Mainline checks 'pd.online', but there is no member online of pd in 5.10. Check 'iocg->online' instead. Signed-off-by: Li Nan <linan122(a)huawei.com> --- block/blk-iocost.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/block/blk-iocost.c b/block/blk-iocost.c index 6a3e8a21c0fc..3b9710ce77e5 100644 --- a/block/blk-iocost.c +++ b/block/blk-iocost.c @@ -1439,8 +1439,11 @@ static void iocg_pay_debt(struct ioc_gq *iocg, u64 abs_vpay, lockdep_assert_held(&iocg->ioc->lock); lockdep_assert_held(&iocg->waitq.lock); - /* make sure that nobody messed with @iocg */ - WARN_ON_ONCE(list_empty(&iocg->active_list)); + /* + * make sure that nobody messed with @iocg. Check iocg->online + * to avoid warn when removing blkcg or disk. + */ + WARN_ON_ONCE(list_empty(&iocg->active_list) && iocg->online); WARN_ON_ONCE(iocg->inuse > 1); iocg->abs_vdebt -= min(abs_vpay, iocg->abs_vdebt); -- 2.39.2

2 1

[PATCH openEuler-22.03-LTS-SP1] blk-iocost: do not WARN if iocg was already offlined
by Li Nan 08 Jun '24

08 Jun '24

mainline inclusion from mainline-v6.9-rc5 commit 01bc4fda9ea0a6b52f12326486f07a4910666cf6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9UABH CVE: CVE-2024-36908 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In iocg_pay_debt(), warn is triggered if 'active_list' is empty, which is intended to confirm iocg is active when it has debt. However, warn can be triggered during a blkcg or disk removal, if iocg_waitq_timer_fn() is run at that time: WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocg_pay_debt+0x14c/0x190 Call trace: iocg_pay_debt+0x14c/0x190 iocg_kick_waitq+0x438/0x4c0 iocg_waitq_timer_fn+0xd8/0x130 __run_hrtimer+0x144/0x45c __hrtimer_run_queues+0x16c/0x244 hrtimer_interrupt+0x2cc/0x7b0 The warn in this situation is meaningless. Since this iocg is being removed, the state of the 'active_list' is irrelevant, and 'waitq_timer' is canceled after removing 'active_list' in ioc_pd_free(), which ensures iocg is freed after iocg_waitq_timer_fn() returns. Therefore, add the check if iocg was already offlined to avoid warn when removing a blkcg or disk. Signed-off-by: Li Nan <linan122(a)huawei.com> Reviewed-by: Yu Kuai <yukuai3(a)huawei.com> Acked-by: Tejun Heo <tj(a)kernel.org> Link: https://lore.kernel.org/r/20240419093257.3004211-1-linan666@huaweicloud.com Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Conflict: block/blk-iocost.c Mainline checks 'pd.online', but there is no member online of pd in 5.10. Check 'iocg->online' instead. Signed-off-by: Li Nan <linan122(a)huawei.com> --- block/blk-iocost.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/block/blk-iocost.c b/block/blk-iocost.c index edab843d547a..2b3bbae302e2 100644 --- a/block/blk-iocost.c +++ b/block/blk-iocost.c @@ -1401,8 +1401,11 @@ static void iocg_pay_debt(struct ioc_gq *iocg, u64 abs_vpay, lockdep_assert_held(&iocg->ioc->lock); lockdep_assert_held(&iocg->waitq.lock); - /* make sure that nobody messed with @iocg */ - WARN_ON_ONCE(list_empty(&iocg->active_list)); + /* + * make sure that nobody messed with @iocg. Check iocg->online + * to avoid warn when removing blkcg or disk. + */ + WARN_ON_ONCE(list_empty(&iocg->active_list) && iocg->online); WARN_ON_ONCE(iocg->inuse > 1); iocg->abs_vdebt -= min(abs_vpay, iocg->abs_vdebt); -- 2.39.2

2 1

[PATCH OLK-5.10] blk-iocost: do not WARN if iocg was already offlined
by Li Nan 08 Jun '24

08 Jun '24

mainline inclusion from mainline-v6.9-rc5 commit 01bc4fda9ea0a6b52f12326486f07a4910666cf6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9UABH CVE: CVE-2024-36908 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In iocg_pay_debt(), warn is triggered if 'active_list' is empty, which is intended to confirm iocg is active when it has debt. However, warn can be triggered during a blkcg or disk removal, if iocg_waitq_timer_fn() is run at that time: WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocg_pay_debt+0x14c/0x190 Call trace: iocg_pay_debt+0x14c/0x190 iocg_kick_waitq+0x438/0x4c0 iocg_waitq_timer_fn+0xd8/0x130 __run_hrtimer+0x144/0x45c __hrtimer_run_queues+0x16c/0x244 hrtimer_interrupt+0x2cc/0x7b0 The warn in this situation is meaningless. Since this iocg is being removed, the state of the 'active_list' is irrelevant, and 'waitq_timer' is canceled after removing 'active_list' in ioc_pd_free(), which ensures iocg is freed after iocg_waitq_timer_fn() returns. Therefore, add the check if iocg was already offlined to avoid warn when removing a blkcg or disk. Signed-off-by: Li Nan <linan122(a)huawei.com> Reviewed-by: Yu Kuai <yukuai3(a)huawei.com> Acked-by: Tejun Heo <tj(a)kernel.org> Link: https://lore.kernel.org/r/20240419093257.3004211-1-linan666@huaweicloud.com Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Conflict: block/blk-iocost.c Mainline checks 'pd.online', but there is no member online of pd in 5.10. Check 'iocg->online' instead. Signed-off-by: Li Nan <linan122(a)huawei.com> --- block/blk-iocost.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/block/blk-iocost.c b/block/blk-iocost.c index edab843d547a..2b3bbae302e2 100644 --- a/block/blk-iocost.c +++ b/block/blk-iocost.c @@ -1401,8 +1401,11 @@ static void iocg_pay_debt(struct ioc_gq *iocg, u64 abs_vpay, lockdep_assert_held(&iocg->ioc->lock); lockdep_assert_held(&iocg->waitq.lock); - /* make sure that nobody messed with @iocg */ - WARN_ON_ONCE(list_empty(&iocg->active_list)); + /* + * make sure that nobody messed with @iocg. Check iocg->online + * to avoid warn when removing blkcg or disk. + */ + WARN_ON_ONCE(list_empty(&iocg->active_list) && iocg->online); WARN_ON_ONCE(iocg->inuse > 1); iocg->abs_vdebt -= min(abs_vpay, iocg->abs_vdebt); -- 2.39.2

2 1

[PATCH openEuler-22.03-LTS-SP1] net/smc: avoid data corruption caused by decline
by Liu Jian 08 Jun '24

08 Jun '24

From: "D. Wythe" <alibuda(a)linux.alibaba.com> stable inclusion from stable-v5.10.203 commit 5ada292b5c504720a0acef8cae9acc62a694d19c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9R4L7 CVE: CVE-2023-52775 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit e6d71b437abc2f249e3b6a1ae1a7228e09c6e563 ] We found a data corruption issue during testing of SMC-R on Redis applications. The benchmark has a low probability of reporting a strange error as shown below. "Error: Protocol error, got "\xe2" as reply type byte" Finally, we found that the retrieved error data was as follows: 0xE2 0xD4 0xC3 0xD9 0x04 0x00 0x2C 0x20 0xA6 0x56 0x00 0x16 0x3E 0x0C 0xCB 0x04 0x02 0x01 0x00 0x00 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xE2 It is quite obvious that this is a SMC DECLINE message, which means that the applications received SMC protocol message. We found that this was caused by the following situations: client server ¦ clc proposal -------------> ¦ clc accept <------------- ¦ clc confirm -------------> wait llc confirm send llc confirm ¦failed llc confirm ¦ x------ (after 2s)timeout wait llc confirm rsp wait decline (after 1s) timeout (after 2s) timeout ¦ decline --------------> ¦ decline <-------------- As a result, a decline message was sent in the implementation, and this message was read from TCP by the already-fallback connection. This patch double the client timeout as 2x of the server value, With this simple change, the Decline messages should never cross or collide (during Confirm link timeout). This issue requires an immediate solution, since the protocol updates involve a more long-term solution. Fixes: 0fb0b02bd6fd ("net/smc: adapt SMC client code to use the LLC flow") Signed-off-by: D. Wythe <alibuda(a)linux.alibaba.com> Reviewed-by: Wen Gu <guwen(a)linux.alibaba.com> Reviewed-by: Wenjia Zhang <wenjia(a)linux.ibm.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: sanglipeng <sanglipeng1(a)jd.com> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/smc/af_smc.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c index 41cbc7c89c9d..f277e5fc8056 100644 --- a/net/smc/af_smc.c +++ b/net/smc/af_smc.c @@ -396,8 +396,12 @@ static int smcr_clnt_conf_first_link(struct smc_sock *smc) struct smc_llc_qentry *qentry; int rc; - /* receive CONFIRM LINK request from server over RoCE fabric */ - qentry = smc_llc_wait(link->lgr, NULL, SMC_LLC_WAIT_TIME, + /* Receive CONFIRM LINK request from server over RoCE fabric. + * Increasing the client's timeout by twice as much as the server's + * timeout by default can temporarily avoid decline messages of + * both sides crossing or colliding + */ + qentry = smc_llc_wait(link->lgr, NULL, 2 * SMC_LLC_WAIT_TIME, SMC_LLC_CONFIRM_LINK); if (!qentry) { struct smc_clc_msg_decline dclc; -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] PCI/PM: Drain runtime-idle callbacks before driver removal
by Jialin Zhang 08 Jun '24

08 Jun '24

From: "Rafael J. Wysocki" <rafael.j.wysocki(a)intel.com> stable inclusion from stable-v4.19.312 commit 9a87375bb586515c0af63d5dcdcd58ec4acf20a6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q91J CVE: CVE-2024-35809 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 9d5286d4e7f68beab450deddbb6a32edd5ecf4bf ] A race condition between the .runtime_idle() callback and the .remove() callback in the rtsx_pcr PCI driver leads to a kernel crash due to an unhandled page fault [1]. The problem is that rtsx_pci_runtime_idle() is not expected to be running after pm_runtime_get_sync() has been called, but the latter doesn't really guarantee that. It only guarantees that the suspend and resume callbacks will not be running when it returns. However, if a .runtime_idle() callback is already running when pm_runtime_get_sync() is called, the latter will notice that the runtime PM status of the device is RPM_ACTIVE and it will return right away without waiting for the former to complete. In fact, it cannot wait for .runtime_idle() to complete because it may be called from that callback (it arguably does not make much sense to do that, but it is not strictly prohibited). Thus in general, whoever is providing a .runtime_idle() callback needs to protect it from running in parallel with whatever code runs after pm_runtime_get_sync(). [Note that .runtime_idle() will not start after pm_runtime_get_sync() has returned, but it may continue running then if it has started earlier.] One way to address that race condition is to call pm_runtime_barrier() after pm_runtime_get_sync() (not before it, because a nonzero value of the runtime PM usage counter is necessary to prevent runtime PM callbacks from being invoked) to wait for the .runtime_idle() callback to complete should it be running at that point. A suitable place for doing that is in pci_device_remove() which calls pm_runtime_get_sync() before removing the driver, so it may as well call pm_runtime_barrier() subsequently, which will prevent the race in question from occurring, not just in the rtsx_pcr driver, but in any PCI drivers providing .runtime_idle() callbacks. Link: https://lore.kernel.org/lkml/20240229062201.49500-1-kai.heng.feng@canonical… # [1] Link: https://lore.kernel.org/r/5761426.DvuYhMxLoT@kreacher Reported-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Tested-by: Ricky Wu <ricky_wu(a)realtek.com> Acked-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: drivers/pci/pci-driver.c [The conflict occurs because commit 064300ccb0e2("PCI: Drop pci_device_remove() test of pci_dev->driver") is not merged] Signed-off-by: Jialin Zhang <zhangjialin11(a)huawei.com> --- drivers/pci/pci-driver.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c index 9329f4881d42..dc33bad9f106 100644 --- a/drivers/pci/pci-driver.c +++ b/drivers/pci/pci-driver.c @@ -442,6 +442,13 @@ static int pci_device_remove(struct device *dev) if (drv) { if (drv->remove) { pm_runtime_get_sync(dev); + /* + * If the driver provides a .runtime_idle() callback and it has + * started to run already, it may continue to run in parallel + * with the code below, so wait until all of the runtime PM + * activity has completed. + */ + pm_runtime_barrier(dev); drv->remove(pci_dev); pm_runtime_put_noidle(dev); } -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] PCI/PM: Drain runtime-idle callbacks before driver removal
by Jialin Zhang 08 Jun '24

08 Jun '24

From: "Rafael J. Wysocki" <rafael.j.wysocki(a)intel.com> stable inclusion from stable-v5.10.215 commit bbe068b24409ef740657215605284fc7cdddd491 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q91J CVE: CVE-2024-35809 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 9d5286d4e7f68beab450deddbb6a32edd5ecf4bf ] A race condition between the .runtime_idle() callback and the .remove() callback in the rtsx_pcr PCI driver leads to a kernel crash due to an unhandled page fault [1]. The problem is that rtsx_pci_runtime_idle() is not expected to be running after pm_runtime_get_sync() has been called, but the latter doesn't really guarantee that. It only guarantees that the suspend and resume callbacks will not be running when it returns. However, if a .runtime_idle() callback is already running when pm_runtime_get_sync() is called, the latter will notice that the runtime PM status of the device is RPM_ACTIVE and it will return right away without waiting for the former to complete. In fact, it cannot wait for .runtime_idle() to complete because it may be called from that callback (it arguably does not make much sense to do that, but it is not strictly prohibited). Thus in general, whoever is providing a .runtime_idle() callback needs to protect it from running in parallel with whatever code runs after pm_runtime_get_sync(). [Note that .runtime_idle() will not start after pm_runtime_get_sync() has returned, but it may continue running then if it has started earlier.] One way to address that race condition is to call pm_runtime_barrier() after pm_runtime_get_sync() (not before it, because a nonzero value of the runtime PM usage counter is necessary to prevent runtime PM callbacks from being invoked) to wait for the .runtime_idle() callback to complete should it be running at that point. A suitable place for doing that is in pci_device_remove() which calls pm_runtime_get_sync() before removing the driver, so it may as well call pm_runtime_barrier() subsequently, which will prevent the race in question from occurring, not just in the rtsx_pcr driver, but in any PCI drivers providing .runtime_idle() callbacks. Link: https://lore.kernel.org/lkml/20240229062201.49500-1-kai.heng.feng@canonical… # [1] Link: https://lore.kernel.org/r/5761426.DvuYhMxLoT@kreacher Reported-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Tested-by: Ricky Wu <ricky_wu(a)realtek.com> Acked-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: drivers/pci/pci-driver.c [The conflict occurs because commit 39f7310eaa79("PCI: Drop pci_device_remove() test of pci_dev->driver") is not merged] Signed-off-by: Jialin Zhang <zhangjialin11(a)huawei.com> --- drivers/pci/pci-driver.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c index 79aa5a4b61c5..b740a7dc7fcd 100644 --- a/drivers/pci/pci-driver.c +++ b/drivers/pci/pci-driver.c @@ -447,6 +447,13 @@ static int pci_device_remove(struct device *dev) if (drv) { if (drv->remove) { pm_runtime_get_sync(dev); + /* + * If the driver provides a .runtime_idle() callback and it has + * started to run already, it may continue to run in parallel + * with the code below, so wait until all of the runtime PM + * activity has completed. + */ + pm_runtime_barrier(dev); drv->remove(pci_dev); pm_runtime_put_noidle(dev); } -- 2.25.1

2 1

[PATCH OLK-5.10] PCI/PM: Drain runtime-idle callbacks before driver removal
by Jialin Zhang 08 Jun '24

08 Jun '24

From: "Rafael J. Wysocki" <rafael.j.wysocki(a)intel.com> stable inclusion from stable-v5.10.215 commit bbe068b24409ef740657215605284fc7cdddd491 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q91J CVE: CVE-2024-35809 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 9d5286d4e7f68beab450deddbb6a32edd5ecf4bf ] A race condition between the .runtime_idle() callback and the .remove() callback in the rtsx_pcr PCI driver leads to a kernel crash due to an unhandled page fault [1]. The problem is that rtsx_pci_runtime_idle() is not expected to be running after pm_runtime_get_sync() has been called, but the latter doesn't really guarantee that. It only guarantees that the suspend and resume callbacks will not be running when it returns. However, if a .runtime_idle() callback is already running when pm_runtime_get_sync() is called, the latter will notice that the runtime PM status of the device is RPM_ACTIVE and it will return right away without waiting for the former to complete. In fact, it cannot wait for .runtime_idle() to complete because it may be called from that callback (it arguably does not make much sense to do that, but it is not strictly prohibited). Thus in general, whoever is providing a .runtime_idle() callback needs to protect it from running in parallel with whatever code runs after pm_runtime_get_sync(). [Note that .runtime_idle() will not start after pm_runtime_get_sync() has returned, but it may continue running then if it has started earlier.] One way to address that race condition is to call pm_runtime_barrier() after pm_runtime_get_sync() (not before it, because a nonzero value of the runtime PM usage counter is necessary to prevent runtime PM callbacks from being invoked) to wait for the .runtime_idle() callback to complete should it be running at that point. A suitable place for doing that is in pci_device_remove() which calls pm_runtime_get_sync() before removing the driver, so it may as well call pm_runtime_barrier() subsequently, which will prevent the race in question from occurring, not just in the rtsx_pcr driver, but in any PCI drivers providing .runtime_idle() callbacks. Link: https://lore.kernel.org/lkml/20240229062201.49500-1-kai.heng.feng@canonical… # [1] Link: https://lore.kernel.org/r/5761426.DvuYhMxLoT@kreacher Reported-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Tested-by: Ricky Wu <ricky_wu(a)realtek.com> Acked-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: drivers/pci/pci-driver.c [The conflict occurs because commit 39f7310eaa79("PCI: Drop pci_device_remove() test of pci_dev->driver") is not merged] Signed-off-by: Jialin Zhang <zhangjialin11(a)huawei.com> --- drivers/pci/pci-driver.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c index 6eaaf4231635..606e4a083337 100644 --- a/drivers/pci/pci-driver.c +++ b/drivers/pci/pci-driver.c @@ -447,6 +447,13 @@ static int pci_device_remove(struct device *dev) if (drv) { if (drv->remove) { pm_runtime_get_sync(dev); + /* + * If the driver provides a .runtime_idle() callback and it has + * started to run already, it may continue to run in parallel + * with the code below, so wait until all of the runtime PM + * activity has completed. + */ + pm_runtime_barrier(dev); drv->remove(pci_dev); pm_runtime_put_noidle(dev); } -- 2.25.1

2 1

[PATCH OLK-5.10 0/2] CVE
by liwei 08 Jun '24

08 Jun '24

CVE-2024-35830 CVE-2024-36919 Alexander Stein (1): media: tc358743: register v4l2 async device only after successful setup Saurav Kashyap (1): scsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload drivers/media/i2c/tc358743.c | 7 ++++--- drivers/scsi/bnx2fc/bnx2fc_tgt.c | 2 -- 2 files changed, 4 insertions(+), 5 deletions(-) -- 2.25.1

2 3

[PATCH openEuler-22.03-LTS-SP1 0/2] CVE
by liwei 08 Jun '24

08 Jun '24

CVE-2024-35830 CVE-2024-36919 Alexander Stein (1): media: tc358743: register v4l2 async device only after successful setup Saurav Kashyap (1): scsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload drivers/media/i2c/tc358743.c | 7 ++++--- drivers/scsi/bnx2fc/bnx2fc_tgt.c | 2 -- 2 files changed, 4 insertions(+), 5 deletions(-) -- 2.25.1

2 3

[PATCH OLK-6.6] scsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload
by liwei 08 Jun '24

08 Jun '24

From: Saurav Kashyap <skashyap(a)marvell.com> mainline inclusion from mainline-v6.9-rc2 commit c214ed2a4dda35b308b0b28eed804d7ae66401f9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9U91D CVE: CVE-2024-36919 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The session resources are used by FW and driver when session is offloaded, once session is uploaded these resources are not used. The lock is not required as these fields won't be used any longer. The offload and upload calls are sequential, hence lock is not required. This will suppress following BUG_ON(): [ 449.843143] ------------[ cut here ]------------ [ 449.848302] kernel BUG at mm/vmalloc.c:2727! [ 449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x86_64 #1 Rebooting. [ 449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016 [ 449.876966] Workqueue: fc_rport_eq fc_rport_work [libfc] [ 449.882910] RIP: 0010:vunmap+0x2e/0x30 [ 449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 <0f> 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41 [ 449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206 [ 449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005 [ 449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000 [ 449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf [ 449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000 [ 449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0 [ 449.953701] FS: 0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000 [ 449.962732] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0 [ 449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 449.993028] Call Trace: [ 449.995756] __iommu_dma_free+0x96/0x100 [ 450.000139] bnx2fc_free_session_resc+0x67/0x240 [bnx2fc] [ 450.006171] bnx2fc_upload_session+0xce/0x100 [bnx2fc] [ 450.011910] bnx2fc_rport_event_handler+0x9f/0x240 [bnx2fc] [ 450.018136] fc_rport_work+0x103/0x5b0 [libfc] [ 450.023103] process_one_work+0x1e8/0x3c0 [ 450.027581] worker_thread+0x50/0x3b0 [ 450.031669] ? rescuer_thread+0x370/0x370 [ 450.036143] kthread+0x149/0x170 [ 450.039744] ? set_kthread_struct+0x40/0x40 [ 450.044411] ret_from_fork+0x22/0x30 [ 450.048404] Modules linked in: vfat msdos fat xfs nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver dm_service_time qedf qed crc8 bnx2fc libfcoe libfc scsi_transport_fc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp dcdbas rapl intel_cstate intel_uncore mei_me pcspkr mei ipmi_ssif lpc_ich ipmi_si fuse zram ext4 mbcache jbd2 loop nfsv3 nfs_acl nfs lockd grace fscache netfs irdma ice sd_mod t10_pi sg ib_uverbs ib_core 8021q garp mrp stp llc mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi fb_sys_fops cec crct10dif_pclmul ahci crc32_pclmul bnx2x drm ghash_clmulni_intel libahci rfkill i40e libata megaraid_sas mdio wmi sunrpc lrw dm_crypt dm_round_robin dm_multipath dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_zero dm_mod linear raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid6_pq libcrc32c crc32c_intel raid1 raid0 iscsi_ibft squashfs be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls [ 450.048497] libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi edd ipmi_devintf ipmi_msghandler [ 450.159753] ---[ end trace 712de2c57c64abc8 ]--- Reported-by: Guangwu Zhang <guazhang(a)redhat.com> Signed-off-by: Saurav Kashyap <skashyap(a)marvell.com> Signed-off-by: Nilesh Javali <njavali(a)marvell.com> Link: https://lore.kernel.org/r/20240315071427.31842-1-skashyap@marvell.com Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: liwei <liwei728(a)huawei.com> --- drivers/scsi/bnx2fc/bnx2fc_tgt.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/scsi/bnx2fc/bnx2fc_tgt.c b/drivers/scsi/bnx2fc/bnx2fc_tgt.c index 2c246e80c1c4..d91659811eb3 100644 --- a/drivers/scsi/bnx2fc/bnx2fc_tgt.c +++ b/drivers/scsi/bnx2fc/bnx2fc_tgt.c @@ -833,7 +833,6 @@ static void bnx2fc_free_session_resc(struct bnx2fc_hba *hba, BNX2FC_TGT_DBG(tgt, "Freeing up session resources\n"); - spin_lock_bh(&tgt->cq_lock); ctx_base_ptr = tgt->ctx_base; tgt->ctx_base = NULL; @@ -889,7 +888,6 @@ static void bnx2fc_free_session_resc(struct bnx2fc_hba *hba, tgt->sq, tgt->sq_dma); tgt->sq = NULL; } - spin_unlock_bh(&tgt->cq_lock); if (ctx_base_ptr) iounmap(ctx_base_ptr); -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS 0/3] CVE
by liwei 08 Jun '24

08 Jun '24

CVE-2024-35830 CVE-2024-36919 CVE-2021-47288 Alexander Stein (1): media: tc358743: register v4l2 async device only after successful setup Gustavo A. R. Silva (1): media: ngene: Fix out-of-bounds bug in ngene_command_config_free_buf() Saurav Kashyap (1): scsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload drivers/media/i2c/tc358743.c | 7 ++++--- drivers/media/pci/ngene/ngene-core.c | 2 +- drivers/media/pci/ngene/ngene.h | 14 ++++++++------ drivers/scsi/bnx2fc/bnx2fc_tgt.c | 2 -- 4 files changed, 13 insertions(+), 12 deletions(-) -- 2.25.1

2 4

[PATCH openEuler-1.0-LTS] ipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action()
by Zhengchao Shao 08 Jun '24

08 Jun '24

From: Eric Dumazet <edumazet(a)google.com> stable inclusion from stable-v4.19.314 commit 4a5a573387da6a6b23a4cc62147453ff1bc32afa category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9TM8A CVE: CVE-2024-36902 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit d101291b2681e5ab938554e3e323f7a7ee33e3aa ] syzbot is able to trigger the following crash [1], caused by unsafe ip6_dst_idev() use. Indeed ip6_dst_idev() can return NULL, and must always be checked. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c:237 [inline] RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267 Code: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 <42> 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c RSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700 RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760 RBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd R10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000 R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00 FS: 00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317 fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108 ip6_route_output_flags_noref net/ipv6/route.c:2637 [inline] ip6_route_output_flags+0x38e/0x610 net/ipv6/route.c:2649 ip6_route_output include/net/ip6_route.h:93 [inline] ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120 ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250 sctp_v6_get_dst+0x792/0x1e20 net/sctp/ipv6.c:326 sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455 sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662 sctp_connect_new_asoc+0x31d/0x6c0 net/sctp/socket.c:1099 __sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 5e5f3f0f8013 ("[IPV6] ADDRCONF: Convert ipv6_get_saddr() to ipv6_dev_get_saddr().") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Reviewed-by: David Ahern <dsahern(a)kernel.org> Link: https://lore.kernel.org/r/20240507163145.835254-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/ipv6/fib6_rules.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/net/ipv6/fib6_rules.c b/net/ipv6/fib6_rules.c index f590446595d8..19ab1a26e3d6 100644 --- a/net/ipv6/fib6_rules.c +++ b/net/ipv6/fib6_rules.c @@ -232,8 +232,12 @@ static int __fib6_rule_action(struct fib_rule *rule, struct flowi *flp, rt = lookup(net, table, flp6, arg->lookup_data, flags); if (rt != net->ipv6.ip6_null_entry) { + struct inet6_dev *idev = ip6_dst_idev(&rt->dst); + + if (!idev) + goto again; err = fib6_rule_saddr(net, rule, flags, flp6, - ip6_dst_idev(&rt->dst)->dev); + idev->dev); if (err == -EAGAIN) goto again; -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] ipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action()
by Zhengchao Shao 08 Jun '24

08 Jun '24

From: Eric Dumazet <edumazet(a)google.com> stable inclusion from stable-v5.10.217 commit 674c951ab8a23f7aff9b4c3f2f865901bc76a290 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9TM8A CVE: CVE-2024-36902 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit d101291b2681e5ab938554e3e323f7a7ee33e3aa ] syzbot is able to trigger the following crash [1], caused by unsafe ip6_dst_idev() use. Indeed ip6_dst_idev() can return NULL, and must always be checked. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c:237 [inline] RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267 Code: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 <42> 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c RSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700 RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760 RBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd R10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000 R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00 FS: 00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317 fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108 ip6_route_output_flags_noref net/ipv6/route.c:2637 [inline] ip6_route_output_flags+0x38e/0x610 net/ipv6/route.c:2649 ip6_route_output include/net/ip6_route.h:93 [inline] ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120 ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250 sctp_v6_get_dst+0x792/0x1e20 net/sctp/ipv6.c:326 sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455 sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662 sctp_connect_new_asoc+0x31d/0x6c0 net/sctp/socket.c:1099 __sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 5e5f3f0f8013 ("[IPV6] ADDRCONF: Convert ipv6_get_saddr() to ipv6_dev_get_saddr().") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Reviewed-by: David Ahern <dsahern(a)kernel.org> Link: https://lore.kernel.org/r/20240507163145.835254-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/ipv6/fib6_rules.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/net/ipv6/fib6_rules.c b/net/ipv6/fib6_rules.c index 3e4c87b29b11..a4276e40a429 100644 --- a/net/ipv6/fib6_rules.c +++ b/net/ipv6/fib6_rules.c @@ -232,8 +232,12 @@ static int __fib6_rule_action(struct fib_rule *rule, struct flowi *flp, rt = pol_lookup_func(lookup, net, table, flp6, arg->lookup_data, flags); if (rt != net->ipv6.ip6_null_entry) { + struct inet6_dev *idev = ip6_dst_idev(&rt->dst); + + if (!idev) + goto again; err = fib6_rule_saddr(net, rule, flags, flp6, - ip6_dst_idev(&rt->dst)->dev); + idev->dev); if (err == -EAGAIN) goto again; -- 2.34.1

2 1

[PATCH OLK-5.10] ipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action()
by Zhengchao Shao 08 Jun '24

08 Jun '24

From: Eric Dumazet <edumazet(a)google.com> stable inclusion from stable-v5.10.217 commit 674c951ab8a23f7aff9b4c3f2f865901bc76a290 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9TM8A CVE: CVE-2024-36902 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit d101291b2681e5ab938554e3e323f7a7ee33e3aa ] syzbot is able to trigger the following crash [1], caused by unsafe ip6_dst_idev() use. Indeed ip6_dst_idev() can return NULL, and must always be checked. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c:237 [inline] RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267 Code: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 <42> 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c RSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700 RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760 RBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd R10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000 R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00 FS: 00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317 fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108 ip6_route_output_flags_noref net/ipv6/route.c:2637 [inline] ip6_route_output_flags+0x38e/0x610 net/ipv6/route.c:2649 ip6_route_output include/net/ip6_route.h:93 [inline] ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120 ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250 sctp_v6_get_dst+0x792/0x1e20 net/sctp/ipv6.c:326 sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455 sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662 sctp_connect_new_asoc+0x31d/0x6c0 net/sctp/socket.c:1099 __sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 5e5f3f0f8013 ("[IPV6] ADDRCONF: Convert ipv6_get_saddr() to ipv6_dev_get_saddr().") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Reviewed-by: David Ahern <dsahern(a)kernel.org> Link: https://lore.kernel.org/r/20240507163145.835254-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/ipv6/fib6_rules.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/net/ipv6/fib6_rules.c b/net/ipv6/fib6_rules.c index 3e4c87b29b11..a4276e40a429 100644 --- a/net/ipv6/fib6_rules.c +++ b/net/ipv6/fib6_rules.c @@ -232,8 +232,12 @@ static int __fib6_rule_action(struct fib_rule *rule, struct flowi *flp, rt = pol_lookup_func(lookup, net, table, flp6, arg->lookup_data, flags); if (rt != net->ipv6.ip6_null_entry) { + struct inet6_dev *idev = ip6_dst_idev(&rt->dst); + + if (!idev) + goto again; err = fib6_rule_saddr(net, rule, flags, flp6, - ip6_dst_idev(&rt->dst)->dev); + idev->dev); if (err == -EAGAIN) goto again; -- 2.34.1

2 1

[PATCH OLK-6.6] ipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action()
by Zhengchao Shao 08 Jun '24

08 Jun '24

From: Eric Dumazet <edumazet(a)google.com> stable inclusion from stable-v6.6.31 commit 8745a8d74ba17dafe72b6ab461fa6c007d879747 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9TM8A CVE: CVE-2024-36902 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit d101291b2681e5ab938554e3e323f7a7ee33e3aa ] syzbot is able to trigger the following crash [1], caused by unsafe ip6_dst_idev() use. Indeed ip6_dst_idev() can return NULL, and must always be checked. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c:237 [inline] RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267 Code: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 <42> 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c RSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700 RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760 RBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd R10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000 R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00 FS: 00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317 fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108 ip6_route_output_flags_noref net/ipv6/route.c:2637 [inline] ip6_route_output_flags+0x38e/0x610 net/ipv6/route.c:2649 ip6_route_output include/net/ip6_route.h:93 [inline] ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120 ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250 sctp_v6_get_dst+0x792/0x1e20 net/sctp/ipv6.c:326 sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455 sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662 sctp_connect_new_asoc+0x31d/0x6c0 net/sctp/socket.c:1099 __sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 5e5f3f0f8013 ("[IPV6] ADDRCONF: Convert ipv6_get_saddr() to ipv6_dev_get_saddr().") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Reviewed-by: David Ahern <dsahern(a)kernel.org> Link: https://lore.kernel.org/r/20240507163145.835254-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/ipv6/fib6_rules.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/net/ipv6/fib6_rules.c b/net/ipv6/fib6_rules.c index be52b18e08a6..6eeab21512ba 100644 --- a/net/ipv6/fib6_rules.c +++ b/net/ipv6/fib6_rules.c @@ -233,8 +233,12 @@ static int __fib6_rule_action(struct fib_rule *rule, struct flowi *flp, rt = pol_lookup_func(lookup, net, table, flp6, arg->lookup_data, flags); if (rt != net->ipv6.ip6_null_entry) { + struct inet6_dev *idev = ip6_dst_idev(&rt->dst); + + if (!idev) + goto again; err = fib6_rule_saddr(net, rule, flags, flp6, - ip6_dst_idev(&rt->dst)->dev); + idev->dev); if (err == -EAGAIN) goto again; -- 2.34.1

2 1

[openeuler:openEuler-1.0-LTS 18949/22827] mm/khugepaged.c:974:21: sparse: sparse: invalid assignment: |=
by kernel test robot 08 Jun '24

08 Jun '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 6a98543755cf2f636ae3169f3774d226d328d2cf commit: ff0fb9e816fac221fa24a1810dd895745406070b [18949/22827] mm: thp: Add memory reliable support for hugepaged collapse config: arm64-randconfig-r123-20240607 (https://download.01.org/0day-ci/archive/20240608/202406081538.GZO9E4bP-lkp@…) compiler: aarch64-linux-gcc (GCC) 13.2.0 reproduce: (https://download.01.org/0day-ci/archive/20240608/202406081538.GZO9E4bP-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202406081538.GZO9E4bP-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) >> mm/khugepaged.c:974:21: sparse: sparse: invalid assignment: |= mm/khugepaged.c:974:21: sparse: left side has type restricted gfp_t mm/khugepaged.c:974:21: sparse: right side has type unsigned int mm/khugepaged.c:1352:21: sparse: sparse: invalid assignment: |= mm/khugepaged.c:1352:21: sparse: left side has type restricted gfp_t mm/khugepaged.c:1352:21: sparse: right side has type unsigned int mm/khugepaged.c:1378:9: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void **slot @@ got void [noderef] <asn:4> ** @@ mm/khugepaged.c:1378:9: sparse: expected void **slot mm/khugepaged.c:1378:9: sparse: got void [noderef] <asn:4> ** mm/khugepaged.c:1378:9: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void **slot @@ got void [noderef] <asn:4> ** @@ mm/khugepaged.c:1378:9: sparse: expected void **slot mm/khugepaged.c:1378:9: sparse: got void [noderef] <asn:4> ** mm/khugepaged.c:1409:56: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void [noderef] <asn:4> **slot @@ got void **slot @@ mm/khugepaged.c:1409:56: sparse: expected void [noderef] <asn:4> **slot mm/khugepaged.c:1409:56: sparse: got void **slot mm/khugepaged.c:1458:22: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void **slot @@ got void [noderef] <asn:4> ** @@ mm/khugepaged.c:1458:22: sparse: expected void **slot mm/khugepaged.c:1458:22: sparse: got void [noderef] <asn:4> ** mm/khugepaged.c:1459:17: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void [noderef] <asn:4> **slot @@ got void **slot @@ mm/khugepaged.c:1459:17: sparse: expected void [noderef] <asn:4> **slot mm/khugepaged.c:1459:17: sparse: got void **slot mm/khugepaged.c:1483:60: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void [noderef] <asn:4> **slot @@ got void **slot @@ mm/khugepaged.c:1483:60: sparse: expected void [noderef] <asn:4> **slot mm/khugepaged.c:1483:60: sparse: got void **slot mm/khugepaged.c:1486:47: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void [noderef] <asn:4> **slot @@ got void **slot @@ mm/khugepaged.c:1486:47: sparse: expected void [noderef] <asn:4> **slot mm/khugepaged.c:1486:47: sparse: got void **slot mm/khugepaged.c:1486:22: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void **slot @@ got void [noderef] <asn:4> ** @@ mm/khugepaged.c:1486:22: sparse: expected void **slot mm/khugepaged.c:1486:22: sparse: got void [noderef] <asn:4> ** mm/khugepaged.c:1378:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void [noderef] <asn:4> **slot @@ got void **slot @@ mm/khugepaged.c:1378:9: sparse: expected void [noderef] <asn:4> **slot mm/khugepaged.c:1378:9: sparse: got void **slot mm/khugepaged.c:1378:9: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void **slot @@ got void [noderef] <asn:4> ** @@ mm/khugepaged.c:1378:9: sparse: expected void **slot mm/khugepaged.c:1378:9: sparse: got void [noderef] <asn:4> ** mm/khugepaged.c:1578:17: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void **slot @@ got void [noderef] <asn:4> ** @@ mm/khugepaged.c:1578:17: sparse: expected void **slot mm/khugepaged.c:1578:17: sparse: got void [noderef] <asn:4> ** mm/khugepaged.c:1578:17: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void **slot @@ got void [noderef] <asn:4> ** @@ mm/khugepaged.c:1578:17: sparse: expected void **slot mm/khugepaged.c:1578:17: sparse: got void [noderef] <asn:4> ** mm/khugepaged.c:1597:68: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void [noderef] <asn:4> **slot @@ got void **slot @@ mm/khugepaged.c:1597:68: sparse: expected void [noderef] <asn:4> **slot mm/khugepaged.c:1597:68: sparse: got void **slot mm/khugepaged.c:1598:55: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void [noderef] <asn:4> **slot @@ got void **slot @@ mm/khugepaged.c:1598:55: sparse: expected void [noderef] <asn:4> **slot mm/khugepaged.c:1598:55: sparse: got void **slot mm/khugepaged.c:1598:30: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void **slot @@ got void [noderef] <asn:4> ** @@ mm/khugepaged.c:1598:30: sparse: expected void **slot mm/khugepaged.c:1598:30: sparse: got void [noderef] <asn:4> ** mm/khugepaged.c:1578:17: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void [noderef] <asn:4> **slot @@ got void **slot @@ mm/khugepaged.c:1578:17: sparse: expected void [noderef] <asn:4> **slot mm/khugepaged.c:1578:17: sparse: got void **slot mm/khugepaged.c:1578:17: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void **slot @@ got void [noderef] <asn:4> ** @@ mm/khugepaged.c:1578:17: sparse: expected void **slot mm/khugepaged.c:1578:17: sparse: got void [noderef] <asn:4> ** mm/khugepaged.c:1633:9: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void **slot @@ got void [noderef] <asn:4> ** @@ mm/khugepaged.c:1633:9: sparse: expected void **slot mm/khugepaged.c:1633:9: sparse: got void [noderef] <asn:4> ** mm/khugepaged.c:1633:9: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void **slot @@ got void [noderef] <asn:4> ** @@ mm/khugepaged.c:1633:9: sparse: expected void **slot mm/khugepaged.c:1633:9: sparse: got void [noderef] <asn:4> ** mm/khugepaged.c:1637:46: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void [noderef] <asn:4> **slot @@ got void **slot @@ mm/khugepaged.c:1637:46: sparse: expected void [noderef] <asn:4> **slot mm/khugepaged.c:1637:46: sparse: got void **slot mm/khugepaged.c:1639:30: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void **slot @@ got void [noderef] <asn:4> ** @@ mm/khugepaged.c:1639:30: sparse: expected void **slot mm/khugepaged.c:1639:30: sparse: got void [noderef] <asn:4> ** mm/khugepaged.c:1682:55: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void [noderef] <asn:4> **slot @@ got void **slot @@ mm/khugepaged.c:1682:55: sparse: expected void [noderef] <asn:4> **slot mm/khugepaged.c:1682:55: sparse: got void **slot mm/khugepaged.c:1682:30: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void **slot @@ got void [noderef] <asn:4> ** @@ mm/khugepaged.c:1682:30: sparse: expected void **slot mm/khugepaged.c:1682:30: sparse: got void [noderef] <asn:4> ** mm/khugepaged.c:1633:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void [noderef] <asn:4> **slot @@ got void **slot @@ mm/khugepaged.c:1633:9: sparse: expected void [noderef] <asn:4> **slot mm/khugepaged.c:1633:9: sparse: got void **slot mm/khugepaged.c:1633:9: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void **slot @@ got void [noderef] <asn:4> ** @@ mm/khugepaged.c:1633:9: sparse: expected void **slot mm/khugepaged.c:1633:9: sparse: got void [noderef] <asn:4> ** mm/khugepaged.c: note: in included file (through include/linux/mm.h): include/linux/gfp.h:457:34: sparse: sparse: restricted gfp_t degrades to integer mm/khugepaged.c:1336: warning: Function parameter or member 'mm' not described in 'collapse_shmem' mm/khugepaged.c:1336: warning: Function parameter or member 'mapping' not described in 'collapse_shmem' mm/khugepaged.c:1336: warning: Function parameter or member 'start' not described in 'collapse_shmem' mm/khugepaged.c:1336: warning: Function parameter or member 'hpage' not described in 'collapse_shmem' mm/khugepaged.c:1336: warning: Function parameter or member 'node' not described in 'collapse_shmem' mm/khugepaged.c:1336: warning: Function parameter or member 'reliable' not described in 'collapse_shmem' vim +974 mm/khugepaged.c 949 950 static void collapse_huge_page(struct mm_struct *mm, 951 unsigned long address, 952 struct page **hpage, 953 int node, int referenced, int unmapped, 954 bool reliable) 955 { 956 pmd_t *pmd, _pmd; 957 pte_t *pte; 958 pgtable_t pgtable; 959 struct page *new_page; 960 spinlock_t *pmd_ptl, *pte_ptl; 961 int isolated = 0, result = 0; 962 struct mem_cgroup *memcg; 963 struct vm_area_struct *vma; 964 unsigned long mmun_start; /* For mmu_notifiers */ 965 unsigned long mmun_end; /* For mmu_notifiers */ 966 gfp_t gfp; 967 968 VM_BUG_ON(address & ~HPAGE_PMD_MASK); 969 970 /* Only allocate from the target node */ 971 gfp = alloc_hugepage_khugepaged_gfpmask() | __GFP_THISNODE; 972 973 if (reliable) > 974 gfp |= ___GFP_RELIABILITY; 975 976 /* 977 * Before allocating the hugepage, release the mmap_sem read lock. 978 * The allocation can take potentially a long time if it involves 979 * sync compaction, and we do not need to hold the mmap_sem during 980 * that. We will recheck the vma after taking it again in write mode. 981 */ 982 up_read(&mm->mmap_sem); 983 new_page = khugepaged_alloc_page(hpage, gfp, node); 984 if (!new_page) { 985 result = SCAN_ALLOC_HUGE_PAGE_FAIL; 986 goto out_nolock; 987 } 988 989 if (unlikely(mem_cgroup_try_charge(new_page, mm, gfp, &memcg, true))) { 990 result = SCAN_CGROUP_CHARGE_FAIL; 991 goto out_nolock; 992 } 993 994 down_read(&mm->mmap_sem); 995 result = hugepage_vma_revalidate(mm, address, &vma); 996 if (result) { 997 mem_cgroup_cancel_charge(new_page, memcg, true); 998 up_read(&mm->mmap_sem); 999 goto out_nolock; 1000 } 1001 1002 pmd = mm_find_pmd(mm, address); 1003 if (!pmd) { 1004 result = SCAN_PMD_NULL; 1005 mem_cgroup_cancel_charge(new_page, memcg, true); 1006 up_read(&mm->mmap_sem); 1007 goto out_nolock; 1008 } 1009 1010 /* 1011 * __collapse_huge_page_swapin always returns with mmap_sem locked. 1012 * If it fails, we release mmap_sem and jump out_nolock. 1013 * Continuing to collapse causes inconsistency. 1014 */ 1015 if (unmapped && !__collapse_huge_page_swapin(mm, vma, address, 1016 pmd, referenced)) { 1017 mem_cgroup_cancel_charge(new_page, memcg, true); 1018 up_read(&mm->mmap_sem); 1019 goto out_nolock; 1020 } 1021 1022 up_read(&mm->mmap_sem); 1023 /* 1024 * Prevent all access to pagetables with the exception of 1025 * gup_fast later handled by the ptep_clear_flush and the VM 1026 * handled by the anon_vma lock + PG_lock. 1027 */ 1028 down_write(&mm->mmap_sem); 1029 result = hugepage_vma_revalidate(mm, address, &vma); 1030 if (result) 1031 goto out; 1032 /* check if the pmd is still valid */ 1033 if (mm_find_pmd(mm, address) != pmd) 1034 goto out; 1035 1036 anon_vma_lock_write(vma->anon_vma); 1037 1038 pte = pte_offset_map(pmd, address); 1039 pte_ptl = pte_lockptr(mm, pmd); 1040 1041 mmun_start = address; 1042 mmun_end = address + HPAGE_PMD_SIZE; 1043 mmu_notifier_invalidate_range_start(mm, mmun_start, mmun_end); 1044 pmd_ptl = pmd_lock(mm, pmd); /* probably unnecessary */ 1045 /* 1046 * After this gup_fast can't run anymore. This also removes 1047 * any huge TLB entry from the CPU so we won't allow 1048 * huge and small TLB entries for the same virtual address 1049 * to avoid the risk of CPU bugs in that area. 1050 */ 1051 _pmd = pmdp_collapse_flush(vma, address, pmd); 1052 spin_unlock(pmd_ptl); 1053 mmu_notifier_invalidate_range_end(mm, mmun_start, mmun_end); 1054 1055 spin_lock(pte_ptl); 1056 isolated = __collapse_huge_page_isolate(vma, address, pte); 1057 spin_unlock(pte_ptl); 1058 1059 if (unlikely(!isolated)) { 1060 pte_unmap(pte); 1061 spin_lock(pmd_ptl); 1062 BUG_ON(!pmd_none(*pmd)); 1063 /* 1064 * We can only use set_pmd_at when establishing 1065 * hugepmds and never for establishing regular pmds that 1066 * points to regular pagetables. Use pmd_populate for that 1067 */ 1068 pmd_populate(mm, pmd, pmd_pgtable(_pmd)); 1069 spin_unlock(pmd_ptl); 1070 anon_vma_unlock_write(vma->anon_vma); 1071 result = SCAN_FAIL; 1072 goto out; 1073 } 1074 1075 /* 1076 * All pages are isolated and locked so anon_vma rmap 1077 * can't run anymore. 1078 */ 1079 anon_vma_unlock_write(vma->anon_vma); 1080 1081 __collapse_huge_page_copy(pte, new_page, vma, address, pte_ptl); 1082 pte_unmap(pte); 1083 __SetPageUptodate(new_page); 1084 pgtable = pmd_pgtable(_pmd); 1085 1086 _pmd = mk_huge_pmd(new_page, vma->vm_page_prot); 1087 _pmd = maybe_pmd_mkwrite(pmd_mkdirty(_pmd), vma); 1088 1089 /* 1090 * spin_lock() below is not the equivalent of smp_wmb(), so 1091 * this is needed to avoid the copy_huge_page writes to become 1092 * visible after the set_pmd_at() write. 1093 */ 1094 smp_wmb(); 1095 1096 spin_lock(pmd_ptl); 1097 BUG_ON(!pmd_none(*pmd)); 1098 page_add_new_anon_rmap(new_page, vma, address, true); 1099 mem_cgroup_commit_charge(new_page, memcg, false, true); 1100 count_memcg_events(memcg, THP_COLLAPSE_ALLOC, 1); 1101 lru_cache_add_active_or_unevictable(new_page, vma); 1102 pgtable_trans_huge_deposit(mm, pmd, pgtable); 1103 set_pmd_at(mm, address, pmd, _pmd); 1104 update_mmu_cache_pmd(vma, address, pmd); 1105 spin_unlock(pmd_ptl); 1106 1107 *hpage = NULL; 1108 1109 khugepaged_pages_collapsed++; 1110 result = SCAN_SUCCEED; 1111 out_up_write: 1112 up_write(&mm->mmap_sem); 1113 out_nolock: 1114 trace_mm_collapse_huge_page(mm, isolated, result); 1115 return; 1116 out: 1117 mem_cgroup_cancel_charge(new_page, memcg, true); 1118 goto out_up_write; 1119 } 1120 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-1.0-LTS] wl1251: Fix possible buffer overflow in wl1251_cmd_scan
by Xia Fukun 08 Jun '24

08 Jun '24

From: Lee Gibson <leegib(a)gmail.com> stable inclusion from stable-v4.19.314 commit 115103f6e3f1c26c473766c16439c7c8b235529a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9R4BX CVE: CVE-2021-47347 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… -------------------------------- [ Upstream commit d10a87a3535cce2b890897914f5d0d83df669c63 ] Function wl1251_cmd_scan calls memcpy without checking the length. Harden by checking the length is within the maximum allowed size. Signed-off-by: Lee Gibson <leegib(a)gmail.com> Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org> Link: https://lore.kernel.org/r/20210428115508.25624-1-leegib@gmail.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Xia Fukun <xiafukun(a)huawei.com> --- drivers/net/wireless/ti/wl1251/cmd.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/net/wireless/ti/wl1251/cmd.c b/drivers/net/wireless/ti/wl1251/cmd.c index 9547aea01b0f..ea0215246c5c 100644 --- a/drivers/net/wireless/ti/wl1251/cmd.c +++ b/drivers/net/wireless/ti/wl1251/cmd.c @@ -466,9 +466,12 @@ int wl1251_cmd_scan(struct wl1251 *wl, u8 *ssid, size_t ssid_len, cmd->channels[i].channel = channels[i]->hw_value; } - cmd->params.ssid_len = ssid_len; - if (ssid) - memcpy(cmd->params.ssid, ssid, ssid_len); + if (ssid) { + int len = clamp_val(ssid_len, 0, IEEE80211_MAX_SSID_LEN); + + cmd->params.ssid_len = len; + memcpy(cmd->params.ssid, ssid, len); + } ret = wl1251_cmd_send(wl, CMD_SCAN, cmd, sizeof(*cmd)); if (ret < 0) { -- 2.34.1

2 1

[PATCH OLK-6.6] ALSA: hda: intel-sdw-acpi: fix usage of device_get_named_child_node()
by Cui GaoSheng 08 Jun '24

08 Jun '24

From: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> stable inclusion from stable-v6.6.31 commit 7db626d2730d3d80fd31638169054b1e507f07bf category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9UOP1 CVE: CVE-2024-36955 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit c158cf914713efc3bcdc25680c7156c48c12ef6a ] The documentation for device_get_named_child_node() mentions this important point: " The caller is responsible for calling fwnode_handle_put() on the returned fwnode pointer. " Add fwnode_handle_put() to avoid a leaked reference. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Fixes: 08c2a4bc9f2a ("ALSA: hda: move Intel SoundWire ACPI scan to dedicated module") Message-ID: <20240426152731.38420-1-pierre-louis.bossart(a)linux.intel.com> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Cui GaoSheng <cuigaosheng1(a)huawei.com> --- sound/hda/intel-sdw-acpi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/hda/intel-sdw-acpi.c b/sound/hda/intel-sdw-acpi.c index b57d72ea4503..4e376994bf78 100644 --- a/sound/hda/intel-sdw-acpi.c +++ b/sound/hda/intel-sdw-acpi.c @@ -41,6 +41,8 @@ static bool is_link_enabled(struct fwnode_handle *fw_node, u8 idx) "intel-quirk-mask", &quirk_mask); + fwnode_handle_put(link); + if (quirk_mask & SDW_INTEL_QUIRK_MASK_BUS_DISABLE) return false; -- 2.34.1

2 1

[PATCH OLK-6.6] tty: n_gsm: fix possible out-of-bounds in gsm0_receive()
by Cui GaoSheng 08 Jun '24

08 Jun '24

From: Daniel Starke <daniel.starke(a)siemens.com> stable inclusion from stable-v6.6.33 commit 2ab96b6e81d2a419d3e0d6bec043ea8f31eab86a category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9TAHR CVE: CVE-2024-36016 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 47388e807f85948eefc403a8a5fdc5b406a65d5a upstream. Assuming the following: - side A configures the n_gsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration. Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAX_MRU in gsm0_receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru. All other checks remain as we still need to limit the data according to the user configuration and actual payload size. Reported-by: j51569436(a)gmail.com Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218708 Tested-by: j51569436(a)gmail.com Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Cc: stable(a)vger.kernel.org Signed-off-by: Daniel Starke <daniel.starke(a)siemens.com> Link: https://lore.kernel.org/r/20240424054842.7741-1-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Cui GaoSheng <cuigaosheng1(a)huawei.com> --- drivers/tty/n_gsm.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c index 0ee7531c9201..f8858865c5bb 100644 --- a/drivers/tty/n_gsm.c +++ b/drivers/tty/n_gsm.c @@ -2912,7 +2912,10 @@ static void gsm0_receive(struct gsm_mux *gsm, unsigned char c) break; case GSM_DATA: /* Data */ gsm->buf[gsm->count++] = c; - if (gsm->count == gsm->len) { + if (gsm->count >= MAX_MRU) { + gsm->bad_size++; + gsm->state = GSM_SEARCH; + } else if (gsm->count >= gsm->len) { /* Calculate final FCS for UI frames over all data */ if ((gsm->control & ~PF) != UIH) { gsm->fcs = gsm_fcs_add_block(gsm->fcs, gsm->buf, @@ -3025,7 +3028,7 @@ static void gsm1_receive(struct gsm_mux *gsm, unsigned char c) gsm->state = GSM_DATA; break; case GSM_DATA: /* Data */ - if (gsm->count > gsm->mru) { /* Allow one for the FCS */ + if (gsm->count > gsm->mru || gsm->count > MAX_MRU) { /* Allow one for the FCS */ gsm->state = GSM_OVERRUN; gsm->bad_size++; } else -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] tty: n_gsm: fix possible out-of-bounds in gsm0_receive()
by Cui GaoSheng 08 Jun '24

08 Jun '24

From: Daniel Starke <daniel.starke(a)siemens.com> stable inclusion from stable-v5.10.219 commit a200355b429825c9331c1bd70d7bb895c2f06b7d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9TAHR CVE: CVE-2024-36016 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 47388e807f85948eefc403a8a5fdc5b406a65d5a upstream. Assuming the following: - side A configures the n_gsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration. Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAX_MRU in gsm0_receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru. All other checks remain as we still need to limit the data according to the user configuration and actual payload size. Reported-by: j51569436(a)gmail.com Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218708 Tested-by: j51569436(a)gmail.com Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Cc: stable(a)vger.kernel.org Signed-off-by: Daniel Starke <daniel.starke(a)siemens.com> Link: https://lore.kernel.org/r/20240424054842.7741-1-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Cui GaoSheng <cuigaosheng1(a)huawei.com> --- drivers/tty/n_gsm.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c index 6cd87e71fecc..594be57f44ec 100644 --- a/drivers/tty/n_gsm.c +++ b/drivers/tty/n_gsm.c @@ -2015,8 +2015,12 @@ static void gsm0_receive(struct gsm_mux *gsm, unsigned char c) break; case GSM_DATA: /* Data */ gsm->buf[gsm->count++] = c; - if (gsm->count == gsm->len) + if (gsm->count >= MAX_MRU) { + gsm->bad_size++; + gsm->state = GSM_SEARCH; + } else if (gsm->count >= gsm->len) { gsm->state = GSM_FCS; + } break; case GSM_FCS: /* FCS follows the packet */ gsm->received_fcs = c; @@ -2109,7 +2113,7 @@ static void gsm1_receive(struct gsm_mux *gsm, unsigned char c) gsm->state = GSM_DATA; break; case GSM_DATA: /* Data */ - if (gsm->count > gsm->mru) { /* Allow one for the FCS */ + if (gsm->count > gsm->mru || gsm->count > MAX_MRU) { /* Allow one for the FCS */ gsm->state = GSM_OVERRUN; gsm->bad_size++; } else -- 2.34.1

2 1

[PATCH OLK-5.10] tty: n_gsm: fix possible out-of-bounds in gsm0_receive()
by Cui GaoSheng 08 Jun '24

08 Jun '24

From: Daniel Starke <daniel.starke(a)siemens.com> stable inclusion from stable-v5.10.219 commit a200355b429825c9331c1bd70d7bb895c2f06b7d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9TAHR CVE: CVE-2024-36016 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 47388e807f85948eefc403a8a5fdc5b406a65d5a upstream. Assuming the following: - side A configures the n_gsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration. Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAX_MRU in gsm0_receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru. All other checks remain as we still need to limit the data according to the user configuration and actual payload size. Reported-by: j51569436(a)gmail.com Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218708 Tested-by: j51569436(a)gmail.com Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Cc: stable(a)vger.kernel.org Signed-off-by: Daniel Starke <daniel.starke(a)siemens.com> Link: https://lore.kernel.org/r/20240424054842.7741-1-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Cui GaoSheng <cuigaosheng1(a)huawei.com> --- drivers/tty/n_gsm.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c index 3693ad9f4521..af2412450b10 100644 --- a/drivers/tty/n_gsm.c +++ b/drivers/tty/n_gsm.c @@ -2019,8 +2019,12 @@ static void gsm0_receive(struct gsm_mux *gsm, unsigned char c) break; case GSM_DATA: /* Data */ gsm->buf[gsm->count++] = c; - if (gsm->count == gsm->len) + if (gsm->count >= MAX_MRU) { + gsm->bad_size++; + gsm->state = GSM_SEARCH; + } else if (gsm->count >= gsm->len) { gsm->state = GSM_FCS; + } break; case GSM_FCS: /* FCS follows the packet */ gsm->received_fcs = c; @@ -2113,7 +2117,7 @@ static void gsm1_receive(struct gsm_mux *gsm, unsigned char c) gsm->state = GSM_DATA; break; case GSM_DATA: /* Data */ - if (gsm->count > gsm->mru) { /* Allow one for the FCS */ + if (gsm->count > gsm->mru || gsm->count > MAX_MRU) { /* Allow one for the FCS */ gsm->state = GSM_OVERRUN; gsm->bad_size++; } else -- 2.34.1

2 1