CVE-2022-50003
published 2025-06-18CVE-2022-50003: In the Linux kernel, the following vulnerability has been resolved: ice: xsk: prohibit usage of non-balanced queue id Fix the following scenario: 1. ethtool -L…
PriorityP421medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.16%
5.5th percentile
In the Linux kernel, the following vulnerability has been resolved:
ice: xsk: prohibit usage of non-balanced queue id
Fix the following scenario:
1. ethtool -L $IFACE rx 8 tx 96
2. xdpsock -q 10 -t -z
Above refers to a case where user would like to attach XSK socket in
txonly mode at a queue id that does not have a corresponding Rx queue.
At this moment ice's XSK logic is tightly bound to act on a "queue pair",
e.g. both Tx and Rx queues at a given queue id are disabled/enabled and
both of them will get XSK pool assigned, which is broken for the presented
queue configuration. This results in the splat included at the bottom,
which is basically an OOB access to Rx ring array.
To fix this, allow using the ids only in scope of "combined" queues
reported by ethtool. However, logic should be rewritten to allow such
configurations later on, which would end up as a complete rewrite of the
control path, so let us go with this temporary fix.
[420160.558008] BUG: kernel NULL pointer dereference, address: 0000000000000082
[420160.566359] #PF: supervisor read access in kernel mode
[420160.572657] #PF: error_code(0x0000) - not-present page
[420160.579002] PGD 0 P4D 0
[420160.582756] Oops: 0000 [#1] PREEMPT SMP NOPTI
[420160.588396] CPU: 10 PID: 21232 Comm: xdpsock Tainted: G OE 5.19.0-rc7+ #10
[420160.597893] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019
[420160.609894] RIP: 0010:ice_xsk_pool_setup+0x44/0x7d0 [ice]
[420160.616968] Code: f3 48 83 ec 40 48 8b 4f 20 48 8b 3f 65 48 8b 04 25 28 00 00 00 48 89 44 24 38 31 c0 48 8d 04 ed 00 00 00 00 48 01 c1 48 8b 11 b7 92 82 00 00 00 48 85 d2 0f 84 2d 75 00 00 48 8d 72 ff 48 85
[420160.639421] RSP: 0018:ffffc9002d2afd48 EFLAGS: 00010282
[420160.646650] RAX: 0000000000000050 RBX: ffff88811d8bdd00 RCX: ffff888112c14ff8
[420160.655893] RDX: 0000000000000000 RSI: ffff88811d8bdd00 RDI: ffff888109861000
[420160.665166] RBP: 000000000000000a R08: 000000000000000a R09: 00000000000
Affected
14 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.0.2-1 (bookworm) | linux 6.0.2-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 2d4238f5569722197612656163d824098208519c < 1bfdcde723d8ceb2d73291b0415767e7c1cc1d8a | 1bfdcde723d8ceb2d73291b0415767e7c1cc1d8a |
| linux | linux | >= 2d4238f5569722197612656163d824098208519c < fe76b3e674665ea4059337f8f66d20cdfb0168eb | fe76b3e674665ea4059337f8f66d20cdfb0168eb |
| linux | linux | >= 2d4238f5569722197612656163d824098208519c < 03a3f29fe5b1751ad9b5c892c894183e75a6e4c4 | 03a3f29fe5b1751ad9b5c892c894183e75a6e4c4 |
| linux | linux | >= 2d4238f5569722197612656163d824098208519c < 5a42f112d367bb4700a8a41f5c12724fde6bfbb9 | 5a42f112d367bb4700a8a41f5c12724fde6bfbb9 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 5.10.140-1 | 5.10.140-1 |
| linux | linux_kernel | >= 0 < 6.0.2-1 | 6.0.2-1 |
| linux | linux_kernel | >= 0 < 6.0.2-1 | 6.0.2-1 |
| linux | linux_kernel | >= 0 < 6.0.2-1 | 6.0.2-1 |
| linux | linux_kernel | >= 5.11 < 5.15.64 | 5.15.64 |
| linux | linux_kernel | >= 5.16 < 5.19.6 | 5.19.6 |
| linux | linux_kernel | >= 5.5 < 5.10.140 | 5.10.140 |
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.
OSV
CVE-2022-50003: In the Linux kernel, the following vulnerability has been resolved: ice: xsk: prohibit usage of non-balanced queue id Fix the following scenario: 1
osv·2025-06-18·CVSS 5.5
CVE-2022-50003 [MEDIUM] CVE-2022-50003: In the Linux kernel, the following vulnerability has been resolved: ice: xsk: prohibit usage of non-balanced queue id Fix the following scenario: 1
In the Linux kernel, the following vulnerability has been resolved: ice: xsk: prohibit usage of non-balanced queue id Fix the following scenario: 1. ethtool -L $IFACE rx 8 tx 96 2. xdpsock -q 10 -t -z Above refers to a case where user would like to attach XSK socket in txonly mode at a queue id that does not have a corresponding Rx queue. At this moment ice's XSK logic is tightly bound to act on a "queue pair", e.g. both Tx and Rx queues at a given queue id are disabled/enabled and both of them will get XSK pool assigned, which is broken for the presented queue configuration. This results in the splat included at the bottom, which is basically an OOB access to Rx ring array. To fix this, allow using the ids only in scope of "combined" queues reported by ethtool. However, logic should be re
GHSA
GHSA-fxwf-88xm-53qq: In the Linux kernel, the following vulnerability has been resolved:
ice: xsk: prohibit usage of non-balanced queue id
Fix the following scenario:
1
ghsa_unreviewed·2025-06-18
CVE-2022-50003 [MEDIUM] CWE-476 GHSA-fxwf-88xm-53qq: In the Linux kernel, the following vulnerability has been resolved:
ice: xsk: prohibit usage of non-balanced queue id
Fix the following scenario:
1
In the Linux kernel, the following vulnerability has been resolved:
ice: xsk: prohibit usage of non-balanced queue id
Fix the following scenario:
1. ethtool -L $IFACE rx 8 tx 96
2. xdpsock -q 10 -t -z
Above refers to a case where user would like to attach XSK socket in
txonly mode at a queue id that does not have a corresponding Rx queue.
At this moment ice's XSK logic is tightly bound to act on a "queue pair",
e.g. both Tx and Rx queues at a given queue id are disabled/enabled and
both of them will get XSK pool assigned, which is broken for the presented
queue configuration. This results in the splat included at the bottom,
which is basically an OOB access to Rx ring array.
To fix this, allow using the ids only in scope of "combined" queues
reported by ethtool. However, logic should b
Red Hat
kernel: ice: xsk: prohibit usage of non-balanced queue id
vendor_redhat·2025-06-18·CVSS 5.5
CVE-2022-50003 [MEDIUM] kernel: ice: xsk: prohibit usage of non-balanced queue id
kernel: ice: xsk: prohibit usage of non-balanced queue id
In the Linux kernel, the following vulnerability has been resolved:
ice: xsk: prohibit usage of non-balanced queue id
Fix the following scenario:
1. ethtool -L $IFACE rx 8 tx 96
2. xdpsock -q 10 -t -z
Above refers to a case where user would like to attach XSK socket in
txonly mode at a queue id that does not have a corresponding Rx queue.
At this moment ice's XSK logic is tightly bound to act on a "queue pair",
e.g. both Tx and Rx queues at a given queue id are disabled/enabled and
both of them will get XSK pool assigned, which is broken for the presented
queue configuration. This results in the splat included at the bottom,
which is basically an OOB access to Rx ring array.
To fix this, allow using the ids only in scope of "combin
Debian
CVE-2022-50003: linux - In the Linux kernel, the following vulnerability has been resolved: ice: xsk: p...
vendor_debian·2022·CVSS 5.5
CVE-2022-50003 [MEDIUM] CVE-2022-50003: linux - In the Linux kernel, the following vulnerability has been resolved: ice: xsk: p...
In the Linux kernel, the following vulnerability has been resolved: ice: xsk: prohibit usage of non-balanced queue id Fix the following scenario: 1. ethtool -L $IFACE rx 8 tx 96 2. xdpsock -q 10 -t -z Above refers to a case where user would like to attach XSK socket in txonly mode at a queue id that does not have a corresponding Rx queue. At this moment ice's XSK logic is tightly bound to act on a "queue pair", e.g. both Tx and Rx queues at a given queue id are disabled/enabled and both of them will get XSK pool assigned, which is broken for the presented queue configuration. This results in the splat included at the bottom, which is basically an OOB access to Rx ring array. To fix this, allow using the ids only in scope of "combined" queues reported by ethtool. However, logic should be re
No detection rules found.
No public exploits indexed.
2025-06-18
Published