CVE-2026-98547— Linux 内核 af_packet 整数溢出漏洞
一分钟漏洞结论
影响对象
Linux Linux
利用判断
尚无明确在野利用证据，仍需结合暴露面评估
建议动作
优先检查厂商安全公告和参考链接中的修复版本；无法立即升级时，限制受影响服务暴露并加强监测。
在 Linux 内核中，以下漏洞已得到修复： af_packet：修复 prb_calc_retire_blk_tmo() 中的整数溢出问题 函数使用 32 位整数进行算术计算： 根据对验证逻辑的理解， 由用户控制，而 仅拒绝小于等于 0 的整数值或未对齐页大小的值。因此，256 MiB 的块大小可以通过验证（且 甚至为此提供了 回退机制）。 当 为 （即 256 MiB）时，乘以 8 后会发生溢出，结果为 （即 -2147483648）。若网卡报告的速率为 1 Gbps（此时除数 ），该函数最终会返回 。 触发该
影响版本矩阵 18
| 厂商 | 产品 | 版本范围 | 状态 |
|---|---|---|---|
| Linux | Linux | f6fb8f100b807378fda19e83e5ac6828b638603a< 02afd75649a4e001031ed82153a5c39312ec0737 |
affected |
f6fb8f100b807378fda19e83e5ac6828b638603a< eb5b3838b9200dac04bfe33483db0ee8287456fb |
affected | ||
f6fb8f100b807378fda19e83e5ac6828b638603a< 297acc571d5813db76b147c745b91031d5f9c960 |
affected | ||
f6fb8f100b807378fda19e83e5ac6828b638603a< be1aacff399d519cc48d6b34354a54dd79041140 |
affected | ||
f6fb8f100b807378fda19e83e5ac6828b638603a< b2bcc6a254d6f27823a56787668ae4ee8cdb6e71 |
affected | ||
f6fb8f100b807378fda19e83e5ac6828b638603a< 6279211e7d2456ecd195d236c9ee5e5c6fa5a17a |
affected | ||
f6fb8f100b807378fda19e83e5ac6828b638603a< 218a944b9e035d4b47d59c69af6ca13319da15fb |
affected | ||
f6fb8f100b807378fda19e83e5ac6828b638603a< 56d82862a0a243ac14ba11b6d7b57ddc2d064b95 |
affected | ||
| … +10 条更多 | |||
获取后续新漏洞提醒
登录后订阅
一、 漏洞 CVE-2026-98547 基础信息
漏洞信息
对漏洞内容有疑问？看看神龙的深度分析是否有帮助！
查看神龙十问 ↗
尽管我们使用了先进的大模型技术，但其输出仍可能包含不准确或过时的信息。神龙努力确保数据的准确性，但请您根据实际情况进行核实和判断。
Vulnerability Title
af_packet: fix integer overflow in prb_calc_retire_blk_tmo()
来源: CVE Program / CVE List V5
Vulnerability Description
In the Linux kernel, the following vulnerability has been resolved:
af_packet: fix integer overflow in prb_calc_retire_blk_tmo()
prb_calc_retire_blk_tmo() computes in 32-bit int arithmetic:
mbits = (blk_size_in_bytes * 8) / (1024 * 1024);
If I'm reading the validation right, tp_block_size is user
controlled and packet_set_ring() only rejects values that are <= 0
as int or not page aligned, so a 256MiB block goes right through
(and alloc_one_pg_vec_page() even has a vzalloc fallback for it).
0x10000000 * 8 wraps to INT_MIN, and on a NIC reporting 1 Gbps
(div == 1) the function ends up returning -2047.
The condition is actually (8 * size) mod 2^32 >= 2^31 && div == 1,
so the trigger set is [256,512), [768,1024), [1280,1536) and
[1792,2048) MiB. Other sizes wrap to non-negative values and faster
links divide the unsigned value back below 2^31, which is why this
doesn't blow up for everyone.
What makes it fatal is what happens next in init_prb_bdqc():
p1->interval_ktime = ms_to_ktime(prb_calc_retire_blk_tmo(...));
hrtimer_start(&p1->retire_blk_timer, p1->interval_ktime,
HRTIMER_MODE_REL_SOFT);
A negative relative timeout expires immediately. The callback
unconditionally returns HRTIMER_RESTART, and hrtimer_forward() turns
the negative interval into hrtimer_resolution:
if (interval < hrtimer_resolution)
interval = hrtimer_resolution;
So the SOFT timer re-fires at the maximum rate forever, holding
sk_receive_queue.lock each pass. One CPU spins in softirq until the
socket is closed. Repeat with more rings and the machine is gone.
The overflow itself is ancient - it was introduced together with
TPACKET_V3 in f6fb8f100b80 ("af-packet: TPACKET_V3 flexible buffer
implementation."). Its effect prior to f7460d2989fa ("net:
af_packet: Use hrtimer to do the retire operation", v6.18) was not
as clear-cut, though: the return value was stored into an unsigned
short retire_blk_tov, so a negative result was truncated, and a
0-jiffy delay loop could be programmed as well. Neither is nearly
as detrimental as the immediate maximum-rate spin the hrtimer
conversion turned it into.
(Unrelated to CVE-2019-20812 - that one was the ethtool failure path
returning 0, which now returns DEFAULT_PRB_RETIRE_TOV.)
Reproducer, needs CAP_NET_RAW (a --network host container has it by
default) and a 1 Gbps NIC (QEMU e1000 works):
int fd = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
bind(fd, ...);
int v = TPACKET_V3;
setsockopt(fd, SOL_PACKET, PACKET_VERSION, &v, sizeof(v));
struct tpacket_req3 req = {
.tp_block_size = 0x10000000,
.tp_block_nr = 1,
.tp_frame_size = 2048,
.tp_frame_nr = 0x10000000 / 2048,
.tp_retire_blk_tov = 0,
};
setsockopt(fd, SOL_PACKET, PACKET_RX_RING, &req, sizeof(req));
Compute in 64 bits instead. The operands are already bounded by the
existing validation, so nothing else changes. If you'd prefer a
different fix, just say so and I'll respin.
来源: CVE Program / CVE List V5
CVSS Information
N/A
来源: CVE Program / CVE List V5
Vulnerability Type
N/A
来源: CVE Program / CVE List V5
受影响产品
二、漏洞 CVE-2026-98547 的公开POC
| # | POC 描述 | 源链接 | 神龙链接 |
|---|
AI 生成 POC
高级
未找到公开 POC。
登录以生成 AI POC三、漏洞 CVE-2026-98547 的情报信息
请登录查看更多情报信息。
CVE-2026-98547 补丁与修复 (7)
同批安全公告 · Linux · 2026-10-18 · 共 436 条
| CVE-2026-98583 | NFC nfcmrvl 驱动命令长度校验越界漏洞 | |
| CVE-2026-98570 | Linux IPv6 子网路由表项处理信息泄露漏洞 | |
| CVE-2026-98571 | stmmac 驱动 skb 构建失败后内存泄漏漏洞 | |
| CVE-2026-98572 | bpf MIPS32 JEQ/JNE 跳转指令逻辑漏洞 | |
| CVE-2026-98573 | Linux 内核 IPv6 校验和计算整数下溢漏洞 | |
| CVE-2026-98574 | bcmgenet 网络驱动 NAPI 停止前禁用队列漏洞 | |
| CVE-2026-98575 | pn533 NFC 驱动越界读取漏洞 | |
| CVE-2026-98576 | Linux NFC LLCP 服务名日志越界读漏洞 | |
| CVE-2026-98577 | NFC LLCP 模块 WKS SAP 劫持漏洞 | |
| CVE-2026-98578 | Linux st21nfca ISO15693 库存长度验证漏洞 | |
| CVE-2026-98579 | NFC LLCP SDreq TLV 列表泄露漏洞 | |
| CVE-2026-98580 | Linux NFC LLCP 接受队列生命周期竞态条件漏洞 | |
| CVE-2026-98581 | NFC LLCP nfc_llcp_recv_dm 列表损坏/引用计数不同步 | |
| CVE-2026-98582 | ST21NFCA NFC 驱动接收帧大小验证漏洞 | |
| CVE-2026-98594 | tg3 驱动 PHYLIB 资源清理漏洞 | |
| CVE-2026-98591 | bpf skb 动态指针越界漏洞 | |
| CVE-2026-98592 | Spacemit 网络驱动传输描述符处理漏洞 | |
| CVE-2026-98593 | Linux s390 调试功能空指针解引用漏洞 | |
| CVE-2026-98590 | bpf 上下文代码生成逻辑修复 | |
| CVE-2026-98595 | Linux 内核 UDP 4 元组哈希表移除漏洞 |
显示前 20 条，共 436 条。 查看全部 → →
IV. Related Vulnerabilities
V. Comments for CVE-2026-98547
暂无评论