CVE-2026-98547
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:
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.
Read full descriptionShow less
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():
A negative relative timeout expires immediately. The callback unconditionally returns HRTIMER_RESTART, and hrtimer_forward() turns the negative interval into 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):
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.
Technical details traces, logs and code from the original report
mbits = (blk_size_in_bytes * 8) / (1024 * 1024);
p1->interval_ktime = ms_to_ktime(prb_calc_retire_blk_tmo(...));
hrtimer_start(&p1->retire_blk_timer, p1->interval_ktime,
HRTIMER_MODE_REL_SOFT);
if (interval < hrtimer_resolution)
interval = hrtimer_resolution;
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));CVSS
NVD hasn't assigned a CVSS score to this CVE (common since the April 2026 policy change).
Exploitation probability (EPSS)
- Probability of exploitation in the next 30 days
- 0.21 %
- Percentile among all scored CVEs
- 11
- Score date
- 10/20/2026
EPSS (Exploit Prediction Scoring System, FIRST) estimates how likely a vulnerability is to be exploited in the wild within 30 days. It complements CVSS (impact) and CISA KEV (confirmed exploitation).
Affected technologies (1)
⚠ AI-inferred from the description — NVD hasn't analyzed this CVE yet, these aren't verified CPEs.
References
Show 8 references
- https://git.kernel.org/stable/c/02afd75649a4e001031ed82153a5c39312ec0737
- https://git.kernel.org/stable/c/218a944b9e035d4b47d59c69af6ca13319da15fb
- https://git.kernel.org/stable/c/297acc571d5813db76b147c745b91031d5f9c960
- https://git.kernel.org/stable/c/56d82862a0a243ac14ba11b6d7b57ddc2d064b95
- https://git.kernel.org/stable/c/6279211e7d2456ecd195d236c9ee5e5c6fa5a17a
- https://git.kernel.org/stable/c/b2bcc6a254d6f27823a56787668ae4ee8cdb6e71
- https://git.kernel.org/stable/c/be1aacff399d519cc48d6b34354a54dd79041140
- https://git.kernel.org/stable/c/eb5b3838b9200dac04bfe33483db0ee8287456fb
Raw JSON (NVD)
Show
{
"id": "CVE-2026-98547",
"cveTags": [],
"metrics": {},
"affected": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"affectedData": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "f6fb8f100b807378fda19e83e5ac6828b638603a",
"lessThan": "02afd75649a4e001031ed82153a5c39312ec0737",
"versionType": "git"
},
{
"status": "affected",
"version": "f6fb8f100b807378fda19e83e5ac6828b638603a",
"lessThan": "eb5b3838b9200dac04bfe33483db0ee8287456fb",
"versionType": "git"
},
{
"status": "affected",
"version": "f6fb8f100b807378fda19e83e5ac6828b638603a",
"lessThan": "297acc571d5813db76b147c745b91031d5f9c960",
"versionType": "git"
},
{
"status": "affected",
"version": "f6fb8f100b807378fda19e83e5ac6828b638603a",
"lessThan": "be1aacff399d519cc48d6b34354a54dd79041140",
"versionType": "git"
},
{
"status": "affected",
"version": "f6fb8f100b807378fda19e83e5ac6828b638603a",
"lessThan": "b2bcc6a254d6f27823a56787668ae4ee8cdb6e71",
"versionType": "git"
},
{
"status": "affected",
"version": "f6fb8f100b807378fda19e83e5ac6828b638603a",
"lessThan": "6279211e7d2456ecd195d236c9ee5e5c6fa5a17a",
"versionType": "git"
},
{
"status": "affected",
"version": "f6fb8f100b807378fda19e83e5ac6828b638603a",
"lessThan": "218a944b9e035d4b47d59c69af6ca13319da15fb",
"versionType": "git"
},
{
"status": "affected",
"version": "f6fb8f100b807378fda19e83e5ac6828b638603a",
"lessThan": "56d82862a0a243ac14ba11b6d7b57ddc2d064b95",
"versionType": "git"
}
],
"programFiles": [
"net/packet/af_packet.c"
],
"defaultStatus": "unaffected"
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "3.2"
},
{
"status": "unaffected",
"version": "0",
"lessThan": "3.2",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "5.10.271",
"versionType": "semver",
"lessThanOrEqual": "5.10.*"
},
{
"status": "unaffected",
"version": "5.15.222",
"versionType": "semver",
"lessThanOrEqual": "5.15.*"
},
{
"status": "unaffected",
"version": "6.1.189",
"versionType": "semver",
"lessThanOrEqual": "6.1.*"
},
{
"status": "unaffected",
"version": "6.6.158",
"versionType": "semver",
"lessThanOrEqual": "6.6.*"
},
{
"status": "unaffected",
"version": "6.12.112",
"versionType": "semver",
"lessThanOrEqual": "6.12.*"
},
{
"status": "unaffected",
"version": "6.18.55",
"versionType": "semver",
"lessThanOrEqual": "6.18.*"
},
{
"status": "unaffected",
"version": "7.2.9",
"versionType": "semver",
"lessThanOrEqual": "7.2.*"
},
{
"status": "unaffected",
"version": "7.3",
"versionType": "original_commit_for_fix",
"lessThanOrEqual": "*"
}
],
"programFiles": [
"net/packet/af_packet.c"
],
"defaultStatus": "affected"
}
]
}
],
"published": "2026-10-18T16:17:06.630",
"references": [
{
"url": "https://git.kernel.org/stable/c/02afd75649a4e001031ed82153a5c39312ec0737",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/218a944b9e035d4b47d59c69af6ca13319da15fb",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/297acc571d5813db76b147c745b91031d5f9c960",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/56d82862a0a243ac14ba11b6d7b57ddc2d064b95",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/6279211e7d2456ecd195d236c9ee5e5c6fa5a17a",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/b2bcc6a254d6f27823a56787668ae4ee8cdb6e71",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/be1aacff399d519cc48d6b34354a54dd79041140",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/eb5b3838b9200dac04bfe33483db0ee8287456fb",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"vulnStatus": "Received",
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\naf_packet: fix integer overflow in prb_calc_retire_blk_tmo()\n\nprb_calc_retire_blk_tmo() computes in 32-bit int arithmetic:\n\n mbits = (blk_size_in_bytes * 8) / (1024 * 1024);\n\nIf I'm reading the validation right, tp_block_size is user\ncontrolled and packet_set_ring() only rejects values that are <= 0\nas int or not page aligned, so a 256MiB block goes right through\n(and alloc_one_pg_vec_page() even has a vzalloc fallback for it).\n0x10000000 * 8 wraps to INT_MIN, and on a NIC reporting 1 Gbps\n(div == 1) the function ends up returning -2047.\n\nThe condition is actually (8 * size) mod 2^32 >= 2^31 && div == 1,\nso the trigger set is [256,512), [768,1024), [1280,1536) and\n[1792,2048) MiB. Other sizes wrap to non-negative values and faster\nlinks divide the unsigned value back below 2^31, which is why this\ndoesn't blow up for everyone.\n\nWhat makes it fatal is what happens next in init_prb_bdqc():\n\n p1->interval_ktime = ms_to_ktime(prb_calc_retire_blk_tmo(...));\n hrtimer_start(&p1->retire_blk_timer, p1->interval_ktime,\n HRTIMER_MODE_REL_SOFT);\n\nA negative relative timeout expires immediately. The callback\nunconditionally returns HRTIMER_RESTART, and hrtimer_forward() turns\nthe negative interval into hrtimer_resolution:\n\n if (interval < hrtimer_resolution)\n interval = hrtimer_resolution;\n\nSo the SOFT timer re-fires at the maximum rate forever, holding\nsk_receive_queue.lock each pass. One CPU spins in softirq until the\nsocket is closed. Repeat with more rings and the machine is gone.\n\nThe overflow itself is ancient - it was introduced together with\nTPACKET_V3 in f6fb8f100b80 (\"af-packet: TPACKET_V3 flexible buffer\nimplementation.\"). Its effect prior to f7460d2989fa (\"net:\naf_packet: Use hrtimer to do the retire operation\", v6.18) was not\nas clear-cut, though: the return value was stored into an unsigned\nshort retire_blk_tov, so a negative result was truncated, and a\n0-jiffy delay loop could be programmed as well. Neither is nearly\nas detrimental as the immediate maximum-rate spin the hrtimer\nconversion turned it into.\n\n(Unrelated to CVE-2019-20812 - that one was the ethtool failure path\nreturning 0, which now returns DEFAULT_PRB_RETIRE_TOV.)\n\nReproducer, needs CAP_NET_RAW (a --network host container has it by\ndefault) and a 1 Gbps NIC (QEMU e1000 works):\n\n int fd = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL));\n bind(fd, ...);\n int v = TPACKET_V3;\n setsockopt(fd, SOL_PACKET, PACKET_VERSION, &v, sizeof(v));\n struct tpacket_req3 req = {\n .tp_block_size = 0x10000000,\n .tp_block_nr = 1,\n .tp_frame_size = 2048,\n .tp_frame_nr = 0x10000000 / 2048,\n .tp_retire_blk_tov = 0,\n };\n setsockopt(fd, SOL_PACKET, PACKET_RX_RING, &req, sizeof(req));\n\nCompute in 64 bits instead. The operands are already bounded by the\nexisting validation, so nothing else changes. If you'd prefer a\ndifferent fix, just say so and I'll respin."
}
],
"lastModified": "2026-10-19T10:19:10.717",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}