CVE-2022-50498
published 2025-10-04CVE-2022-50498: In the Linux kernel, the following vulnerability has been resolved: eth: alx: take rtnl_lock on resume Zbynek reports that alx trips an rtnl assertion on…
PriorityP420medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.14%
4.2th percentile
In the Linux kernel, the following vulnerability has been resolved:
eth: alx: take rtnl_lock on resume
Zbynek reports that alx trips an rtnl assertion on resume:
RTNL: assertion failed at net/core/dev.c (2891)
RIP: 0010:netif_set_real_num_tx_queues+0x1ac/0x1c0
Call Trace:
__alx_open+0x230/0x570 [alx]
alx_resume+0x54/0x80 [alx]
? pci_legacy_resume+0x80/0x80
dpm_run_callback+0x4a/0x150
device_resume+0x8b/0x190
async_resume+0x19/0x30
async_run_entry_fn+0x30/0x130
process_one_work+0x1e5/0x3b0
indeed the driver does not hold rtnl_lock during its internal close
and re-open functions during suspend/resume. Note that this is not
a huge bug as the driver implements its own locking, and does not
implement changing the number of queues, but we need to silence
the splat.
Affected
12 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.0.3-1 (bookworm) | linux 6.0.3-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 4a5fe57e775188be96359a1934501be45fe5f705 < 6f1991a940b90753b34570f093a21dba366e8cc0 | 6f1991a940b90753b34570f093a21dba366e8cc0 |
| linux | linux | >= 4a5fe57e775188be96359a1934501be45fe5f705 < a845a0c4bdece2c0073ecea2fca7c4d5f0550f78 | a845a0c4bdece2c0073ecea2fca7c4d5f0550f78 |
| linux | linux | >= 4a5fe57e775188be96359a1934501be45fe5f705 < c0323c0fd07804d5874699e93f935cda0d989c67 | c0323c0fd07804d5874699e93f935cda0d989c67 |
| linux | linux | >= 4a5fe57e775188be96359a1934501be45fe5f705 < 6ad1c94e1e7e374d88f0cfd77936dddb8339aaba | 6ad1c94e1e7e374d88f0cfd77936dddb8339aaba |
| linux | linux_kernel | >= 0 < 6.0.3-1 | 6.0.3-1 |
| linux | linux_kernel | >= 0 < 6.0.3-1 | 6.0.3-1 |
| linux | linux_kernel | >= 0 < 6.0.3-1 | 6.0.3-1 |
| linux | linux_kernel | >= 5.14 < 5.15.75 | 5.15.75 |
| linux | linux_kernel | >= 5.16 < 5.19.17 | 5.19.17 |
| linux | linux_kernel | >= 6.0 < 6.0.3 | 6.0.3 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: eth: alx: take rtnl_lock on resume
vendor_redhat·2025-10-04·CVSS 5.5
CVE-2022-50498 [MEDIUM] CWE-413 kernel: eth: alx: take rtnl_lock on resume
kernel: eth: alx: take rtnl_lock on resume
In the Linux kernel, the following vulnerability has been resolved:
eth: alx: take rtnl_lock on resume
Zbynek reports that alx trips an rtnl assertion on resume:
RTNL: assertion failed at net/core/dev.c (2891)
RIP: 0010:netif_set_real_num_tx_queues+0x1ac/0x1c0
Call Trace:
__alx_open+0x230/0x570 [alx]
alx_resume+0x54/0x80 [alx]
? pci_legacy_resume+0x80/0x80
dpm_run_callback+0x4a/0x150
device_resume+0x8b/0x190
async_resume+0x19/0x30
async_run_entry_fn+0x30/0x130
process_one_work+0x1e5/0x3b0
indeed the driver does not hold rtnl_lock during its internal close
and re-open functions during suspend/resume. Note that this is not
a huge bug as the driver implements its own locking, and does not
implement changing the number of queues, but we need to sile
Debian
CVE-2022-50498: linux - In the Linux kernel, the following vulnerability has been resolved: eth: alx: t...
vendor_debian·2022·CVSS 5.5
CVE-2022-50498 [MEDIUM] CVE-2022-50498: linux - In the Linux kernel, the following vulnerability has been resolved: eth: alx: t...
In the Linux kernel, the following vulnerability has been resolved: eth: alx: take rtnl_lock on resume Zbynek reports that alx trips an rtnl assertion on resume: RTNL: assertion failed at net/core/dev.c (2891) RIP: 0010:netif_set_real_num_tx_queues+0x1ac/0x1c0 Call Trace: __alx_open+0x230/0x570 [alx] alx_resume+0x54/0x80 [alx] ? pci_legacy_resume+0x80/0x80 dpm_run_callback+0x4a/0x150 device_resume+0x8b/0x190 async_resume+0x19/0x30 async_run_entry_fn+0x30/0x130 process_one_work+0x1e5/0x3b0 indeed the driver does not hold rtnl_lock during its internal close and re-open functions during suspend/resume. Note that this is not a huge bug as the driver implements its own locking, and does not implement changing the number of queues, but we need to silence the splat.
Scope: local
bookworm: resolve
OSV
CVE-2022-50498: In the Linux kernel, the following vulnerability has been resolved: eth: alx: take rtnl_lock on resume Zbynek reports that alx trips an rtnl assertion
osv·2025-10-04·CVSS 5.5
CVE-2022-50498 [MEDIUM] CVE-2022-50498: In the Linux kernel, the following vulnerability has been resolved: eth: alx: take rtnl_lock on resume Zbynek reports that alx trips an rtnl assertion
In the Linux kernel, the following vulnerability has been resolved: eth: alx: take rtnl_lock on resume Zbynek reports that alx trips an rtnl assertion on resume: RTNL: assertion failed at net/core/dev.c (2891) RIP: 0010:netif_set_real_num_tx_queues+0x1ac/0x1c0 Call Trace: __alx_open+0x230/0x570 [alx] alx_resume+0x54/0x80 [alx] ? pci_legacy_resume+0x80/0x80 dpm_run_callback+0x4a/0x150 device_resume+0x8b/0x190 async_resume+0x19/0x30 async_run_entry_fn+0x30/0x130 process_one_work+0x1e5/0x3b0 indeed the driver does not hold rtnl_lock during its internal close and re-open functions during suspend/resume. Note that this is not a huge bug as the driver implements its own locking, and does not implement changing the number of queues, but we need to silence the splat.
GHSA
GHSA-5v2q-57gf-xr2x: In the Linux kernel, the following vulnerability has been resolved:
eth: alx: take rtnl_lock on resume
Zbynek reports that alx trips an rtnl asserti
ghsa_unreviewed·2025-10-04
CVE-2022-50498 [MEDIUM] GHSA-5v2q-57gf-xr2x: In the Linux kernel, the following vulnerability has been resolved:
eth: alx: take rtnl_lock on resume
Zbynek reports that alx trips an rtnl asserti
In the Linux kernel, the following vulnerability has been resolved:
eth: alx: take rtnl_lock on resume
Zbynek reports that alx trips an rtnl assertion on resume:
RTNL: assertion failed at net/core/dev.c (2891)
RIP: 0010:netif_set_real_num_tx_queues+0x1ac/0x1c0
Call Trace:
__alx_open+0x230/0x570 [alx]
alx_resume+0x54/0x80 [alx]
? pci_legacy_resume+0x80/0x80
dpm_run_callback+0x4a/0x150
device_resume+0x8b/0x190
async_resume+0x19/0x30
async_run_entry_fn+0x30/0x130
process_one_work+0x1e5/0x3b0
indeed the driver does not hold rtnl_lock during its internal close
and re-open functions during suspend/resume. Note that this is not
a huge bug as the driver implements its own locking, and does not
implement changing the number of queues, but we need to silence
the splat.
No detection rules found.
No public exploits indexed.
2025-10-04
Published