In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
af_packet: fix integer overflow in prb_calc_retire_blk_tmo()<\/p>\n
prb_calc_retire_blk_tmo() computes in 32-bit int arithmetic:<\/p>\n
mbits = (blk_size_in_bytes * 8) \/ (1024 * 1024);<\/p>\n
If I’m reading the validation right, tp_block_size is user
\ncontrolled and packet_set_ring() only rejects values that are = 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.<\/p>\n
What makes it fatal is what happens next in init_prb_bdqc():<\/p>\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);<\/p>\n
A negative relative timeout expires immediately. The callback
\nunconditionally returns HRTIMER_RESTART, and hrtimer_forward() turns
\nthe negative interval into hrtimer_resolution:<\/p>\n
if (interval < hrtimer_resolution)
\n interval = hrtimer_resolution;<\/p>\n
So 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.<\/p>\n
The 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.<\/p>\n
(Unrelated to CVE-2019-20812 – that one was the ethtool failure path
\nreturning 0, which now returns DEFAULT_PRB_RETIRE_TOV.)<\/p>\n
Reproducer, needs CAP_NET_RAW (a –network host container has it by
\ndefault) and a 1 Gbps NIC (QEMU e1000 works):<\/p>\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));<\/p>\n
Compute 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.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
af_packet: fix integer overflow in prb_calc_retire_blk_tmo()<\/p>\n
prb_calc_retire_blk_tmo() computes in 32-bit int arithmetic:<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-41019","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/41019","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=41019"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=41019"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=41019"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}