In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix DEVMAP_HASH overflow check on 32-bit arches
The devmap code allocates a number hash buckets equal to the next power
of two of the max_entries value provided when creating the map. When
rounding up to the next power of two, the 32-bit variable storing the
number of buckets can overflow, and the code checks for overflow by
checking if the truncated 32-bit value is equal to 0. However, on 32-bit
arches the rounding up itself can overflow mid-way through, because it
ends up doing a left-shift of 32 bits on an unsigned long value. If the
size of an unsigned long is four bytes, this is undefined behaviour, so
there is no guarantee that we'll end up with a nice and tidy 0-value at
the end.
Syzbot managed to turn this into a crash on arm32 by creating a
DEVMAP_HASH with max_entries > 0x80000000 and then trying to update it.
Fix this by moving the overflow check to before the rounding up
operation.
CVSS
7.8 HIGH (v3.1, CNA)CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
6f9d451ab1a33728adb72d7ff66a7b374d665176 builds before 1f5e352b9088211fa5eb4e1639cd365f4f7d2f65; 6f9d451ab1a33728adb72d7ff66a7b374d665176 builds before 4b81a9f92b3676cb74b907a7a209b3d15bd9a7f9; from 6f9d451ab1a33728adb72d7ff66a7b374d665176 before c826502bed93970f2fd488918a7b8d5f1d30e2e3; from 6f9d451ab1a33728adb72d7ff66a7b374d665176 before edf7990baa48de5097daa9ac02e06cb4c798a737; from 6f9d451ab1a33728adb72d7ff66a7b374d665176 before 250051acc21f9d4c5c595e4fcb55986ea08c4691; from 6f9d451ab1a33728adb72d7ff66a7b374d665176 before 22079b3a423382335f47d9ed32114e6c9fe88d7c; from 6f9d451ab1a33728adb72d7ff66a7b374d665176 before e89386f62ce9a9ab9a94835a9890883c23d9d52c; from 6f9d451ab1a33728adb72d7ff66a7b374d665176 before 281d464a34f540de166cee74b723e97ac2515ec3
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.
Printed from infosecsignals.com. Every record links back to the agency that published it.
Your cookie choices
We use essential cookies to run this site, and, only with your consent, an advertising cookie from Google to measure whether our ads lead to sign-ups and subscriptions. See our for details.