vhost/vsock: always initialize seqpacket_allow
There are two issues around seqpacket_allow:
1. seqpacket_allow is not initialized when socket is
created. Thus if features are never set, it will be
read uninitialized.
2. if VIRTIO_VSOCK_F_SEQPACKET is set and then cleared,
then seqpacket_allow will not be cleared appropriately
(existing apps I know about don't usually do this but
it's legal and there's no way to be sure no one relies
on this).
To fix:
- initialize seqpacket_allow after allocation
- set it unconditionally in set_features
Metrics
Affected Vendors & Products
| Source | ID | Title |
|---|---|---|
Debian DLA |
DLA-4008-1 | linux-6.1 security update |
Ubuntu USN |
USN-7100-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7100-2 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7123-1 | Linux kernel (Azure) vulnerabilities |
Ubuntu USN |
USN-7144-1 | Linux kernel (Intel IoTG) vulnerabilities |
Ubuntu USN |
USN-7154-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7155-1 | Linux kernel (NVIDIA) vulnerabilities |
Ubuntu USN |
USN-7156-1 | Linux kernel (GKE) vulnerabilities |
Ubuntu USN |
USN-7154-2 | Linux kernel (HWE) vulnerabilities |
Ubuntu USN |
USN-7194-1 | Linux kernel (Azure) vulnerabilities |
Ubuntu USN |
USN-7196-1 | Linux kernel (Azure) vulnerabilities |
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
Mon, 03 Nov 2025 22:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
|
Wed, 16 Jul 2025 13:45:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
epss
|
epss
|
Wed, 14 May 2025 02:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Redhat
Redhat enterprise Linux |
|
| CPEs | cpe:/a:redhat:enterprise_linux:9 cpe:/o:redhat:enterprise_linux:9 |
|
| Vendors & Products |
Redhat
Redhat enterprise Linux |
Thu, 19 Sep 2024 23:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Weaknesses | CWE-402 |
Wed, 11 Sep 2024 13:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
Tue, 03 Sep 2024 14:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Linux
Linux linux Kernel |
|
| Weaknesses | CWE-909 | |
| CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Linux
Linux linux Kernel |
|
| Metrics |
cvssV3_1
|
cvssV3_1
|
Wed, 21 Aug 2024 23:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
| |
| Metrics |
threat_severity
|
cvssV3_1
|
Wed, 21 Aug 2024 00:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | In the Linux kernel, the following vulnerability has been resolved: vhost/vsock: always initialize seqpacket_allow There are two issues around seqpacket_allow: 1. seqpacket_allow is not initialized when socket is created. Thus if features are never set, it will be read uninitialized. 2. if VIRTIO_VSOCK_F_SEQPACKET is set and then cleared, then seqpacket_allow will not be cleared appropriately (existing apps I know about don't usually do this but it's legal and there's no way to be sure no one relies on this). To fix: - initialize seqpacket_allow after allocation - set it unconditionally in set_features | |
| Title | vhost/vsock: always initialize seqpacket_allow | |
| References |
|
|
Status: PUBLISHED
Assigner: Linux
Published:
Updated: 2025-11-03T22:06:23.270Z
Reserved: 2024-08-17T09:11:59.281Z
Link: CVE-2024-43873
Updated: 2024-09-11T12:42:22.662Z
Status : Modified
Published: 2024-08-21T01:15:11.790
Modified: 2025-11-03T22:18:15.043
Link: CVE-2024-43873
OpenCVE Enrichment
No data.
Debian DLA
Ubuntu USN