Metrics
Affected Vendors & Products
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: 2024-08-21T00:06:25.114Z
Updated: 2024-12-19T09:17:34.388Z
Reserved: 2024-08-17T09:11:59.281Z
Link: CVE-2024-43873
Updated: 2024-09-11T12:42:22.662Z
Status : Analyzed
Published: 2024-08-21T01:15:11.790
Modified: 2024-09-03T13:35:44.897
Link: CVE-2024-43873