CVE-2024-56694

一、漏洞信息
漏洞编号：CVE-2024-56694
漏洞归属组件：kernel
漏洞归属的版本：4.19.140,4.19.194,4.19.90,5.10.0,6.1.19,6.4.0,6.6.0
CVSS V3.0分值：
BaseScore：5.5 Medium
Vector：CVSS：3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
漏洞简述：
In the Linux kernel, the following vulnerability has been resolved:bpf: fix recursive lock when verdict program return SK_PASSWhen the stream_verdict program returns SK_PASS, it places the received skbinto its own receive queue, but a recursive lock eventually occurs, leadingto an operating system deadlock. This issue has been present since v6.9. sk_psock_strp_data_ready write_lock_bh(&sk->sk_callback_lock) strp_data_ready strp_read_sock read_sock -> tcp_read_sock strp_recv cb.rcv_msg -> sk_psock_strp_read # now stream_verdict return SK_PASS without peer sock assign __SK_PASS = sk_psock_map_verd(SK_PASS, NULL) sk_psock_verdict_apply sk_psock_skb_ingress_self sk_psock_skb_ingress_enqueue sk_psock_data_ready read_lock_bh(&sk->sk_callback_lock) <= dead lock This topic has been discussed before, but it has not been fixed.Previous discussion:https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch
漏洞公开时间：2024-12-28 18:15:15
漏洞创建时间：2024-12-28 18:31:15
漏洞详情参考链接：
https://nvd.nist.gov/vuln/detail/CVE-2024-56694

更多参考(点击展开)

参考来源	参考链接	来源链接
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/01f1b88acfd79103da0610b45471f6c88ea98d72
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/078f7e1521442a55db4bed812a2fbaf02ac33819
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/221109ba2127eabd0aa64718543638b58b15df56
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/386efa339e08563dd33e83bc951aea5d407fe578
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/6694f7acd625ed854bf6342926e771d65dad7f69
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/8ca2a1eeadf09862190b2810697702d803ceef2d
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/da2bc8a0c8f3ac66fdf980fc59936f851a083561
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/f84c5ef6ca23cc2f72f3b830d74f67944684bb05
suse_bugzilla	http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-56694	https://bugzilla.suse.com/show_bug.cgi?id=1235412
suse_bugzilla	https://www.cve.org/CVERecord?id=CVE-2024-56694	https://bugzilla.suse.com/show_bug.cgi?id=1235412
suse_bugzilla	https://git.kernel.org/stable/c/01f1b88acfd79103da0610b45471f6c88ea98d72	https://bugzilla.suse.com/show_bug.cgi?id=1235412
suse_bugzilla	https://git.kernel.org/stable/c/386efa339e08563dd33e83bc951aea5d407fe578	https://bugzilla.suse.com/show_bug.cgi?id=1235412
suse_bugzilla	https://git.kernel.org/stable/c/6694f7acd625ed854bf6342926e771d65dad7f69	https://bugzilla.suse.com/show_bug.cgi?id=1235412
suse_bugzilla	https://git.kernel.org/stable/c/8ca2a1eeadf09862190b2810697702d803ceef2d	https://bugzilla.suse.com/show_bug.cgi?id=1235412
suse_bugzilla	https://git.kernel.org/stable/c/da2bc8a0c8f3ac66fdf980fc59936f851a083561	https://bugzilla.suse.com/show_bug.cgi?id=1235412
suse_bugzilla	https://git.kernel.org/stable/c/f84c5ef6ca23cc2f72f3b830d74f67944684bb05	https://bugzilla.suse.com/show_bug.cgi?id=1235412
suse_bugzilla	https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2024/CVE-2024-56694.mbox	https://bugzilla.suse.com/show_bug.cgi?id=1235412
suse_bugzilla	https://bugzilla.redhat.com/show_bug.cgi?id=2334694	https://bugzilla.suse.com/show_bug.cgi?id=1235412
redhat_bugzilla	https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch	https://bugzilla.redhat.com/show_bug.cgi?id=2334694
redhat_bugzilla	https://lore.kernel.org/linux-cve-announce/2024122835-CVE-2024-56694-c701@gregkh/T	https://bugzilla.redhat.com/show_bug.cgi?id=2334694
debian		https://security-tracker.debian.org/tracker/CVE-2024-56694
anolis		https://anas.openanolis.cn/cves/detail/CVE-2024-56694
osv	https://git.kernel.org/stable/c/01f1b88acfd79103da0610b45471f6c88ea98d72	https://osv.dev/vulnerability/CVE-2024-56694
osv	https://git.kernel.org/stable/c/386efa339e08563dd33e83bc951aea5d407fe578	https://osv.dev/vulnerability/CVE-2024-56694
osv	https://git.kernel.org/stable/c/6694f7acd625ed854bf6342926e771d65dad7f69	https://osv.dev/vulnerability/CVE-2024-56694
osv	https://git.kernel.org/stable/c/8ca2a1eeadf09862190b2810697702d803ceef2d	https://osv.dev/vulnerability/CVE-2024-56694
osv	https://git.kernel.org/stable/c/da2bc8a0c8f3ac66fdf980fc59936f851a083561	https://osv.dev/vulnerability/CVE-2024-56694
osv	https://git.kernel.org/stable/c/f84c5ef6ca23cc2f72f3b830d74f67944684bb05	https://osv.dev/vulnerability/CVE-2024-56694
osv	https://git.kernel.org/stable/c/078f7e1521442a55db4bed812a2fbaf02ac33819	https://osv.dev/vulnerability/CVE-2024-56694
osv	https://git.kernel.org/stable/c/221109ba2127eabd0aa64718543638b58b15df56	https://osv.dev/vulnerability/CVE-2024-56694
osv	https://security-tracker.debian.org/tracker/CVE-2024-56694	https://osv.dev/vulnerability/CVE-2024-56694

漏洞分析指导链接：
https://gitee.com/openeuler/cve-manager/blob/master/cve-vulner-manager/doc/md/manual.md
漏洞数据来源:
openBrain开源漏洞感知系统
漏洞补丁信息：

详情(点击展开)

影响的包	修复版本	修复补丁	问题引入补丁	来源
		https://git.kernel.org/stable/c/01f1b88acfd79103da0610b45471f6c88ea98d72		nvd
		https://git.kernel.org/stable/c/386efa339e08563dd33e83bc951aea5d407fe578		nvd
		https://git.kernel.org/stable/c/6694f7acd625ed854bf6342926e771d65dad7f69		nvd
		https://git.kernel.org/stable/c/8ca2a1eeadf09862190b2810697702d803ceef2d		nvd
		https://git.kernel.org/stable/c/da2bc8a0c8f3ac66fdf980fc59936f851a083561		nvd
		https://git.kernel.org/stable/c/f84c5ef6ca23cc2f72f3b830d74f67944684bb05		nvd
linux_kernel	5.15.174	https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6694f7acd625ed854bf6342926e771d65dad7f69Issue	https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5965bc7535fb87510b724e5465ccc1a1cf00916d	linuxkernelcves
linux_kernel	6.1.120	https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=386efa339e08563dd33e83bc951aea5d407fe578Issue	https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5965bc7535fb87510b724e5465ccc1a1cf00916d	linuxkernelcves
linux_kernel	6.6.64	https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=da2bc8a0c8f3ac66fdf980fc59936f851a083561Issue	https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5965bc7535fb87510b724e5465ccc1a1cf00916d	linuxkernelcves
linux_kernel	6.11.11	https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=01f1b88acfd79103da0610b45471f6c88ea98d72Issue	https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5965bc7535fb87510b724e5465ccc1a1cf00916d	linuxkernelcves
linux_kernel	6.12.2	https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f84c5ef6ca23cc2f72f3b830d74f67944684bb05Issue	https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5965bc7535fb87510b724e5465ccc1a1cf00916d	linuxkernelcves
linux_kernel	6.13-rc1	https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8ca2a1eeadf09862190b2810697702d803ceef2dIssue	https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5965bc7535fb87510b724e5465ccc1a1cf00916d	linuxkernelcves

二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:bpf: fix recursive lock when verdict program return SK_PASSWhen the stream_verdict program returns SK_PASS, it places the received skbinto its own receive queue, but a recursive lock eventually occurs, leadingto an operating system deadlock. This issue has been present since v6.9. sk_psock_strp_data_ready write_lock_bh(&sk->sk_callback_lock) strp_data_ready strp_read_sock read_sock -> tcp_read_sock strp_recv cb.rcv_msg -> sk_psock_strp_read # now stream_verdict return SK_PASS without peer sock assign __SK_PASS = sk_psock_map_verd(SK_PASS, NULL) sk_psock_verdict_apply sk_psock_skb_ingress_self sk_psock_skb_ingress_enqueue sk_psock_data_ready read_lock_bh(&sk->sk_callback_lock) <= dead lock This topic has been discussed before, but it has not been fixed.Previous discussion:https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch
openEuler评分：
5.5
Vector：CVSS：3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
受影响版本排查(受影响/不受影响)：
1.openEuler-22.03-LTS-SP3(5.10.0):受影响
2.openEuler-22.03-LTS-SP4(5.10.0):受影响
3.openEuler-24.03-LTS(6.6.0):受影响
4.openEuler-24.03-LTS-SP1(6.6.0):受影响
5.openEuler-20.03-LTS-SP4(4.19.90):不受影响
6.master(6.6.0):不受影响
7.openEuler-24.03-LTS-Next(6.6.0):不受影响

修复是否涉及abi变化(是/否)：
1.openEuler-20.03-LTS-SP4(4.19.90):否
2.openEuler-22.03-LTS-SP3(5.10.0):否
3.master(6.6.0):否
4.openEuler-24.03-LTS(6.6.0):否
5.openEuler-24.03-LTS-Next(6.6.0):否
6.openEuler-22.03-LTS-SP4(5.10.0):否
7.openEuler-24.03-LTS-SP1(6.6.0):否

原因说明：
1.openEuler-24.03-LTS(6.6.0):正常修复
2.openEuler-24.03-LTS-SP1(6.6.0):正常修复
3.openEuler-22.03-LTS-SP3(5.10.0):不修复-超出修复范围
4.openEuler-22.03-LTS-SP4(5.10.0):不修复-超出修复范围
5.master(6.6.0):不受影响-漏洞代码不能被攻击者触发
6.openEuler-24.03-LTS-Next(6.6.0):不受影响-漏洞代码不能被攻击者触发
7.openEuler-20.03-LTS-SP4(4.19.90):不受影响-漏洞代码不存在

三、漏洞修复
安全公告链接：https://www.openeuler.org/zh/security/safety-bulletin/detail/?id=openEuler-SA-2025-1450

Hi openeuler-ci-bot, welcome to the openEuler Community.
I'm the Bot here serving you. You can find the instructions on how to interact with me at Here.
If you have any questions, please contact the SIG: Kernel, and any of the maintainers.

@yangyingliang ,@jiaoff ,@guohaocs2c ,@hanjun-guo ,@woqidaideshi ,@newbeats ,@zhangyi089 ,@colyli ,@thundertown ,@htforge ,@chiqijun ,@lengchao ,@zhujianwei001 ,@kylin-mayukun ,@wangxiongfeng ,@wkfxxx ,@SuperSix173 ,@jentlestea ,@oskernel0719 ,@gasonchen 
**issue处理注意事项:** 
**1. 当前issue受影响的分支提交pr时, 须在pr描述中填写当前issue编号进行关联, 否则无法关闭当前issue;**
**2. 模板内容需要填写完整, 无论是受影响或者不受影响都需要填写完整内容,未引入的分支不需要填写, 否则无法关闭当前issue;**
**3. 以下为模板中需要填写完整的内容, 请复制到评论区回复, 注: 内容的标题名称(影响性分析说明, openEuler评分, 受影响版本排查(受影响/不受影响), 修复是否涉及abi变化(是/否), 原因说明)不能省略,省略后cve-manager将无法正常解析填写内容.**
************************************************************************
影响性分析说明:

openEuler评分: (评分和向量)

受影响版本排查(受影响/不受影响): 
1.master(6.6.0):
2.openEuler-20.03-LTS-SP4(4.19.90):
3.openEuler-22.03-LTS-SP1(5.10.0):
4.openEuler-22.03-LTS-SP3(5.10.0):
5.openEuler-22.03-LTS-SP4(5.10.0):
6.openEuler-24.03-LTS(6.6.0):
7.openEuler-24.03-LTS-Next(6.6.0):
8.openEuler-24.03-LTS-SP1(6.6.0):

修复是否涉及abi变化(是/否)：
1.master(6.6.0):
2.openEuler-20.03-LTS-SP4(4.19.90):
3.openEuler-22.03-LTS-SP1(5.10.0):
4.openEuler-22.03-LTS-SP3(5.10.0):
5.openEuler-22.03-LTS-SP4(5.10.0):
6.openEuler-24.03-LTS(6.6.0):
7.openEuler-24.03-LTS-Next(6.6.0):
8.openEuler-24.03-LTS-SP1(6.6.0):

原因说明：
1.master(6.6.0):
2.openEuler-20.03-LTS-SP4(4.19.90):
3.openEuler-22.03-LTS-SP1(5.10.0):
4.openEuler-22.03-LTS-SP3(5.10.0):
5.openEuler-22.03-LTS-SP4(5.10.0):
6.openEuler-24.03-LTS(6.6.0):
7.openEuler-24.03-LTS-Next(6.6.0):
8.openEuler-24.03-LTS-SP1(6.6.0):

issue处理具体操作请参考: 
https://gitee.com/openeuler/cve-manager/blob/master/cve-vulner-manager/doc/md/manual.md
pr关联issue具体操作请参考:
https://gitee.com/help/articles/4142

CVE-2024-56694

影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:

bpf: fix recursive lock when verdict program return SK_PASS

When the stream_verdict program returns SK_PASS, it places the received skb
into its own receive queue, but a recursive lock eventually occurs, leading
to an operating system deadlock. This issue has been present since v6.9.

'''
sk_psock_strp_data_ready
write_lock_bh(&sk->sk_callback_lock)
strp_data_ready
strp_read_sock
read_sock -> tcp_read_sock
strp_recv
cb.rcv_msg -> sk_psock_strp_read
# now stream_verdict return SK_PASS without peer sock assign
__SK_PASS = sk_psock_map_verd(SK_PASS, NULL)
sk_psock_verdict_apply
sk_psock_skb_ingress_self
sk_psock_skb_ingress_enqueue
sk_psock_data_ready
read_lock_bh(&sk->sk_callback_lock) <= dead lock

'''

This topic has been discussed before, but it has not been fixed.
Previous discussion:
https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch

The Linux kernel CVE team has assigned CVE-2024-56694 to this issue.

openEuler评分:(评分和向量)
3.9
AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L

受影响版本排查(受影响/不受影响):
1.openEuler-20.03-LTS-SP4:不受影响
2.openEuler-22.03-LTS-SP1:受影响
3.openEuler-22.03-LTS-SP3:受影响
4.openEuler-22.03-LTS-SP4:受影响
5.master(6.1.0):不受影响
6.openEuler-24.03-LTS:受影响
7.openEuler-24.03-LTS-Next:不受影响
8.openEuler-24.03-LTS-SP1:受影响

修复是否涉及abi变化(是/否)：
1.openEuler-20.03-LTS-SP4:否
2.openEuler-22.03-LTS-SP1:否
3.openEuler-22.03-LTS-SP3:否
4.master(6.1.0):否
5.openEuler-24.03-LTS:否
6.openEuler-24.03-LTS-Next:否
7.openEuler-22.03-LTS-SP4:否
8.openEuler-24.03-LTS-SP1:否

原因说明：
1.master(23.08.5):不受影响-漏洞代码不能被攻击者触发
2.openEuler-20.03-LTS-SP4:不受影响-漏洞代码不存在
3.openEuler-22.03-LTS-SP1:正常修复
4.openEuler-22.03-LTS-SP3:正常修复
5.openEuler-22.03-LTS-SP4:正常修复
6.openEuler-24.03-LTS:正常修复
7.openEuler-24.03-LTS-Next:不受影响-漏洞代码不能被攻击者触发
8.openEuler-24.03-LTS-SP1:正常修复

@sanglipeng 经过 cve-manager 解析, 已分析的内容如下表所示:
| 状态  | 分析项目 | 内容 |
|:--:|:--:|---------|
|已分析|1.影响性分析说明|In the Linux kernel, the following vulnerability has been resolved:bpf: fix recursive lock when verdict program return SK_PASSWhen the stream_verdict program returns SK_PASS, it places the received skbinto its own receive queue, but a recursive lock eventually occurs, leadingto an operating system deadlock. This issue has been present since v6.9.&#39;&#39;&#39;sk_psock_strp_data_ready    write_lock_bh(&#38;sk-&gt;sk_callback_lock)    strp_data_ready      strp_read_sock        read_sock -&gt; tcp_read_sock          strp_recv            cb.rcv_msg -&gt; sk_psock_strp_read              # now stream_verdict return SK_PASS without peer sock assign              __SK_PASS = sk_psock_map_verd(SK_PASS, NULL)              sk_psock_verdict_apply                sk_psock_skb_ingress_self                  sk_psock_skb_ingress_enqueue                    sk_psock_data_ready                      read_lock_bh(&#38;sk-&gt;sk_callback_lock) &lt;= dead lock&#39;&#39;&#39;This topic has been discussed before, but it has not been fixed.Previous discussion:<ahref="https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch">https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch</a>The Linux kernel CVE team has assigned CVE-2024-56694 to this issue.|
|已分析|2.openEulerScore|3.9|
|已分析|3.openEulerVector|AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L|
|已分析|4.受影响版本排查|openEuler-22.03-LTS-SP1:受影响,openEuler-22.03-LTS-SP3:受影响,openEuler-22.03-LTS-SP4:受影响,openEuler-24.03-LTS:受影响,openEuler-24.03-LTS-SP1:受影响,openEuler-20.03-LTS-SP4:不受影响,master:不受影响,openEuler-24.03-LTS-Next:不受影响|
|已分析|5.是否涉及abi变化|openEuler-20.03-LTS-SP4:否,openEuler-22.03-LTS-SP1:否,openEuler-22.03-LTS-SP3:否,master:否,openEuler-24.03-LTS:否,openEuler-24.03-LTS-Next:否,openEuler-22.03-LTS-SP4:否,openEuler-24.03-LTS-SP1:否|
|已分析|6.原因说明|openEuler-22.03-LTS-SP1:正常修复,openEuler-22.03-LTS-SP3:正常修复,openEuler-22.03-LTS-SP4:正常修复,openEuler-24.03-LTS:正常修复,openEuler-24.03-LTS-SP1:正常修复,master:不受影响-漏洞代码不能被攻击者触发,openEuler-24.03-LTS-Next:不受影响-漏洞代码不能被攻击者触发,openEuler-20.03-LTS-SP4:不受影响-漏洞代码不存在|

**请确认分析内容的准确性, 确认无误后, 您可以进行后续步骤, 否则您可以继续分析.**

CVE-2024-56694

影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:

bpf: fix recursive lock when verdict program return SK_PASS

When the stream_verdict program returns SK_PASS, it places the received skb
into its own receive queue, but a recursive lock eventually occurs, leading
to an operating system deadlock. This issue has been present since v6.9.

'''
sk_psock_strp_data_ready
write_lock_bh(&sk->sk_callback_lock)
strp_data_ready
strp_read_sock
read_sock -> tcp_read_sock
strp_recv
cb.rcv_msg -> sk_psock_strp_read
# now stream_verdict return SK_PASS without peer sock assign
__SK_PASS = sk_psock_map_verd(SK_PASS, NULL)
sk_psock_verdict_apply
sk_psock_skb_ingress_self
sk_psock_skb_ingress_enqueue
sk_psock_data_ready
read_lock_bh(&sk->sk_callback_lock) <= dead lock

'''

This topic has been discussed before, but it has not been fixed.
Previous discussion:
https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch

openEuler评分:(评分和向量)
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

受影响版本排查(受影响/不受影响):
1.openEuler-20.03-LTS-SP4:不受影响
2.openEuler-22.03-LTS-SP3:受影响
3.openEuler-22.03-LTS-SP4:受影响
4.master(6.6.0):不受影响
5.openEuler-24.03-LTS:受影响
6.openEuler-24.03-LTS-Next:不受影响
7.openEuler-24.03-LTS-SP1:受影响

原因说明:
1.openEuler-20.03-LTS-SP4:不受影响-漏洞代码不存在
2.openEuler-22.03-LTS-SP3:不修复-超出修复范围
3.openEuler-22.03-LTS-SP4:不修复-超出修复范围
4.master(6.6.0):不受影响-漏洞代码不能被攻击者触发
5.openEuler-24.03-LTS:正常修复
6.openEuler-24.03-LTS-Next:不受影响-漏洞代码不能被攻击者触发
7.openEuler-24.03-LTS-SP1:正常修复

修复是否涉及abi变化(是/否)：
1.openEuler-20.03-LTS-SP4:否
2.openEuler-22.03-LTS-SP3:否
3.master(23.08.5):否
4.openEuler-24.03-LTS:否
5.openEuler-24.03-LTS-Next:否
6.openEuler-22.03-LTS-SP4:否
7.openEuler-24.03-LTS-SP1:否

===========================================================

@sanglipeng 经过 cve-manager 解析, 已分析的内容如下表所示:
| 状态  | 分析项目 | 内容 |
|:--:|:--:|---------|
|已分析|1.影响性分析说明|In the Linux kernel, the following vulnerability has been resolved:bpf: fix recursive lock when verdict program return SK_PASSWhen the stream_verdict program returns SK_PASS, it places the received skbinto its own receive queue, but a recursive lock eventually occurs, leadingto an operating system deadlock. This issue has been present since v6.9.'''sk_psock_strp_data_ready    write_lock_bh(&sk->sk_callback_lock)    strp_data_ready      strp_read_sock        read_sock -> tcp_read_sock          strp_recv            cb.rcv_msg -> sk_psock_strp_read              # now stream_verdict return SK_PASS without peer sock assign              __SK_PASS = sk_psock_map_verd(SK_PASS, NULL)              sk_psock_verdict_apply                sk_psock_skb_ingress_self                  sk_psock_skb_ingress_enqueue                    sk_psock_data_ready                      read_lock_bh(&sk->sk_callback_lock) <= dead lock'''This topic has been discussed before, but it has not been fixed.Previous discussion:https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch|
|已分析|2.openEulerScore|5.5|
|已分析|3.openEulerVector|AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H|
|已分析|4.受影响版本排查|openEuler-22.03-LTS-SP3:受影响,openEuler-22.03-LTS-SP4:受影响,openEuler-24.03-LTS:受影响,openEuler-24.03-LTS-SP1:受影响,openEuler-20.03-LTS-SP4:不受影响,master:不受影响,openEuler-24.03-LTS-Next:不受影响|
|已分析|5.是否涉及abi变化|openEuler-20.03-LTS-SP4:否,openEuler-22.03-LTS-SP3:否,master:否,openEuler-24.03-LTS:否,openEuler-24.03-LTS-Next:否,openEuler-22.03-LTS-SP4:否,openEuler-24.03-LTS-SP1:否|
|已分析|6.原因说明|openEuler-24.03-LTS:正常修复,openEuler-24.03-LTS-SP1:正常修复,openEuler-22.03-LTS-SP3:不修复-超出修复范围,openEuler-22.03-LTS-SP4:不修复-超出修复范围,master:不受影响-漏洞代码不能被攻击者触发,openEuler-24.03-LTS-Next:不受影响-漏洞代码不能被攻击者触发,openEuler-20.03-LTS-SP4:不受影响-漏洞代码不存在|

**请确认分析内容的准确性, 确认无误后, 您可以进行后续步骤, 否则您可以继续分析.**

CVE-2024-56694

影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:

bpf: fix recursive lock when verdict program return SK_PASS

When the stream_verdict program returns SK_PASS, it places the received skb
into its own receive queue, but a recursive lock eventually occurs, leading
to an operating system deadlock. This issue has been present since v6.9.

'''
sk_psock_strp_data_ready
write_lock_bh(&sk->sk_callback_lock)
strp_data_ready
strp_read_sock
read_sock -> tcp_read_sock
strp_recv
cb.rcv_msg -> sk_psock_strp_read
# now stream_verdict return SK_PASS without peer sock assign
__SK_PASS = sk_psock_map_verd(SK_PASS, NULL)
sk_psock_verdict_apply
sk_psock_skb_ingress_self
sk_psock_skb_ingress_enqueue
sk_psock_data_ready
read_lock_bh(&sk->sk_callback_lock) <= dead lock

'''

This topic has been discussed before, but it has not been fixed.
Previous discussion:
https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch

openEuler评分:(评分和向量)
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

受影响版本排查(受影响/不受影响):
1.openEuler-20.03-LTS-SP4:不受影响
2.openEuler-22.03-LTS-SP3:受影响
3.openEuler-22.03-LTS-SP4:受影响
4.master(6.6.0):不受影响
5.openEuler-24.03-LTS:受影响
6.openEuler-24.03-LTS-Next:不受影响
7.openEuler-24.03-LTS-SP1:受影响

原因说明:
1.openEuler-20.03-LTS-SP4:不受影响-漏洞代码不存在
2.openEuler-22.03-LTS-SP3:不修复-超出修复范围
3.openEuler-22.03-LTS-SP4:不修复-超出修复范围
4.master(6.6.0):不受影响-漏洞代码不能被攻击者触发
5.openEuler-24.03-LTS:正常修复
6.openEuler-24.03-LTS-Next:不受影响-漏洞代码不能被攻击者触发
7.openEuler-24.03-LTS-SP1:正常修复

修复是否涉及abi变化(是/否)：
1.openEuler-20.03-LTS-SP4:否
2.openEuler-22.03-LTS-SP3:否
3.master(23.08.5):否
4.openEuler-24.03-LTS:否
5.openEuler-24.03-LTS-Next:否
6.openEuler-22.03-LTS-SP4:否
7.openEuler-24.03-LTS-SP1:否

===========================================================

@sanglipeng 经过 cve-manager 解析, 已分析的内容如下表所示:
| 状态  | 分析项目 | 内容 |
|:--:|:--:|---------|
|已分析|1.影响性分析说明|In the Linux kernel, the following vulnerability has been resolved:bpf: fix recursive lock when verdict program return SK_PASSWhen the stream_verdict program returns SK_PASS, it places the received skbinto its own receive queue, but a recursive lock eventually occurs, leadingto an operating system deadlock. This issue has been present since v6.9.'''sk_psock_strp_data_ready    write_lock_bh(&sk->sk_callback_lock)    strp_data_ready      strp_read_sock        read_sock -> tcp_read_sock          strp_recv            cb.rcv_msg -> sk_psock_strp_read              # now stream_verdict return SK_PASS without peer sock assign              __SK_PASS = sk_psock_map_verd(SK_PASS, NULL)              sk_psock_verdict_apply                sk_psock_skb_ingress_self                  sk_psock_skb_ingress_enqueue                    sk_psock_data_ready                      read_lock_bh(&sk->sk_callback_lock) <= dead lock'''This topic has been discussed before, but it has not been fixed.Previous discussion:https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch|
|已分析|2.openEulerScore|5.5|
|已分析|3.openEulerVector|AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H|
|已分析|4.受影响版本排查|openEuler-22.03-LTS-SP3:受影响,openEuler-22.03-LTS-SP4:受影响,openEuler-24.03-LTS:受影响,openEuler-24.03-LTS-SP1:受影响,openEuler-20.03-LTS-SP4:不受影响,master:不受影响,openEuler-24.03-LTS-Next:不受影响|
|已分析|5.是否涉及abi变化|openEuler-20.03-LTS-SP4:否,openEuler-22.03-LTS-SP3:否,master:否,openEuler-24.03-LTS:否,openEuler-24.03-LTS-Next:否,openEuler-22.03-LTS-SP4:否,openEuler-24.03-LTS-SP1:否|
|已分析|6.原因说明|openEuler-24.03-LTS:正常修复,openEuler-24.03-LTS-SP1:正常修复,openEuler-22.03-LTS-SP3:不修复-超出修复范围,openEuler-22.03-LTS-SP4:不修复-超出修复范围,master:不受影响-漏洞代码不能被攻击者触发,openEuler-24.03-LTS-Next:不受影响-漏洞代码不能被攻击者触发,openEuler-20.03-LTS-SP4:不受影响-漏洞代码不存在|

**请确认分析内容的准确性, 确认无误后, 您可以进行后续步骤, 否则您可以继续分析.**

CVE-2024-56694

影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:

bpf: fix recursive lock when verdict program return SK_PASS

When the stream_verdict program returns SK_PASS, it places the received skb
into its own receive queue, but a recursive lock eventually occurs, leading
to an operating system deadlock. This issue has been present since v6.9.

'''
sk_psock_strp_data_ready
write_lock_bh(&sk->sk_callback_lock)
strp_data_ready
strp_read_sock
read_sock -> tcp_read_sock
strp_recv
cb.rcv_msg -> sk_psock_strp_read
# now stream_verdict return SK_PASS without peer sock assign
__SK_PASS = sk_psock_map_verd(SK_PASS, NULL)
sk_psock_verdict_apply
sk_psock_skb_ingress_self
sk_psock_skb_ingress_enqueue
sk_psock_data_ready
read_lock_bh(&sk->sk_callback_lock) <= dead lock

'''

This topic has been discussed before, but it has not been fixed.
Previous discussion:
https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch

openEuler评分:(评分和向量)
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

受影响版本排查(受影响/不受影响):
1.openEuler-20.03-LTS-SP4:不受影响
2.openEuler-22.03-LTS-SP3:受影响
3.openEuler-22.03-LTS-SP4:受影响
4.master(6.6.0):不受影响
5.openEuler-24.03-LTS:受影响
6.openEuler-24.03-LTS-Next:不受影响
7.openEuler-24.03-LTS-SP1:受影响

原因说明:
1.openEuler-20.03-LTS-SP4:不受影响-漏洞代码不存在
2.openEuler-22.03-LTS-SP3:不修复-超出修复范围
3.openEuler-22.03-LTS-SP4:不修复-超出修复范围
4.master(6.6.0):不受影响-漏洞代码不能被攻击者触发
5.openEuler-24.03-LTS:正常修复
6.openEuler-24.03-LTS-Next:不受影响-漏洞代码不能被攻击者触发
7.openEuler-24.03-LTS-SP1:正常修复

修复是否涉及abi变化(是/否)：
1.openEuler-20.03-LTS-SP4:否
2.openEuler-22.03-LTS-SP3:否
3.master(23.08.5):否
4.openEuler-24.03-LTS:否
5.openEuler-24.03-LTS-Next:否
6.openEuler-22.03-LTS-SP4:否
7.openEuler-24.03-LTS-SP1:否

===========================================================

@sanglipeng 经过 cve-manager 解析, 已分析的内容如下表所示:
| 状态  | 分析项目 | 内容 |
|:--:|:--:|---------|
|已分析|1.影响性分析说明|In the Linux kernel, the following vulnerability has been resolved:bpf: fix recursive lock when verdict program return SK_PASSWhen the stream_verdict program returns SK_PASS, it places the received skbinto its own receive queue, but a recursive lock eventually occurs, leadingto an operating system deadlock. This issue has been present since v6.9.'''sk_psock_strp_data_ready    write_lock_bh(&sk->sk_callback_lock)    strp_data_ready      strp_read_sock        read_sock -> tcp_read_sock          strp_recv            cb.rcv_msg -> sk_psock_strp_read              # now stream_verdict return SK_PASS without peer sock assign              __SK_PASS = sk_psock_map_verd(SK_PASS, NULL)              sk_psock_verdict_apply                sk_psock_skb_ingress_self                  sk_psock_skb_ingress_enqueue                    sk_psock_data_ready                      read_lock_bh(&sk->sk_callback_lock) <= dead lock'''This topic has been discussed before, but it has not been fixed.Previous discussion:https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch|
|已分析|2.openEulerScore|5.5|
|已分析|3.openEulerVector|AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H|
|已分析|4.受影响版本排查|openEuler-22.03-LTS-SP3:受影响,openEuler-22.03-LTS-SP4:受影响,openEuler-24.03-LTS:受影响,openEuler-24.03-LTS-SP1:受影响,openEuler-20.03-LTS-SP4:不受影响,master:不受影响,openEuler-24.03-LTS-Next:不受影响|
|已分析|5.是否涉及abi变化|openEuler-20.03-LTS-SP4:否,openEuler-22.03-LTS-SP3:否,master:否,openEuler-24.03-LTS:否,openEuler-24.03-LTS-Next:否,openEuler-22.03-LTS-SP4:否,openEuler-24.03-LTS-SP1:否|
|已分析|6.原因说明|openEuler-24.03-LTS:正常修复,openEuler-24.03-LTS-SP1:正常修复,openEuler-22.03-LTS-SP3:不修复-超出修复范围,openEuler-22.03-LTS-SP4:不修复-超出修复范围,master:不受影响-漏洞代码不能被攻击者触发,openEuler-24.03-LTS-Next:不受影响-漏洞代码不能被攻击者触发,openEuler-20.03-LTS-SP4:不受影响-漏洞代码不存在|

**请确认分析内容的准确性, 确认无误后, 您可以进行后续步骤, 否则您可以继续分析.**

CVE-2024-56694

影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:

bpf: fix recursive lock when verdict program return SK_PASS

When the stream_verdict program returns SK_PASS, it places the received skb
into its own receive queue, but a recursive lock eventually occurs, leading
to an operating system deadlock. This issue has been present since v6.9.

'''
sk_psock_strp_data_ready
write_lock_bh(&sk->sk_callback_lock)
strp_data_ready
strp_read_sock
read_sock -> tcp_read_sock
strp_recv
cb.rcv_msg -> sk_psock_strp_read
# now stream_verdict return SK_PASS without peer sock assign
__SK_PASS = sk_psock_map_verd(SK_PASS, NULL)
sk_psock_verdict_apply
sk_psock_skb_ingress_self
sk_psock_skb_ingress_enqueue
sk_psock_data_ready
read_lock_bh(&sk->sk_callback_lock) <= dead lock

'''

This topic has been discussed before, but it has not been fixed.
Previous discussion:
https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch

The Linux kernel CVE team has assigned CVE-2024-56694 to this issue.

openEuler评分:(评分和向量)
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

受影响版本排查(受影响/不受影响):
1.master(6.1.0):不受影响
2.openEuler-20.03-LTS-SP4:不受影响
3.openEuler-22.03-LTS-SP3:受影响
4.openEuler-22.03-LTS-SP4:受影响
5.openEuler-24.03-LTS:受影响
6.openEuler-24.03-LTS-Next:不受影响
7.openEuler-24.03-LTS-SP1:受影响

修复是否涉及abi变化(是/否)：
1.master(6.1.0):否
2.openEuler-20.03-LTS-SP4:否
3.openEuler-22.03-LTS-SP3:否
4.openEuler-22.03-LTS-SP4:否
5.openEuler-24.03-LTS:否
6.openEuler-24.03-LTS-Next:否
7.openEuler-24.03-LTS-SP1:否

原因说明：
1.master(23.08.5):不受影响-漏洞代码不能被攻击者触发
2.openEuler-20.03-LTS-SP4:不受影响-漏洞代码不存在
4.openEuler-22.03-LTS-SP3:正常修复
5.openEuler-22.03-LTS-SP4:正常修复
6.openEuler-24.03-LTS:正常修复
7.openEuler-24.03-LTS-Next:不受影响-漏洞代码不能被攻击者触发
8.openEuler-24.03-LTS-SP1:正常修复

@sanglipeng 经过 cve-manager 解析, 已分析的内容如下表所示:
| 状态  | 分析项目 | 内容 |
|:--:|:--:|---------|
|已分析|1.影响性分析说明|In the Linux kernel, the following vulnerability has been resolved:bpf: fix recursive lock when verdict program return SK_PASSWhen the stream_verdict program returns SK_PASS, it places the received skbinto its own receive queue, but a recursive lock eventually occurs, leadingto an operating system deadlock. This issue has been present since v6.9.&#39;&#39;&#39;sk_psock_strp_data_ready    write_lock_bh(&#38;sk-&gt;sk_callback_lock)    strp_data_ready      strp_read_sock        read_sock -&gt; tcp_read_sock          strp_recv            cb.rcv_msg -&gt; sk_psock_strp_read              # now stream_verdict return SK_PASS without peer sock assign              __SK_PASS = sk_psock_map_verd(SK_PASS, NULL)              sk_psock_verdict_apply                sk_psock_skb_ingress_self                  sk_psock_skb_ingress_enqueue                    sk_psock_data_ready                      read_lock_bh(&#38;sk-&gt;sk_callback_lock) &lt;= dead lock&#39;&#39;&#39;This topic has been discussed before, but it has not been fixed.Previous discussion:<ahref="https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch">https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch</a>The Linux kernel CVE team has assigned CVE-2024-56694 to this issue.|
|已分析|2.openEulerScore|5.5|
|已分析|3.openEulerVector|AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H|
|已分析|4.受影响版本排查|openEuler-22.03-LTS-SP3:受影响,openEuler-22.03-LTS-SP4:受影响,openEuler-24.03-LTS:受影响,openEuler-24.03-LTS-SP1:受影响,master:不受影响,openEuler-20.03-LTS-SP4:不受影响,openEuler-24.03-LTS-Next:不受影响|
|已分析|5.是否涉及abi变化|master:否,openEuler-20.03-LTS-SP4:否,openEuler-22.03-LTS-SP3:否,openEuler-22.03-LTS-SP4:否,openEuler-24.03-LTS:否,openEuler-24.03-LTS-Next:否,openEuler-24.03-LTS-SP1:否|
|已分析|6.原因说明|openEuler-22.03-LTS-SP3:正常修复,openEuler-22.03-LTS-SP4:正常修复,openEuler-24.03-LTS:正常修复,openEuler-24.03-LTS-SP1:正常修复,master:不受影响-漏洞代码不能被攻击者触发,openEuler-24.03-LTS-Next:不受影响-漏洞代码不能被攻击者触发,openEuler-20.03-LTS-SP4:不受影响-漏洞代码不存在|

**请确认分析内容的准确性, 确认无误后, 您可以进行后续步骤, 否则您可以继续分析.**

CVE-2024-56694

影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:

bpf: fix recursive lock when verdict program return SK_PASS

When the stream_verdict program returns SK_PASS, it places the received skb
into its own receive queue, but a recursive lock eventually occurs, leading
to an operating system deadlock. This issue has been present since v6.9.

'''
sk_psock_strp_data_ready
write_lock_bh(&sk->sk_callback_lock)
strp_data_ready
strp_read_sock
read_sock -> tcp_read_sock
strp_recv
cb.rcv_msg -> sk_psock_strp_read
# now stream_verdict return SK_PASS without peer sock assign
__SK_PASS = sk_psock_map_verd(SK_PASS, NULL)
sk_psock_verdict_apply
sk_psock_skb_ingress_self
sk_psock_skb_ingress_enqueue
sk_psock_data_ready
read_lock_bh(&sk->sk_callback_lock) <= dead lock

'''

This topic has been discussed before, but it has not been fixed.
Previous discussion:
https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch

The Linux kernel CVE team has assigned CVE-2024-56694 to this issue.

openEuler评分:(评分和向量)
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

受影响版本排查(受影响/不受影响):
1.master(6.1.0):不受影响
2.openEuler-20.03-LTS-SP4:不受影响
3.openEuler-22.03-LTS-SP3:受影响
4.openEuler-22.03-LTS-SP4:受影响
5.openEuler-24.03-LTS:受影响
6.openEuler-24.03-LTS-Next:不受影响
7.openEuler-24.03-LTS-SP1:受影响

修复是否涉及abi变化(是/否)：
1.master(6.1.0):否
2.openEuler-20.03-LTS-SP4:否
3.openEuler-22.03-LTS-SP3:否
4.openEuler-22.03-LTS-SP4:否
5.openEuler-24.03-LTS:否
6.openEuler-24.03-LTS-Next:否
7.openEuler-24.03-LTS-SP1:否

原因说明：
1.master(23.08.5):不受影响-漏洞代码不能被攻击者触发
2.openEuler-20.03-LTS-SP4:不受影响-漏洞代码不存在
4.openEuler-22.03-LTS-SP3:不修复-超出修复范围
5.openEuler-22.03-LTS-SP4:不修复-超出修复范围
6.openEuler-24.03-LTS:正常修复
7.openEuler-24.03-LTS-Next:不受影响-漏洞代码不能被攻击者触发
8.openEuler-24.03-LTS-SP1:正常修复

@sanglipeng 经过 cve-manager 解析, 已分析的内容如下表所示:
| 状态  | 分析项目 | 内容 |
|:--:|:--:|---------|
|已分析|1.影响性分析说明|In the Linux kernel, the following vulnerability has been resolved:bpf: fix recursive lock when verdict program return SK_PASSWhen the stream_verdict program returns SK_PASS, it places the received skbinto its own receive queue, but a recursive lock eventually occurs, leadingto an operating system deadlock. This issue has been present since v6.9.&#39;&#39;&#39;sk_psock_strp_data_ready    write_lock_bh(&#38;sk-&gt;sk_callback_lock)    strp_data_ready      strp_read_sock        read_sock -&gt; tcp_read_sock          strp_recv            cb.rcv_msg -&gt; sk_psock_strp_read              # now stream_verdict return SK_PASS without peer sock assign              __SK_PASS = sk_psock_map_verd(SK_PASS, NULL)              sk_psock_verdict_apply                sk_psock_skb_ingress_self                  sk_psock_skb_ingress_enqueue                    sk_psock_data_ready                      read_lock_bh(&#38;sk-&gt;sk_callback_lock) &lt;= dead lock&#39;&#39;&#39;This topic has been discussed before, but it has not been fixed.Previous discussion:<ahref="https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch">https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch</a>The Linux kernel CVE team has assigned CVE-2024-56694 to this issue.|
|已分析|2.openEulerScore|5.5|
|已分析|3.openEulerVector|AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H|
|已分析|4.受影响版本排查|openEuler-22.03-LTS-SP3:受影响,openEuler-22.03-LTS-SP4:受影响,openEuler-24.03-LTS:受影响,openEuler-24.03-LTS-SP1:受影响,master:不受影响,openEuler-20.03-LTS-SP4:不受影响,openEuler-24.03-LTS-Next:不受影响|
|已分析|5.是否涉及abi变化|master:否,openEuler-20.03-LTS-SP4:否,openEuler-22.03-LTS-SP3:否,openEuler-22.03-LTS-SP4:否,openEuler-24.03-LTS:否,openEuler-24.03-LTS-Next:否,openEuler-24.03-LTS-SP1:否|
|已分析|6.原因说明|openEuler-24.03-LTS:正常修复,openEuler-24.03-LTS-SP1:正常修复,openEuler-22.03-LTS-SP3:不修复-超出修复范围,openEuler-22.03-LTS-SP4:不修复-超出修复范围,master:不受影响-漏洞代码不能被攻击者触发,openEuler-24.03-LTS-Next:不受影响-漏洞代码不能被攻击者触发,openEuler-20.03-LTS-SP4:不受影响-漏洞代码不存在|

**请确认分析内容的准确性, 确认无误后, 您可以进行后续步骤, 否则您可以继续分析.**

CVE-2024-56694

影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:

bpf: fix recursive lock when verdict program return SK_PASS

When the stream_verdict program returns SK_PASS, it places the received skb
into its own receive queue, but a recursive lock eventually occurs, leading
to an operating system deadlock. This issue has been present since v6.9.

'''
sk_psock_strp_data_ready
write_lock_bh(&sk->sk_callback_lock)
strp_data_ready
strp_read_sock
read_sock -> tcp_read_sock
strp_recv
cb.rcv_msg -> sk_psock_strp_read
# now stream_verdict return SK_PASS without peer sock assign
__SK_PASS = sk_psock_map_verd(SK_PASS, NULL)
sk_psock_verdict_apply
sk_psock_skb_ingress_self
sk_psock_skb_ingress_enqueue
sk_psock_data_ready
read_lock_bh(&sk->sk_callback_lock) <= dead lock

'''

This topic has been discussed before, but it has not been fixed.
Previous discussion:
https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch

openEuler评分:(评分和向量)
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

受影响版本排查(受影响/不受影响):
1.openEuler-20.03-LTS-SP4:不受影响
2.openEuler-22.03-LTS-SP3:受影响
3.openEuler-22.03-LTS-SP4:受影响
4.master(6.6.0):不受影响
5.openEuler-24.03-LTS:受影响
6.openEuler-24.03-LTS-Next:不受影响
7.openEuler-24.03-LTS-SP1:受影响

原因说明:
1.openEuler-20.03-LTS-SP4:不受影响-漏洞代码不存在
2.openEuler-22.03-LTS-SP3:不修复-超出修复范围
3.openEuler-22.03-LTS-SP4:不修复-超出修复范围
4.master(6.6.0):不受影响-漏洞代码不能被攻击者触发
5.openEuler-24.03-LTS:正常修复
6.openEuler-24.03-LTS-Next:不受影响-漏洞代码不能被攻击者触发
7.openEuler-24.03-LTS-SP1:正常修复

修复是否涉及abi变化(是/否)：
1.openEuler-20.03-LTS-SP4:否
2.openEuler-22.03-LTS-SP3:否
3.master(23.08.5):否
4.openEuler-24.03-LTS:否
5.openEuler-24.03-LTS-Next:否
6.openEuler-22.03-LTS-SP4:否
7.openEuler-24.03-LTS-SP1:否

===========================================================

@sanglipeng 经过 cve-manager 解析, 已分析的内容如下表所示:
| 状态  | 分析项目 | 内容 |
|:--:|:--:|---------|
|已分析|1.影响性分析说明|In the Linux kernel, the following vulnerability has been resolved:bpf: fix recursive lock when verdict program return SK_PASSWhen the stream_verdict program returns SK_PASS, it places the received skbinto its own receive queue, but a recursive lock eventually occurs, leadingto an operating system deadlock. This issue has been present since v6.9.'''sk_psock_strp_data_ready    write_lock_bh(&sk->sk_callback_lock)    strp_data_ready      strp_read_sock        read_sock -> tcp_read_sock          strp_recv            cb.rcv_msg -> sk_psock_strp_read              # now stream_verdict return SK_PASS without peer sock assign              __SK_PASS = sk_psock_map_verd(SK_PASS, NULL)              sk_psock_verdict_apply                sk_psock_skb_ingress_self                  sk_psock_skb_ingress_enqueue                    sk_psock_data_ready                      read_lock_bh(&sk->sk_callback_lock) <= dead lock'''This topic has been discussed before, but it has not been fixed.Previous discussion:https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch|
|已分析|2.openEulerScore|5.5|
|已分析|3.openEulerVector|AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H|
|已分析|4.受影响版本排查|openEuler-22.03-LTS-SP3:受影响,openEuler-22.03-LTS-SP4:受影响,openEuler-24.03-LTS:受影响,openEuler-24.03-LTS-SP1:受影响,openEuler-20.03-LTS-SP4:不受影响,master:不受影响,openEuler-24.03-LTS-Next:不受影响|
|已分析|5.是否涉及abi变化|openEuler-20.03-LTS-SP4:否,openEuler-22.03-LTS-SP3:否,master:否,openEuler-24.03-LTS:否,openEuler-24.03-LTS-Next:否,openEuler-22.03-LTS-SP4:否,openEuler-24.03-LTS-SP1:否|
|已分析|6.原因说明|openEuler-24.03-LTS:正常修复,openEuler-24.03-LTS-SP1:正常修复,openEuler-22.03-LTS-SP3:不修复-超出修复范围,openEuler-22.03-LTS-SP4:不修复-超出修复范围,master:不受影响-漏洞代码不能被攻击者触发,openEuler-24.03-LTS-Next:不受影响-漏洞代码不能被攻击者触发,openEuler-20.03-LTS-SP4:不受影响-漏洞代码不存在|

**请确认分析内容的准确性, 确认无误后, 您可以进行后续步骤, 否则您可以继续分析.**

src-openEuler/kernel

内容风险标识

评论 (19)

src-openEuler/kernel .gitee-modal { width: 500px !important; }

内容风险标识

CVE-2024-56694

评论 (19)

搜索帮助

src-openEuler/kernel