一、漏洞信息
漏洞编号:CVE-2024-26804
漏洞归属组件:kernel
漏洞归属的版本:4.19.140,4.19.194,4.19.90,5.10.0,6.1.0,6.1.14,6.1.19,6.1.5,6.1.6,6.1.8,6.4.0
CVSS V2.0分值:
BaseScore:0.0 Low
Vector:CVSS:2.0/
漏洞简述:
In the Linux kernel, the following vulnerability has been resolved:net: ip_tunnel: prevent perpetual headroom growthsyzkaller triggered following kasan splat:BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191[..] kasan_report+0xda/0x110 mm/kasan/report.c:588 __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline] ___skb_get_hash net/core/flow_dissector.c:1791 [inline] __skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856 skb_get_hash include/linux/skbuff.h:1556 [inline] ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748 ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592 ... ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 .. iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831 ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 ...The splat occurs because skb->data points past skb->head allocated area.This is because neigh layer does: __skb_pull(skb, skb_network_offset(skb));... but skb_network_offset() returns a negative offset and __skb_pull()arg is unsigned. IOW, we skb->data gets adjusted by a huge value.The negative value is returned because skb->head and skb->data distance ismore than 64k and skb->network_header (u16) has wrapped around.The bug is in the ip_tunnel infrastructure, which can causedev->needed_headroom to increment ad infinitum.The syzkaller reproducer consists of packets getting routed via a gretunnel, and route of gre encapsulated packets pointing at another (ipip)tunnel. The ipip encapsulation finds gre0 as next output device.This results in the following pattern:1). First packet is to be sent out via gre0.Route lookup found an output device, ipip0.2).ip_tunnel_xmit for gre0 bumps gre0->needed_headroom based on the futureoutput device, rt.dev->needed_headroom (ipip0).3).ip output / start_xmit moves skb on to ipip0. which runs the samecode path again (xmit recursion).4).Routing step for the post-gre0-encap packet finds gre0 as output deviceto use for ipip0 encapsulated packet.tunl0->needed_headroom is then incremented based on the (already bumped)gre0 device headroom.This repeats for every future packet:gre0->needed_headroom gets inflated because previous packets ipip0 stepincremented rt->dev (gre0) headroom, and ipip0 incremented because gre0needed_headroom was increased.For each subsequent packet, gre/ipip0->needed_headroom grows untilpost-expand-head reallocations result in a skb->head/data distance ofmore than 64k.Once that happens, skb->network_header (u16) wraps around whenpskb_expand_head tries to make sure that skb_network_offset() is unchangedafter the headroom expansion/reallocation.After this skb_network_offset(skb) returns a different (and negative)result post headroom expansion.The next trip to neigh layer (or anything else that would __skb_pull thenetwork header) makes skb->data point to a memory location outsideskb->head area.v2: Cap the needed_headroom update to an arbitarily chosen upperlimit toprevent perpetual increase instead of dropping the headroom incrementcompletely.
漏洞公开时间:2024-04-04 17:15:09
漏洞创建时间:2024-04-04 18:17:24
漏洞详情参考链接:
https://nvd.nist.gov/vuln/detail/CVE-2024-26804
漏洞分析指导链接:
https://gitee.com/openeuler/cve-manager/blob/master/cve-vulner-manager/doc/md/manual.md
漏洞数据来源:
openBrain开源漏洞感知系统
漏洞补丁信息:
影响的包 | 修复版本 | 修复补丁 | 问题引入补丁 | 来源 |
---|---|---|---|---|
linux | https://git.kernel.org/linus/5ae1e9922bbdbaeb9cfbe91085ab75927488ac0f | https://git.kernel.org/linus/243aad830e8a4cdda261626fbaeddde16b08d04a | ubuntu |
二、漏洞分析结构反馈
影响性分析说明:
In the Linux kernel, the following vulnerability has been resolved:net: ip_tunnel: prevent perpetual headroom growthsyzkaller triggered following kasan splat:BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191[..] kasan_report+0xda/0x110 mm/kasan/report.c:588 __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline] ___skb_get_hash net/core/flow_dissector.c:1791 [inline] __skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856 skb_get_hash include/linux/skbuff.h:1556 [inline] ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748 ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592 ... ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 .. iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831 ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 ...The splat occurs because skb->data points past skb->head allocated area.This is because neigh layer does: __skb_pull(skb, skb_network_offset(skb));... but skb_network_offset() returns a negative offset and __skb_pull()arg is unsigned. IOW, we skb->data gets adjusted by a huge value.The negative value is returned because skb->head and skb->data distance ismore than 64k and skb->network_header (u16) has wrapped around.The bug is in the ip_tunnel infrastructure, which can causedev->needed_headroom to increment ad infinitum.The syzkaller reproducer consists of packets getting routed via a gretunnel, and route of gre encapsulated packets pointing at another (ipip)tunnel. The ipip encapsulation finds gre0 as next output device.This results in the following pattern:1). First packet is to be sent out via gre0.Route lookup found an output device, ipip0.2).ip_tunnel_xmit for gre0 bumps gre0->needed_headroom based on the futureoutput device, rt.dev->needed_headroom (ipip0).3).ip output / start_xmit moves skb on to ipip0. which runs the samecode path again (xmit recursion).4).Routing step for the post-gre0-encap packet finds gre0 as output deviceto use for ipip0 encapsulated packet.tunl0->needed_headroom is then incremented based on the (already bumped)gre0 device headroom.This repeats for every future packet:gre0->needed_headroom gets inflated because previous packets ipip0 stepincremented rt->dev (gre0) headroom, and ipip0 incremented because gre0needed_headroom was increased.For each subsequent packet, gre/ipip0->needed_headroom grows untilpost-expand-head reallocations result in a skb->head/data distance ofmore than 64k.Once that happens, skb->network_header (u16) wraps around whenpskb_expand_head tries to make sure that skb_network_offset() is unchangedafter the headroom expansion/reallocation.After this skb_network_offset(skb) returns a different (and negative)result post headroom expansion.The next trip to neigh layer (or anything else that would __skb_pull thenetwork header) makes skb->data point to a memory location outsideskb->head area.v2: Cap the needed_headroom update to an arbitarily chosen upperlimit toprevent perpetual increase instead of dropping the headroom incrementcompletely.
openEuler评分:
5.5
Vector:CVSS:2.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
受影响版本排查(受影响/不受影响):
1.openEuler-20.03-LTS-SP1(4.19.90):受影响
2.openEuler-20.03-LTS-SP4(4.19.90):受影响
3.openEuler-22.03-LTS(5.10.0):受影响
4.openEuler-22.03-LTS-SP1(5.10.0):受影响
5.openEuler-22.03-LTS-SP2(5.10.0):受影响
6.openEuler-22.03-LTS-SP3(5.10.0):受影响
7.master(6.1.0):不受影响
8.openEuler-22.03-LTS-Next(5.10.0):不受影响
9.openEuler-24.03-LTS:不受影响
10.openEuler-24.03-LTS-Next:不受影响
修复是否涉及abi变化(是/否):
1.openEuler-20.03-LTS-SP1(4.19.90):否
2.openEuler-20.03-LTS-SP4(4.19.90):否
3.openEuler-22.03-LTS(5.10.0):否
4.openEuler-22.03-LTS-SP1(5.10.0):否
5.openEuler-22.03-LTS-SP2(5.10.0):否
6.openEuler-22.03-LTS-SP3(5.10.0):否
7.master(6.1.0):否
8.openEuler-22.03-LTS-Next(5.10.0):否
9.openEuler-24.03-LTS:否
10.openEuler-24.03-LTS-Next:否
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。
@YangYingliang ,@成坚 (CHENG Jian) ,@jiaoff ,@AlexGuo ,@hanjun-guo ,@woqidaideshi ,@Jackie Liu ,@Zhang Yi ,@colyli ,@ThunderTown ,@htforge ,@Chiqijun ,@冷嘲啊 ,@zhujianwei001 ,@kylin-mayukun ,@wangxiongfeng ,@Kefeng ,@SuperSix173 ,@WangShaoBo ,@Zheng Zucheng
issue处理注意事项:
1. 当前issue受影响的分支提交pr时, 须在pr描述中填写当前issue编号进行关联, 否则无法关闭当前issue;
2. 模板内容需要填写完整, 无论是受影响或者不受影响都需要填写完整内容,未引入的分支不需要填写, 否则无法关闭当前issue;
3. 以下为模板中需要填写完整的内容, 请复制到评论区回复, 注: 内容的标题名称(影响性分析说明, openEuler评分, 受影响版本排查(受影响/不受影响), 修复是否涉及abi变化(是/否))不能省略,省略后cve-manager将无法正常解析填写内容.
影响性分析说明:
openEuler评分: (评分和向量)
受影响版本排查(受影响/不受影响):
1.master(6.1.0):
2.openEuler-20.03-LTS-SP1(4.19.90):
3.openEuler-20.03-LTS-SP4:
4.openEuler-22.03-LTS(5.10.0):
5.openEuler-22.03-LTS-Next(5.10.0):
6.openEuler-22.03-LTS-SP1(5.10.0):
7.openEuler-22.03-LTS-SP2(5.10.0):
8.openEuler-22.03-LTS-SP3:
9.openEuler-24.03-LTS:
10.openEuler-24.03-LTS-Next:
修复是否涉及abi变化(是/否):
1.master(6.1.0):
2.openEuler-20.03-LTS-SP1(4.19.90):
3.openEuler-20.03-LTS-SP4:
4.openEuler-22.03-LTS(5.10.0):
5.openEuler-22.03-LTS-Next(5.10.0):
6.openEuler-22.03-LTS-SP1(5.10.0):
7.openEuler-22.03-LTS-SP2(5.10.0):
8.openEuler-22.03-LTS-SP3:
9.openEuler-24.03-LTS:
10.openEuler-24.03-LTS-Next:
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补丁工具。
若补丁不准确,烦请在此issue下评论 '/report-patch 参考网址 补丁链接1,补丁链接2' 反馈正确信息,便于我们不断优化工具,不胜感激。
如 /report-patch https://security-tracker.debian.org/tracker/CVE-2021-3997 https://github.com/systemd/systemd/commit/5b1cf7a9be37e20133c0208005274ce4a5b5c6a1
@ci-robot 请确认分支: master,openEuler-20.03-LTS-SP1,openEuler-20.03-LTS-SP4,openEuler-22.03-LTS,openEuler-22.03-LTS-Next,openEuler-22.03-LTS-SP1,openEuler-22.03-LTS-SP2,openEuler-22.03-LTS-SP3,openEuler-24.03-LTS,openEuler-24.03-LTS-Next 受影响/不受影响.
请确认分支信息是否填写完整,否则将无法关闭当前issue.
@ci-robot 请确认分支: master,openEuler-20.03-LTS-SP1,openEuler-20.03-LTS-SP4,openEuler-22.03-LTS,openEuler-22.03-LTS-Next,openEuler-22.03-LTS-SP1,openEuler-22.03-LTS-SP2,openEuler-22.03-LTS-SP3,openEuler-24.03-LTS,openEuler-24.03-LTS-Next 受影响/不受影响.
请确认分支信息是否填写完整,否则将无法关闭当前issue.
@zhangchangzhong 请确认分支: master,openEuler-20.03-LTS-SP1,openEuler-20.03-LTS-SP4,openEuler-22.03-LTS,openEuler-22.03-LTS-Next,openEuler-22.03-LTS-SP1,openEuler-22.03-LTS-SP2,openEuler-22.03-LTS-SP3,openEuler-24.03-LTS,openEuler-24.03-LTS-Next 受影响/不受影响.
请确认分支信息是否填写完整,否则将无法关闭当前issue.
@chenyi 请确认分支: master,openEuler-20.03-LTS-SP1,openEuler-20.03-LTS-SP4,openEuler-22.03-LTS,openEuler-22.03-LTS-Next,openEuler-22.03-LTS-SP1,openEuler-22.03-LTS-SP2,openEuler-22.03-LTS-SP3,openEuler-24.03-LTS,openEuler-24.03-LTS-Next 受影响/不受影响.
请确认分支信息是否填写完整,否则将无法关闭当前issue.
@zhangjialin 请确认分支: master,openEuler-20.03-LTS-SP1,openEuler-20.03-LTS-SP4,openEuler-22.03-LTS,openEuler-22.03-LTS-Next,openEuler-22.03-LTS-SP1,openEuler-22.03-LTS-SP2,openEuler-22.03-LTS-SP3,openEuler-24.03-LTS,openEuler-24.03-LTS-Next 受影响/不受影响.
请确认分支信息是否填写完整,否则将无法关闭当前issue.
CVE-2024-26804
影响性分析说明:
In the Linux kernel, the following vulnerability has been resolved:
net: ip_tunnel: prevent perpetual headroom growth
syzkaller triggered following kasan splat:
BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170
Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191
[..]
kasan_report+0xda/0x110 mm/kasan/report.c:588
__skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170
skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline]
___skb_get_hash net/core/flow_dissector.c:1791 [inline]
__skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856
skb_get_hash include/linux/skbuff.h:1556 [inline]
ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748
ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308
__netdev_start_xmit include/linux/netdevice.h:4940 [inline]
netdev_start_xmit include/linux/netdevice.h:4954 [inline]
xmit_one net/core/dev.c:3548 [inline]
dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564
__dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592
...
ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235
ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323
..
iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82
ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831
ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665
__netdev_start_xmit include/linux/netdevice.h:4940 [inline]
netdev_start_xmit include/linux/netdevice.h:4954 [inline]
xmit_one net/core/dev.c:3548 [inline]
dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564
...
The splat occurs because skb->data points past skb->head allocated area.
This is because neigh layer does:
__skb_pull(skb, skb_network_offset(skb));
... but skb_network_offset() returns a negative offset and __skb_pull()
arg is unsigned. IOW, we skb->data gets "adjusted" by a huge value.
The negative value is returned because skb->head and skb->data distance is
more than 64k and skb->network_header (u16) has wrapped around.
The bug is in the ip_tunnel infrastructure, which can cause
dev->needed_headroom to increment ad infinitum.
The syzkaller reproducer consists of packets getting routed via a gre
tunnel, and route of gre encapsulated packets pointing at another (ipip)
tunnel. The ipip encapsulation finds gre0 as next output device.
This results in the following pattern:
1). First packet is to be sent out via gre0.
Route lookup found an output device, ipip0.
2).
ip_tunnel_xmit for gre0 bumps gre0->needed_headroom based on the future
output device, rt.dev->needed_headroom (ipip0).
3).
ip output / start_xmit moves skb on to ipip0. which runs the same
code path again (xmit recursion).
4).
Routing step for the post-gre0-encap packet finds gre0 as output device
to use for ipip0 encapsulated packet.
tunl0->needed_headroom is then incremented based on the (already bumped)
gre0 device headroom.
This repeats for every future packet:
gre0->needed_headroom gets inflated because previous packets' ipip0 step
incremented rt->dev (gre0) headroom, and ipip0 incremented because gre0
needed_headroom was increased.
For each subsequent packet, gre/ipip0->needed_headroom grows until
post-expand-head reallocations result in a skb->head/data distance of
more than 64k.
Once that happens, skb->network_header (u16) wraps around when
pskb_expand_head tries to make sure that skb_network_offset() is unchanged
after the headroom expansion/reallocation.
After this skb_network_offset(skb) returns a different (and negative)
result post headroom expansion.
The next trip to neigh layer (or anything else that would __skb_pull the
network header) makes skb->data point to a memory location outside
skb->head area.
v2: Cap the needed_headroom update to an arbitarily chosen upperlimit to
prevent perpetual increase instead of dropping the headroom increment
completely.
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-SP1:受影响
2.openEuler-20.03-LTS-SP4:受影响
3.openEuler-22.03-LTS:受影响
4.openEuler-22.03-LTS-SP1:受影响
5.openEuler-22.03-LTS-SP2:受影响
6.openEuler-22.03-LTS-SP3:受影响
7.master(6.1.0):不受影响
8.openEuler-22.03-LTS-Next:不受影响
9.openEuler-24.03-LTS:不受影响
10.openEuler-24.03-LTS-Next:不受影响
修复是否涉及abi变化(是/否):
1.openEuler-20.03-LTS-SP1(4.19.90):否
2.openEuler-20.03-LTS-SP4:否
3.openEuler-22.03-LTS:否
4.openEuler-22.03-LTS-SP1:否
5.openEuler-22.03-LTS-SP2:否
6.openEuler-22.03-LTS-SP3:否
7.master(6.1.0):否
8.openEuler-22.03-LTS-Next:否
9.openEuler-24.03-LTS:否
10.openEuler-24.03-LTS-Next:否
===========================================================
@成坚 (CHENG Jian) ,@Xie XiuQi ,@YangYingliang ,@pi3orama ,@jiaoff ,@郭梦琪
关闭issue前,需要将受影响的分支在合并pr时关联上当前issue编号: #I9E47C:CVE-2024-26804
受影响分支: openEuler-22.03-LTS/openEuler-22.03-LTS-SP1/openEuler-22.03-LTS-SP2
具体操作参考: https://gitee.com/help/articles/4142
登录 后才可以发表评论