In the Linux kernel, the following vulnerability has been resolved:
mm/slub: actually fix freelist pointer vs redzoning
It turns out that SLUB redzoning ("slubdebug=Z") checks from s->objectsize rather than from s->inuse (which is normally bumped to make room for the freelist pointer), so a cache created with an object size less than 24 would have the freelist pointer written beyond s->objectsize, causing the redzone to be corrupted by the freelist pointer. This was very visible with "slubdebug=ZF":
BUG test (Tainted: G B ): Right Redzone overwritten
INFO: 0xffff957ead1c05de-0xffff957ead1c05df @offset=1502. First byte 0x1a instead of 0xbb INFO: Slab 0xffffef3950b47000 objects=170 used=170 fp=0x0000000000000000 flags=0x8000000000000200 INFO: Object 0xffff957ead1c05d8 @offset=1496 fp=0xffff957ead1c0620
Redzone (ptrval): bb bb bb bb bb bb bb bb ........ Object (ptrval): 00 00 00 00 00 f6 f4 a5 ........ Redzone (ptrval): 40 1d e8 1a aa @.... Padding (ptrval): 00 00 00 00 00 00 00 00 ........
Adjust the offset to stay within s->object_size.
(Note that no caches of in this size range are known to exist in the kernel currently.)
"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2021-47221.json"
[
{
"events": [
{
"introduced": "5.7"
},
{
"fixed": "5.10.46"
}
]
},
{
"events": [
{
"introduced": "5.11"
},
{
"fixed": "5.12.13"
}
]
},
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "5.13-rc1"
}
]
},
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "5.13-rc2"
}
]
},
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "5.13-rc3"
}
]
},
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "5.13-rc4"
}
]
},
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "5.13-rc5"
}
]
},
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "5.13-rc6"
}
]
}
]