Логотип exploitDog
Консоль
Логотип exploitDog

exploitDog

fstec логотип

BDU:2024-10016

Опубликовано: 20 сент. 2022
Источник: fstec
CVSS3: 5.5
CVSS2: 4.6
EPSS Низкий

Описание

Уязвимость компонентов net/sched ядра операционной системы Linux вызвана ошибками синхронизации при использовании общего ресурса. Эксплуатация уязвимости может позволить нарушителю вызвать отказ в обслуживании

Вендор

Canonical Ltd.
Сообщество свободного программного обеспечения
ООО «Ред Софт»
Red Hat Inc.

Наименование ПО

Ubuntu
Debian GNU/Linux
РЕД ОС
Red Hat Enterprise Linux
Linux

Версия ПО

18.04 LTS (Ubuntu)
20.04 LTS (Ubuntu)
11 (Debian GNU/Linux)
12 (Debian GNU/Linux)
7.3 (РЕД ОС)
22.04 LTS (Ubuntu)
9 (Red Hat Enterprise Linux)
от 5.5 до 5.10.145 включительно (Linux)
от 5.11 до 5.15.70 включительно (Linux)
от 5.16 до 5.19.11 включительно (Linux)
18.04 ESM (Ubuntu)
от 5.4 до 5.4.214 включительно (Linux)

Тип ПО

Операционная система

Операционные системы и аппаратные платформы

Canonical Ltd. Ubuntu 18.04 LTS
Canonical Ltd. Ubuntu 20.04 LTS
Сообщество свободного программного обеспечения Debian GNU/Linux 11
Сообщество свободного программного обеспечения Debian GNU/Linux 12
ООО «Ред Софт» РЕД ОС 7.3
Canonical Ltd. Ubuntu 22.04 LTS
Red Hat Inc. Red Hat Enterprise Linux 9
Сообщество свободного программного обеспечения Linux 6.0 rc1
Canonical Ltd. Ubuntu 18.04 ESM
Сообщество свободного программного обеспечения Linux от 5.15 до 5.15.71
Сообщество свободного программного обеспечения Linux от 5.10 до 5.10.146
Сообщество свободного программного обеспечения Linux от 5.19 до 5.19.12
Сообщество свободного программного обеспечения Linux от 5.4 до 5.4.215

Уровень опасности уязвимости

Средний уровень опасности (базовая оценка CVSS 2.0 составляет 4,6)
Средний уровень опасности (базовая оценка CVSS 3.0 составляет 5,5)
Нет опасности уровень опасности (оценка CVSS 4.0 составляет 0)

Возможные меры по устранению уязвимости

В условиях отсутствия обновлений безопасности от производителя рекомендуется придерживаться "Рекомендаций по безопасной настройке операционных систем LINUX", изложенных в методическом документе ФСТЭК России, утверждённом 25 декабря 2022 года.
Использование рекомендаций:
Для Linux:
https://lore.kernel.org/linux-cve-announce/2024042856-CVE-2022-48644-757e@gregkh/T/#u
Для РедОС:
http://repo.red-soft.ru/redos/7.3c/x86_64/updates/
Для Debian GNU/Linux:
https://security-tracker.debian.org/tracker/CVE-2022-48644
Для Ubuntu:
https://ubuntu.com/security/CVE-2022-48644
Для программных продуктов Red Hat Inc.:
https://access.redhat.com/security/cve/CVE-2022-48644

Статус уязвимости

Подтверждена производителем

Наличие эксплойта

Данные уточняются

Информация об устранении

Уязвимость устранена

Идентификаторы других систем описаний уязвимостей

EPSS

Процентиль: 4%
0.00021
Низкий

5.5 Medium

CVSS3

4.6 Medium

CVSS2

Связанные уязвимости

ubuntu
около 1 года назад

In the Linux kernel, the following vulnerability has been resolved: net/sched: taprio: avoid disabling offload when it was never enabled In an incredibly strange API design decision, qdisc->destroy() gets called even if qdisc->init() never succeeded, not exclusively since commit 87b60cfacf9f ("net_sched: fix error recovery at qdisc creation"), but apparently also earlier (in the case of qdisc_create_dflt()). The taprio qdisc does not fully acknowledge this when it attempts full offload, because it starts off with q->flags = TAPRIO_FLAGS_INVALID in taprio_init(), then it replaces q->flags with TCA_TAPRIO_ATTR_FLAGS parsed from netlink (in taprio_change(), tail called from taprio_init()). But in taprio_destroy(), we call taprio_disable_offload(), and this determines what to do based on FULL_OFFLOAD_IS_ENABLED(q->flags). But looking at the implementation of FULL_OFFLOAD_IS_ENABLED() (a bitwise check of bit 1 in q->flags), it is invalid to call this macro on q->flags when it contains TA...

CVSS3: 6.1
redhat
около 1 года назад

In the Linux kernel, the following vulnerability has been resolved: net/sched: taprio: avoid disabling offload when it was never enabled In an incredibly strange API design decision, qdisc->destroy() gets called even if qdisc->init() never succeeded, not exclusively since commit 87b60cfacf9f ("net_sched: fix error recovery at qdisc creation"), but apparently also earlier (in the case of qdisc_create_dflt()). The taprio qdisc does not fully acknowledge this when it attempts full offload, because it starts off with q->flags = TAPRIO_FLAGS_INVALID in taprio_init(), then it replaces q->flags with TCA_TAPRIO_ATTR_FLAGS parsed from netlink (in taprio_change(), tail called from taprio_init()). But in taprio_destroy(), we call taprio_disable_offload(), and this determines what to do based on FULL_OFFLOAD_IS_ENABLED(q->flags). But looking at the implementation of FULL_OFFLOAD_IS_ENABLED() (a bitwise check of bit 1 in q->flags), it is invalid to call this macro on q->flags when it contains TA...

nvd
около 1 года назад

In the Linux kernel, the following vulnerability has been resolved: net/sched: taprio: avoid disabling offload when it was never enabled In an incredibly strange API design decision, qdisc->destroy() gets called even if qdisc->init() never succeeded, not exclusively since commit 87b60cfacf9f ("net_sched: fix error recovery at qdisc creation"), but apparently also earlier (in the case of qdisc_create_dflt()). The taprio qdisc does not fully acknowledge this when it attempts full offload, because it starts off with q->flags = TAPRIO_FLAGS_INVALID in taprio_init(), then it replaces q->flags with TCA_TAPRIO_ATTR_FLAGS parsed from netlink (in taprio_change(), tail called from taprio_init()). But in taprio_destroy(), we call taprio_disable_offload(), and this determines what to do based on FULL_OFFLOAD_IS_ENABLED(q->flags). But looking at the implementation of FULL_OFFLOAD_IS_ENABLED() (a bitwise check of bit 1 in q->flags), it is invalid to call this macro on q->flags when it contains

debian
около 1 года назад

In the Linux kernel, the following vulnerability has been resolved: n ...

github
около 1 года назад

In the Linux kernel, the following vulnerability has been resolved: net/sched: taprio: avoid disabling offload when it was never enabled In an incredibly strange API design decision, qdisc->destroy() gets called even if qdisc->init() never succeeded, not exclusively since commit 87b60cfacf9f ("net_sched: fix error recovery at qdisc creation"), but apparently also earlier (in the case of qdisc_create_dflt()). The taprio qdisc does not fully acknowledge this when it attempts full offload, because it starts off with q->flags = TAPRIO_FLAGS_INVALID in taprio_init(), then it replaces q->flags with TCA_TAPRIO_ATTR_FLAGS parsed from netlink (in taprio_change(), tail called from taprio_init()). But in taprio_destroy(), we call taprio_disable_offload(), and this determines what to do based on FULL_OFFLOAD_IS_ENABLED(q->flags). But looking at the implementation of FULL_OFFLOAD_IS_ENABLED() (a bitwise check of bit 1 in q->flags), it is invalid to call this macro on q->flags when it contai...

EPSS

Процентиль: 4%
0.00021
Низкий

5.5 Medium

CVSS3

4.6 Medium

CVSS2