Star12
94
Code
Code
Issues5521
Pull Requests9
Discussion
Wiki
Analysis
Star12
94
Open
CVE-2026-81001 #19912
zhangxiaoxuAdd on  Sep 30
Z
zhangxiaoxu
Sep 30 Create

一、漏洞信息
漏洞编号：CVE-2026-81001
漏洞归属组件：kernel
漏洞归属的版本：5.10.0
CVSS评分：
BaseScore：7.8 High
Vector：CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
漏洞简述：
In the Linux kernel, the following vulnerability has been resolved:slip: fix use-after-free in sl_sync()slip_devs[] stores bare net_device pointers and takes no reference onthem. sl_sync() and sl_alloc() walk that table from slip_open() underrtnl_lock(), while an entry is dropped by sl_free_netdev(), whichsl_setup() installs as dev->priv_destructor.priv_destructor is called from netdev_run_todo(), which deliberatelyruns with the RTNL semaphore released so that it can sleep while waitingfor the device refcount to drop: /* Snapshot list, allow later requests / list_replace_init(&net_todo_list, &list); __rtnl_unlock(); ... if (dev->priv_destructor) dev->priv_destructor(dev); / slip_devs[i] = NULL / if (dev->needs_free_netdev) free_netdev(dev); ... / Free network device / kobject_put(&dev->dev.kobj);So rtnl_lock() does not serialise slip_open() against the teardown atall. sl_sync() can load slip_devs[i] while the entry is still publishedand dereference it after netdev_run_todo() has run the destructor andreleased the device: CPU0 (slip_open) CPU1 (slip_close) unregister_netdev() rtnl_unlock() netdev_run_todo() __rtnl_unlock() rtnl_lock() sl_sync() dev = slip_devs[i] priv_destructor(dev) slip_devs[i] = NULL kobject_put(&dev->dev.kobj) / dev is freed / sl = netdev_priv(dev) if (sl->tty || sl->leased) / use-after-free */ BUG: KASAN: use-after-free in sl_sync drivers/net/slip/slip.c:730 [inline] BUG: KASAN: use-after-free in slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806 Read of size 1 at addr ffff8880712dac71 by task syz-executor.2/6506 CPU: 2 PID: 6506 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00260-g0c8fc3469765 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Call Trace: sl_sync drivers/net/slip/slip.c:730 [inline] slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564 tiocsetd drivers/tty/tty_io.c:2428 [inline] tty_ioctl+0x5f0/0x1530 drivers/tty/tty_io.c:2712 Allocated by task 6502: alloc_netdev_mqs+0x98/0xfe0 net/core/dev.c:10719 sl_alloc drivers/net/slip/slip.c:756 [inline] slip_open+0x36d/0x1210 drivers/net/slip/slip.c:817 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564 Freed by task 6497: device_release+0xa2/0x240 drivers/base/core.c:2507 kobject_put+0x179/0x280 lib/kobject.c:729 netdev_run_todo+0x6c8/0xef0 net/core/dev.c:10509 slip_close+0x166/0x1c0 drivers/net/slip/slip.c:906 tty_ldisc_close+0x113/0x1a0 drivers/tty/tty_ldisc.c:456 tty_ldisc_kill+0x94/0x160 drivers/tty/tty_ldisc.c:614 tty_ldisc_release+0xe3/0x2b0 drivers/tty/tty_ldisc.c:782 tty_release+0xbcc/0xe70 drivers/tty/tty_io.c:1860Commit e58c19124189 ( slip: Fix use-after-free Read in slip_open ) fixeda different source of stale entries - a device left in slip_devs[] afterslip_open() freed it on the registration error path - and does notaddress this race, which is why the report survives it.Drop the entry from ndo_uninit instead. unregister_netdevice() callsndo_uninit under RTNL, before the device is queued to netdev_run_todo(),so an entry that sl_sync() can still see while holding RTNL belongs to adevice that cannot be freed until RTNL is dropped. sl_free_netdev()stays only for the slip_open() error path, where register_netdevice()may have failed before ndo_init and ndo_uninit is then not calledeither. Both running for the same device is harmless: the---truncated---
漏洞公开时间：2026-09-12 04:19:08
漏洞创建时间：2026-09-30 01:06:09
漏洞详情参考链接：
https://nvd.nist.gov/vuln/detail/CVE-2026-81001

更多参考(点击展开)

无

漏洞分析指导链接：
https://atomgit.com/openeuler/cve-manager/blob/master/cve-vulner-manager/doc/md/manual.md
漏洞数据来源:
其他
漏洞补丁信息：

详情(点击展开)

无

二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:slip: fix use-after-free in sl_sync()slip_devs[] stores bare net_device pointers and takes no reference onthem. sl_sync() and sl_alloc() walk that table from slip_open() underrtnl_lock(), while an entry is dropped by sl_free_netdev(), whichsl_setup() installs as dev->priv_destructor.priv_destructor is called from netdev_run_todo(), which deliberatelyruns with the RTNL semaphore released so that it can sleep while waitingfor the device refcount to drop:/* Snapshot list, allow later requests /list_replace_init(&net_todo_list, &list);__rtnl_unlock();...if (dev->priv_destructor)dev->priv_destructor(dev);/ slip_devs[i] = NULL /if (dev->needs_free_netdev)free_netdev(dev);.../ Free network device /kobject_put(&dev->dev.kobj);So rtnl_lock() does not serialise slip_open() against the teardown atall. sl_sync() can load slip_devs[i] while the entry is still publishedand dereference it after netdev_run_todo() has run the destructor andreleased the device: CPU0 (slip_open) CPU1 (slip_close) unregister_netdev() rtnl_unlock() netdev_run_todo() __rtnl_unlock() rtnl_lock() sl_sync() dev = slip_devs[i] priv_destructor(dev) slip_devs[i] = NULL kobject_put(&dev->dev.kobj) / dev is freed / sl = netdev_priv(dev) if (sl->tty || sl->leased) / use-after-free */ BUG: KASAN: use-after-free in sl_sync drivers/net/slip/slip.c:730 [inline] BUG: KASAN: use-after-free in slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806 Read of size 1 at addr ffff8880712dac71 by task syz-executor.2/6506 CPU: 2 PID: 6506 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00260-g0c8fc3469765 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Call Trace: sl_sync drivers/net/slip/slip.c:730 [inline] slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564 tiocsetd drivers/tty/tty_io.c:2428 [inline] tty_ioctl+0x5f0/0x1530 drivers/tty/tty_io.c:2712 Allocated by task 6502: alloc_netdev_mqs+0x98/0xfe0 net/core/dev.c:10719 sl_alloc drivers/net/slip/slip.c:756 [inline] slip_open+0x36d/0x1210 drivers/net/slip/slip.c:817 tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433 tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564 Freed by task 6497: device_release+0xa2/0x240 drivers/base/core.c:2507 kobject_put+0x179/0x280 lib/kobject.c:729 netdev_run_todo+0x6c8/0xef0 net/core/dev.c:10509 slip_close+0x166/0x1c0 drivers/net/slip/slip.c:906 tty_ldisc_close+0x113/0x1a0 drivers/tty/tty_ldisc.c:456 tty_ldisc_kill+0x94/0x160 drivers/tty/tty_ldisc.c:614 tty_ldisc_release+0xe3/0x2b0 drivers/tty/tty_ldisc.c:782 tty_release+0xbcc/0xe70 drivers/tty/tty_io.c:1860Commit e58c19124189 ("slip: Fix use-after-free Read in slip_open") fixeda different source of stale entries - a device left in slip_devs[] afterslip_open() freed it on the registration error path - and does notaddress this race, which is why the report survives it.Drop the entry from ndo_uninit instead. unregister_netdevice() callsndo_uninit under RTNL, before the device is queued to netdev_run_todo(),so an entry that sl_sync() can still see while holding RTNL belongs to adevice that cannot be freed until RTNL is dropped. sl_free_netdev()stays only for the slip_open() error path, where register_netdevice()may have failed before ndo_init and ndo_uninit is then not calledeither. Both running for the same device is harmless: they run underthe same RTNL section, so the slot cannot have been reused in between.This also removes the second symptom of the missing exclusion: adestructor running after sl_al
openEuler评分：
7.8
Vector：CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
受影响版本排查(受影响/不受影响)：
1.master(6.18.40):不受影响
2.openEuler-20.03-LTS-SP4(4.19.90):受影响
3.openEuler-22.03-LTS-SP4(5.10.0):受影响
4.openEuler-24.03-LTS-Next(6.6.0):不受影响
5.openEuler-24.03-LTS-SP1(6.6.0):受影响
6.openEuler-24.03-LTS-SP3(6.6.0):受影响
7.openEuler-24.03-LTS-SP4(6.6.0):受影响
8.openEuler-22.03-LTS-SP3(5.10.0):受影响
9.openEuler-24.03-LTS(6.6.0):受影响
10.openEuler-24.03-LTS-SP2(6.6.0):受影响

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

原因说明：
1.master(6.18.40):不受影响-漏洞代码不能被攻击者触发
2.openEuler-20.03-LTS-SP4(4.19.90):暂不修复-暂无解决方案或补丁
3.openEuler-22.03-LTS-SP4(5.10.0):暂不修复-漏洞仍在分析中
4.openEuler-24.03-LTS-Next(6.6.0):不受影响-漏洞代码不能被攻击者触发
5.openEuler-24.03-LTS-SP1(6.6.0):暂不修复-漏洞仍在分析中
6.openEuler-24.03-LTS-SP3(6.6.0):暂不修复-漏洞仍在分析中
7.openEuler-24.03-LTS-SP4(6.6.0):暂不修复-漏洞仍在分析中
8.openEuler-22.03-LTS-SP3(5.10.0):不修复-超出修复范围
9.openEuler-24.03-LTS(6.6.0):不修复-超出修复范围
10.openEuler-24.03-LTS-SP2(6.6.0):不修复-超出修复范围

likedislike
devstation-robot
devstation-robot
Sep 30 Comments：

检测到新建 CVE Issue，CVE-ID: CVE-2026-81001。

你可以通过以下两种方式使用 CVE 修复服务：

  1. 分支影响分析

    • 在本 Issue 下评论：/analysis_branches
    • 系统将自动分析各个分支是否受影响，并在本 Issue 下给出表格形式的分析结果；

  2. 在指定分支上创建 PR（修复提交）

    • 在本 Issue 下按如下格式评论（branch、name、email 为必填字段，每个字段单独一行）：
/create_pr

branch: OLK-6.6 OLK-5.10
name: dev
email: dev@devstation.com
backport-engine: opencode
  • 说明：
    • branch: 需要创建 PR 的目标分支列表，例如 OLK-6.6 OLK-5.10；
    • name: PR 签名人姓名（如责任人或安全负责人）；
    • email: PR 签名人邮箱；
    • backport-engine（可选）：可选 portgpt、mystique 或 opencode；不填时默认使用 opencode；

系统会根据上述信息自动在指定分支上创建 PR，并在本 Issue 下反馈结果。

provided by DevStation.

likedislike
openeuler-ci-botopeneuler-ci-botCollaborators
Sep 30 Assign wkfxxx、zeng_zhaorong、sanglipeng、oekernel、zhangxiaoxv、hanjunguo as responsible person
openeuler-ci-botopeneuler-ci-botCollaborators
Sep 30 Added label: sig/Kernel
openeuler-ci-bot
openeuler-ci-botCollaborators
Sep 30 Comments：

Welcome To openEuler Community

Hey @zhangxiaoxv , thanks for your contribution to the community.

Bot Usage Manual

I'm the Bot here serving you. You can find the instructions on how to interact with me at Here . That means you can comment below every pull request or issue to trigger Bot Commands. You can self-configure the PR merge rules for this repository. For more details, please refer to Here.

Contact Guide

If you have any questions, please contact the SIG: Kernel ,
and any of the maintainers: @hanjunguo, @oekernel, @sanglipeng, @wkfxxx, @zeng_zhaorong ,
and any of the committers: @CTC-XiboWang, @Frank_Sae, @GoGo_phytium, @GongLei-, @LiuYongQiang0816, @SuperSix173, @Tankll2021, @TrueAI, @YiweiZ, @allen-shi, @alvin-ling, @baratta, @bibo_mao, @caixu-blue, @chen-jun-hw, @chenjiesong, @chenjunxin1992, @chenke2026, @chiqijun, @chriszjh, @duanqiangwen, @eingesch, @fangfeng123, @fanghaiqinghw, @gang_he, @gaojuxin09, @gouhao2022, @guohaocs2c, @guzitao, @hanjunguo, @hanliyang, @hellotcc, @henryze, @hewanhan, @hjx_gitff, @hongwu-wang, @howard_lu, @htforge, @hu-chunzhi, @hunan4222, @jackknight, @jerry_lilijun, @jiayi0118, @junlong-zheng, @juntianlinux, @kailiu42, @kaitiandu, @kazero00, @kevinzhu1, @kile2009, @klmengkd, @koishimind, @kongzizaixian, @kunlun_spurs, @kylin-mayukun, @leoliu-oc, @li-huisong, @linan888, @linyunsheng, @liulongfang, @liyihang0226, @lostway1, @lujialin2, @mao-hongbo, @markyuan4ta21, @mawupeng, @mingqian218472, @mingrui-liu, @mufengyan, @nebulamatrix_rdma, @peterpangogogo, @pigalsofine, @robinorg, @rock_hw, @sanglipeng, @shu-shengming, @shuaijiakun, @siyanteng, @sming56_admin, @stavewu, @stkid, @sun_nanyong, @wangboe2022, @wanghang73, @wenzhiwei11, @whoisxxx, @wkfxxx, @woqidaideshi, @wsoydl, @xingmz1, @xukuohai, @yeweihua999, @ygn-ndwd-official, @yonghu_4dc5, @young-sun, @yubo-liu1, @yuehaibing_planb, @yuzenghui1, @zhang-changzhong, @zhangyi089, @zhujianwei001, @zichengqu, @zouyipeng, @zqiao216 .

likedislike
Zzhangxiaoxu
Sep 30 Associated pull request
openeuler-ci-botopeneuler-ci-botCollaborators
Sep 30 Modify description of issue
openeuler-ci-botopeneuler-ci-botCollaborators
Sep 30 Assign GoGo_phytium as responsible person, remove original responsible person: wkfxxx、zeng_zhaorong、sanglipeng、oekernel、zhangxiaoxv、hanjunguo
openeuler-ci-bot
openeuler-ci-botCollaborators
Sep 30 Comments：

issue处理注意事项:
1. 提交正常修复分支的修复PR时,必须关联当前issue,否则无法关闭当前issue;
2. 模板内容需要填写完整, 无论是受影响或者不受影响都需要填写完整内容;
3. 以下为模板中需要填写完整的内容, 请复制到评论区回复;
注: 内容的关键词(影响性分析说明, openEuler评分, 受影响版本排查(受影响/不受影响), 修复是否涉及abi变化(是/否), 原因说明)不能省略,省略后cve-manager将无法正常解析填写内容.

影响性分析说明:

openEuler评分: (评分和向量)

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

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

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

原因说明填写请参考下方表格(注意：版本是否受影响和版本的原因说明必须对应，例如master版本分支受影响，那原因说明只能是受影响对应的原因之一!)：

分支状态
原因说明 使用场景
受影响 正常修复 受影响且需要修复（包含升级版本修复）的漏洞；
受影响且已经修复的漏洞（历史修复PR也需要关联issue）；
若因特殊原因无法修复，应修改原因说明为【不修复-特殊原因】，并在安委会备案相关情况。
受影响 暂不修复-漏洞仍在分析中 已关注到相关漏洞，正在处理，未明确漏洞影响和修复方案。
受影响 暂不修复-暂无解决方案或补丁 当前没有可用的修复或补救措施。【影响性分析】中应包含有关为什么没有修复或补救措施的详细说明、上游相关PR等。
受影响 不修复-超出修复范围 没有漏洞的修复计划。当版本停维、软件包宣布生命周期终止或弃用使用。
受影响 不修复-特殊原因导致不再修复 如存在其他特殊情况不修复相关漏洞，或评估后无法升级修复，应在openEuler社区安全委员会例会进行说明备案。
【影响性分析】中应包含不发布修复的详细说明、特殊情况还应有安委会会议纪要。
不受影响 不受影响-组件不存在 软件不受影响，因为易受攻击的组件不在产品中。
不受影响 不受影响-已有内置的内联控制或缓解措施 内置的内联控制或缓解措施可防止攻击者利用漏洞
不受影响 不受影响-漏洞代码不能被攻击者触发 易受攻击的组件存在，并且该组件包含易受攻击的代码。但是，易受攻击的代码的使用方式使得攻击者无法进行任何预期的攻击。
不受影响 不受影响-漏洞代码不在执行路径 易受影响的代码在执行过程中不可访问，包括产品的非预期状态。产品不使用也不执行的组件。
不受影响 不受影响-漏洞代码不存在 产品不受影响，因为漏洞背后的代码在产品中不存在。与component_not_present不同的是，有问题的组件存在，但由于某种原因（例如安全的编译器选项）使漏洞的特定代码不存在于组件中。

issue处理具体操作请参考:
https://atomgit.com/openeuler/cve-manager/blob/master/cve-vulner-manager/doc/md/manual.md
pr关联issue具体操作请参考:
https://docs.atomgit.com/docs/help/home/org_project/pullrequests/pr-related-issue

likedislike
openeuler-ci-botopeneuler-ci-botCollaborators
Sep 30 Added label: CVE/UNFIXED
openeuler-ci-bot
openeuler-ci-botCollaborators
Sep 30 Comments：
参考网址 关联pr 状态 补丁链接
https://www.opencve.io/cve/CVE-2026-81001
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2026-81001
https://security-tracker.debian.org/tracker/CVE-2026-81001NoneNonehttps://git.kernel.org/linus/2c4e7c42d77e78ad595dbb9e4b5886b58b45d89d
http://www.cnnvd.org.cn/web/vulnerability/queryLds.tag?qcvCnnvdid=CVE-2026-81001
https://nvd.nist.gov/vuln/detail/CVE-2026-81001
https://ubuntu.com/security/CVE-2026-81001NoneNonehttps://git.kernel.org/linus/5342b77c4123ba39f911d92a813295fb3bb21f69
https://discourse.ubuntu.com/c/project
https://git.kernel.org/stable/c/2c4e7c42d77e78ad595dbb9e4b5886b58b45d89d
https://git.kernel.org/stable/c/d6f25e5bd777b05880da8673daf74a8419480545
https://git.kernel.org/linus/2c4e7c42d77e78ad595dbb9e4b5886b58b45d89d
https://git.kernel.org/stable/c/486577db807891d0f964fdf13c1640c7f54b0ad1
https://git.kernel.org/stable/c/a235b20972bbd98ca1fb127d6269434edc607f19

说明：补丁链接仅供初步排查参考，实际可用性请人工再次确认，补丁下载验证可使用CVE补丁工具。
若补丁不准确，烦请在此issue下评论 '/report-patch 参考网址 补丁链接1,补丁链接2' 反馈正确信息，便于我们不断优化工具，不胜感激。
如 /report-patch https://security-tracker.debian.org/tracker/CVE-2021-3997 https://github.com/systemd/systemd/commit/5b1cf7a9be37e20133c0208005274ce4a5b5c6a1

likedislike
openeuler-ci-bot
openeuler-ci-botCollaborators
Sep 30 Comments：

@zhangxiaoxv CVE信息从NVD同步成功, 稍后请重新加载页面.

likedislike
openeuler-ci-botopeneuler-ci-botCollaborators
Sep 30 Modify description of issue
H
hulk-ci-botCollaborators
Oct 4 Comments：

CVE-2026-81001

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

slip: fix use-after-free in sl_sync()

slip_devs[] stores bare net_device pointers and takes no reference on
them. sl_sync() and sl_alloc() walk that table from slip_open() under
rtnl_lock(), while an entry is dropped by sl_free_netdev(), which
sl_setup() installs as dev->priv_destructor.

priv_destructor is called from netdev_run_todo(), which deliberately
runs with the RTNL semaphore released so that it can sleep while waiting
for the device refcount to drop:

/* Snapshot list, allow later requests */
list_replace_init(&net_todo_list, &list);

__rtnl_unlock();
...
	if (dev->priv_destructor)
		dev->priv_destructor(dev);	/* slip_devs[i] = NULL */
	if (dev->needs_free_netdev)
		free_netdev(dev);
	...
	/* Free network device */
	kobject_put(&dev->dev.kobj);

So rtnl_lock() does not serialise slip_open() against the teardown at
all. sl_sync() can load slip_devs[i] while the entry is still published
and dereference it after netdev_run_todo() has run the destructor and
released the device:

CPU0 (slip_open) CPU1 (slip_close)
unregister_netdev()
rtnl_unlock()
netdev_run_todo()
__rtnl_unlock()
rtnl_lock()
sl_sync()
dev = slip_devs[i]
priv_destructor(dev)
slip_devs[i] = NULL
kobject_put(&dev->dev.kobj)
/* dev is freed /
sl = netdev_priv(dev)
if (sl->tty || sl->leased) / use-after-free */

BUG: KASAN: use-after-free in sl_sync drivers/net/slip/slip.c:730 [inline]
BUG: KASAN: use-after-free in slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806
Read of size 1 at addr ffff8880712dac71 by task syz-executor.2/6506

CPU: 2 PID: 6506 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00260-g0c8fc3469765 #0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
Call Trace:
sl_sync drivers/net/slip/slip.c:730 [inline]
slip_open+0xef4/0x1210 drivers/net/slip/slip.c:806
tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433
tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564
tiocsetd drivers/tty/tty_io.c:2428 [inline]
tty_ioctl+0x5f0/0x1530 drivers/tty/tty_io.c:2712

Allocated by task 6502:
alloc_netdev_mqs+0x98/0xfe0 net/core/dev.c:10719
sl_alloc drivers/net/slip/slip.c:756 [inline]
slip_open+0x36d/0x1210 drivers/net/slip/slip.c:817
tty_ldisc_open+0xa2/0x120 drivers/tty/tty_ldisc.c:433
tty_set_ldisc+0x324/0x720 drivers/tty/tty_ldisc.c:564

Freed by task 6497:
device_release+0xa2/0x240 drivers/base/core.c:2507
kobject_put+0x179/0x280 lib/kobject.c:729
netdev_run_todo+0x6c8/0xef0 net/core/dev.c:10509
slip_close+0x166/0x1c0 drivers/net/slip/slip.c:906
tty_ldisc_close+0x113/0x1a0 drivers/tty/tty_ldisc.c:456
tty_ldisc_kill+0x94/0x160 drivers/tty/tty_ldisc.c:614
tty_ldisc_release+0xe3/0x2b0 drivers/tty/tty_ldisc.c:782
tty_release+0xbcc/0xe70 drivers/tty/tty_io.c:1860

Commit e58c19124189 ("slip: Fix use-after-free Read in slip_open") fixed
a different source of stale entries - a device left in slip_devs[] after
slip_open() freed it on the registration error path - and does not
address this race, which is why the report survives it.

Drop the entry from ndo_uninit instead. unregister_netdevice() calls
ndo_uninit under RTNL, before the device is queued to netdev_run_todo(),
so an entry that sl_sync() can still see while holding RTNL belongs to a
device that cannot be freed until RTNL is dropped. sl_free_netdev()
stays only for the slip_open() error path, where register_netdevice()
may have failed before ndo_init and ndo_uninit is then not called
either. Both running for the same device is harmless: they run under
the same RTNL section, so the slot cannot have been reused in between.

This also removes the second symptom of the missing exclusion: a
destructor running after sl_alloc() had already handed the slot out to
another channel used to clear a live entry, so sl_sync() stopped at that
NULL, sl_alloc() returned the same index again, and
register_netdevice() failed with -EEXIST because slN was still there.

Reproduced on x86_64 with several threads looping over
open("/dev/ptmx") + ioctl(TIOCSETD, N_SLIP) + close().

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

The Linux kernel CVE team has assigned CVE-2026-81001 to this issue.

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

受影响版本排查(受影响/不受影响):
1.master:不受影响
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:受影响
8.openEuler-24.03-LTS-SP2:受影响
9.openEuler-24.03-LTS-SP3:受影响
10.openEuler-24.03-LTS-SP4:受影响

修复是否涉及abi变化(是/否)：
1.master:否
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:否
8.openEuler-24.03-LTS-SP2:否
9.openEuler-24.03-LTS-SP3:否
10.openEuler-24.03-LTS-SP4:否

原因说明：
1.master:不受影响-漏洞代码不能被攻击者触发
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:暂不修复-漏洞仍在分析中
8.openEuler-24.03-LTS-SP2:不修复-超出修复范围
9.openEuler-24.03-LTS-SP3:暂不修复-漏洞仍在分析中
10.openEuler-24.03-LTS-SP4:暂不修复-漏洞仍在分析中

likedislike
openeuler-ci-botopeneuler-ci-botCollaborators
Oct 4 Modify description of issue
openeuler-ci-bot
openeuler-ci-botCollaborators
Oct 4 Comments：

@GoGo_phytium 经过 cve-manager 解析, 已分析的内容如下表所示:

状态 分析项目 内容
已分析 1.影响性分析说明 In the Linux kernel, the following vulnerability has been resolved:slip: fix use-after-free in sl_sync()slip_devs[] stores bare net_device pointers and takes no reference onthem. sl_sync() and sl_alloc() walk that table from slip_open() underrtnl_lock(), while an entry is dropped by sl_free_netdev(), whichsl_setup() installs as dev->priv_destructor.priv_destructor is called from netdev_run_todo(), which deliberatelyruns with the RTNL semaphore released so that it can sleep while waitingfor the device refcount to drop:/* Snapshot list, allow later requests /list_replace_init(&net_todo_list, &list);__rtnl_unlock();...if (dev->priv_destructor)dev->priv_destructor(dev);/ slip_devs[i] = NULL /if (dev->needs_free_netdev)free_netdev(dev);.../ Free network device /kobject_put(&dev->dev.kobj);So rtnl_lock() does not serialise slip_open() against the teardown atall. sl_sync() can load slip_devs[i] while the entry is still publishedand dereference it after netdev_run_todo() has run the destructor andreleased the device: CPU0 (slip_open) CPU1 (slip_close) unregister_netdev() rtnl_unlock() netdev_run_todo() __rtnl_unlock() rtnl_lock() sl_sync() dev = slip_devs[i] priv_destructor(dev) slip_devs[i] = NULL kobject_put(&dev->dev.kobj) / dev is freed */ sl = netdev_priv(dev) if (sl->tty
已分析 2.openEulerScore 7.8
已分析 3.openEulerVector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
已分析 4.受影响版本排查 master:不受影响,openEuler-20.03-LTS-SP4:受影响,openEuler-22.03-LTS-SP4:受影响,openEuler-24.03-LTS-Next:不受影响,openEuler-24.03-LTS-SP1:受影响,openEuler-24.03-LTS-SP3:受影响,openEuler-24.03-LTS-SP4:受影响,openEuler-22.03-LTS-SP3:受影响,openEuler-24.03-LTS:受影响,openEuler-24.03-LTS-SP2:受影响
已分析 5.是否涉及abi变化 master:否,openEuler-20.03-LTS-SP4:否,openEuler-22.03-LTS-SP4:否,openEuler-24.03-LTS-Next:否,openEuler-24.03-LTS-SP1:否,openEuler-24.03-LTS-SP3:否,openEuler-24.03-LTS-SP4:否,openEuler-22.03-LTS-SP3:否,openEuler-24.03-LTS:否,openEuler-24.03-LTS-SP2:否
已分析 6.原因说明 master:不受影响-漏洞代码不能被攻击者触发,openEuler-20.03-LTS-SP4:暂不修复-暂无解决方案或补丁,openEuler-22.03-LTS-SP4:暂不修复-漏洞仍在分析中,openEuler-24.03-LTS-Next:不受影响-漏洞代码不能被攻击者触发,openEuler-24.03-LTS-SP1:暂不修复-漏洞仍在分析中,openEuler-24.03-LTS-SP3:暂不修复-漏洞仍在分析中,openEuler-24.03-LTS-SP4:暂不修复-漏洞仍在分析中,openEuler-22.03-LTS-SP3:不修复-超出修复范围,openEuler-24.03-LTS:不修复-超出修复范围,openEuler-24.03-LTS-SP2:不修复-超出修复范围

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

likedislike
openeuler-ci-botopeneuler-ci-botCollaborators
Oct 4 changed custom state from 待办的 to 进行中
6 event messages are collapsed here。 See more
openeuler-ci-botopeneuler-ci-botCollaborators
7 days ago changed custom state from 进行中 to 待办的