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

exploitDog

fstec логотип

BDU:2024-10014

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

Описание

Уязвимость компонента sfc ядра операционной системы Linux связана с разыменованием указателя NULL в функции efx_probe_interrupts(). Эксплуатация уязвимости может позволить нарушителю вызвать отказ в обслуживании

Вендор

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

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

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

Версия ПО

6 (Red Hat Enterprise Linux)
7 (Red Hat Enterprise Linux)
8 (Red Hat Enterprise Linux)
20.04 LTS (Ubuntu)
11 (Debian GNU/Linux)
12 (Debian GNU/Linux)
7.3 (РЕД ОС)
22.04 LTS (Ubuntu)
5.17.15 (Linux)
от 5.10.122 до 5.10.145 включительно (Linux)
от 5.15.47 до 5.15.70 включительно (Linux)
от 5.18.4 до 5.19.11 включительно (Linux)

Тип ПО

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

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

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

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

Средний уровень опасности (базовая оценка 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/2024042857-CVE-2022-48647-4a4d@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-48647
Для Ubuntu:
https://ubuntu.com/security/CVE-2022-48647
Для программных продуктов Red Hat Inc.:
https://access.redhat.com/security/cve/CVE-2022-48647

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

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

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

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

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

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

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

EPSS

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

5.5 Medium

CVSS3

4.6 Medium

CVSS2

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

ubuntu
больше 1 года назад

In the Linux kernel, the following vulnerability has been resolved: sfc: fix TX channel offset when using legacy interrupts In legacy interrupt mode the tx_channel_offset was hardcoded to 1, but that's not correct if efx_sepparate_tx_channels is false. In that case, the offset is 0 because the tx queues are in the single existing channel at index 0, together with the rx queue. Without this fix, as soon as you try to send any traffic, it tries to get the tx queues from an uninitialized channel getting these errors: WARNING: CPU: 1 PID: 0 at drivers/net/ethernet/sfc/tx.c:540 efx_hard_start_xmit+0x12e/0x170 [sfc] [...] RIP: 0010:efx_hard_start_xmit+0x12e/0x170 [sfc] [...] Call Trace: <IRQ> dev_hard_start_xmit+0xd7/0x230 sch_direct_xmit+0x9f/0x360 __dev_queue_xmit+0x890/0xa40 [...] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [...] RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc] [...] Call Trace: <IRQ> dev_hard_start_xmit+0xd7/0x230 sch_direct_xmit+0x9f/0x36...

CVSS3: 5.5
redhat
больше 1 года назад

In the Linux kernel, the following vulnerability has been resolved: sfc: fix TX channel offset when using legacy interrupts In legacy interrupt mode the tx_channel_offset was hardcoded to 1, but that's not correct if efx_sepparate_tx_channels is false. In that case, the offset is 0 because the tx queues are in the single existing channel at index 0, together with the rx queue. Without this fix, as soon as you try to send any traffic, it tries to get the tx queues from an uninitialized channel getting these errors: WARNING: CPU: 1 PID: 0 at drivers/net/ethernet/sfc/tx.c:540 efx_hard_start_xmit+0x12e/0x170 [sfc] [...] RIP: 0010:efx_hard_start_xmit+0x12e/0x170 [sfc] [...] Call Trace: <IRQ> dev_hard_start_xmit+0xd7/0x230 sch_direct_xmit+0x9f/0x360 __dev_queue_xmit+0x890/0xa40 [...] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [...] RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc] [...] Call Trace: <IRQ> dev_hard_start_xmit+0xd7/0x230 sch_direct_xmit+0x9f/0x36...

nvd
больше 1 года назад

In the Linux kernel, the following vulnerability has been resolved: sfc: fix TX channel offset when using legacy interrupts In legacy interrupt mode the tx_channel_offset was hardcoded to 1, but that's not correct if efx_sepparate_tx_channels is false. In that case, the offset is 0 because the tx queues are in the single existing channel at index 0, together with the rx queue. Without this fix, as soon as you try to send any traffic, it tries to get the tx queues from an uninitialized channel getting these errors: WARNING: CPU: 1 PID: 0 at drivers/net/ethernet/sfc/tx.c:540 efx_hard_start_xmit+0x12e/0x170 [sfc] [...] RIP: 0010:efx_hard_start_xmit+0x12e/0x170 [sfc] [...] Call Trace: <IRQ> dev_hard_start_xmit+0xd7/0x230 sch_direct_xmit+0x9f/0x360 __dev_queue_xmit+0x890/0xa40 [...] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [...] RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc] [...] Call Trace: <IRQ> dev_hard_start_x

debian
больше 1 года назад

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

github
больше 1 года назад

In the Linux kernel, the following vulnerability has been resolved: sfc: fix TX channel offset when using legacy interrupts In legacy interrupt mode the tx_channel_offset was hardcoded to 1, but that's not correct if efx_sepparate_tx_channels is false. In that case, the offset is 0 because the tx queues are in the single existing channel at index 0, together with the rx queue. Without this fix, as soon as you try to send any traffic, it tries to get the tx queues from an uninitialized channel getting these errors: WARNING: CPU: 1 PID: 0 at drivers/net/ethernet/sfc/tx.c:540 efx_hard_start_xmit+0x12e/0x170 [sfc] [...] RIP: 0010:efx_hard_start_xmit+0x12e/0x170 [sfc] [...] Call Trace: <IRQ> dev_hard_start_xmit+0xd7/0x230 sch_direct_xmit+0x9f/0x360 __dev_queue_xmit+0x890/0xa40 [...] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [...] RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc] [...] Call Trace: <IRQ> dev_hard_star...

EPSS

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

5.5 Medium

CVSS3

4.6 Medium

CVSS2