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
Analysis and contextual insights are available on OpenCVE Cloud.
No vendor fix or workaround currently provided.
Additional remediation guidance may be available on OpenCVE Cloud.
Tracking
Sign in to view the affected projects.
| 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 |
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: 2026-05-11T20:31:28.675Z
Reserved: 2024-08-17T09:11:59.281Z
Link: CVE-2024-43873
Updated: 2025-11-03T22:06:23.270Z
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