Описание
In the Linux kernel, the following vulnerability has been resolved:
debugobjects: Plug race against a concurrent OOM disable
syzbot reported a puzzling splat:
WARNING: kernel/time/hrtimer.c:443 at stub_timer+0xa/0x20
stub_timer() is installed as timer callback function in
hrtimer_fixup_assert_init(), which is invoked when
debug_object_assert_init() can't find a shadow object. In that case debug
objects emits a warning about it before invoking the fixup.
Though the provided console log lacks this warning and instead has the
following a few seconds before the splat:
ODEBUG: Out of memory. ODEBUG disabled
So the object was looked up in debug_object_assert_init() and the lookup
failed due a concurrent out of memory situation which disabled debug
objects and freed the shadow objects:
debug_object_assert_init()
if (!debug_objects_enabled)
return; obj = alloc();
if (!obj) {
// Out of memory
debug_objects_enabled = false;
free_objects();
obj = lookup_or_alloc();
// The lookup failed because the other side
// removed the objects, so this returns
// an error code as the object in question
// is not statically initialized
if (!IS_ERR_OR_NULL(obj))
return;
if (!obj) {
debug_oom();
return;
}
print(...)
if (!debug_objects_enabled)
return;
fixup(...)
The debug object splat is skipped because debug_objects_enabled is false,
but the fixup callback is invoked unconditionally, which makes the timer
disfunctional.
This is only a problem in debug_object_assert_init() and
debug_object_activate() as both have to handle statically initialized
objects and therefore must handle the error pointer return case
gracefully. All other places only handle the found/not found case and the
NULL pointer return is a signal for OOM. Otherwise they get a valid shadow
object.
Plug the hole by checking whether debug objects are still enabled before
invoking the print and fixup function in those two places.
A flaw was found in the debugobjects component of the Linux kernel. A race condition can occur when an out-of-memory (OOM) situation happens concurrently with certain debug object operations. This can lead to a dysfunctional timer and a kernel warning, potentially causing system instability or a denial of service (DoS).
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Red Hat Enterprise Linux 10 | kernel | Fix deferred | ||
| Red Hat Enterprise Linux 6 | kernel | Out of support scope | ||
| Red Hat Enterprise Linux 7 | kernel | Fix deferred | ||
| Red Hat Enterprise Linux 7 | kernel-rt | Fix deferred | ||
| Red Hat Enterprise Linux 8 | kernel | Fix deferred | ||
| Red Hat Enterprise Linux 8 | kernel-rt | Fix deferred | ||
| Red Hat Enterprise Linux 9 | kernel | Fix deferred | ||
| Red Hat Enterprise Linux 9 | kernel-rt | Fix deferred |
Показывать по
Дополнительная информация
Статус:
EPSS
5.5 Medium
CVSS3
Связанные уязвимости
In the Linux kernel, the following vulnerability has been resolved: debugobjects: Plug race against a concurrent OOM disable syzbot reported a puzzling splat: WARNING: kernel/time/hrtimer.c:443 at stub_timer+0xa/0x20 stub_timer() is installed as timer callback function in hrtimer_fixup_assert_init(), which is invoked when debug_object_assert_init() can't find a shadow object. In that case debug objects emits a warning about it before invoking the fixup. Though the provided console log lacks this warning and instead has the following a few seconds before the splat: ODEBUG: Out of memory. ODEBUG disabled So the object was looked up in debug_object_assert_init() and the lookup failed due a concurrent out of memory situation which disabled debug objects and freed the shadow objects: debug_object_assert_init() if (!debug_objects_enabled) return; obj = alloc(); if (!obj) { // Out of memory debug_objects_enabled = false; free_objects(); obj = lookup_or_alloc(); // T...
In the Linux kernel, the following vulnerability has been resolved: debugobjects: Plug race against a concurrent OOM disable syzbot reported a puzzling splat: WARNING: kernel/time/hrtimer.c:443 at stub_timer+0xa/0x20 stub_timer() is installed as timer callback function in hrtimer_fixup_assert_init(), which is invoked when debug_object_assert_init() can't find a shadow object. In that case debug objects emits a warning about it before invoking the fixup. Though the provided console log lacks this warning and instead has the following a few seconds before the splat: ODEBUG: Out of memory. ODEBUG disabled So the object was looked up in debug_object_assert_init() and the lookup failed due a concurrent out of memory situation which disabled debug objects and freed the shadow objects: debug_object_assert_init() if (!debug_objects_enabled) return; obj = alloc(); if (!obj) { // Out of memory
In the Linux kernel, the following vulnerability has been resolved: d ...
In the Linux kernel, the following vulnerability has been resolved: debugobjects: Plug race against a concurrent OOM disable syzbot reported a puzzling splat: WARNING: kernel/time/hrtimer.c:443 at stub_timer+0xa/0x20 stub_timer() is installed as timer callback function in hrtimer_fixup_assert_init(), which is invoked when debug_object_assert_init() can't find a shadow object. In that case debug objects emits a warning about it before invoking the fixup. Though the provided console log lacks this warning and instead has the following a few seconds before the splat: ODEBUG: Out of memory. ODEBUG disabled So the object was looked up in debug_object_assert_init() and the lookup failed due a concurrent out of memory situation which disabled debug objects and freed the shadow objects: debug_object_assert_init() if (!debug_objects_enabled) return; obj = alloc(); if (!obj) { // Out of memory ...
EPSS
5.5 Medium
CVSS3