CVE-2018-1000204
published 2018-06-26CVE-2018-1000204: Linux Kernel version 3.18 to 4.16 incorrectly handles an SG_IO ioctl on /dev/sg0 with dxfer_direction=SG_DXFER_FROM_DEV and an empty 6-byte cmdp. This may lead…
PriorityP431medium5.3CVSS 3.0
AVNACHPRLUINSUCHINAN
EPSS
1.91%
77.8th percentile
Linux Kernel version 3.18 to 4.16 incorrectly handles an SG_IO ioctl on /dev/sg0 with dxfer_direction=SG_DXFER_FROM_DEV and an empty 6-byte cmdp. This may lead to copying up to 1000 kernel heap pages to the userspace. This has been fixed upstream in https://github.com/torvalds/linux/commit/a45b599ad808c3c982fdcdc12b0b8611c2f92824 already. The problem has limited scope, as users don't usually have permissions to access SCSI devices. On the other hand, e.g. the Nero user manual suggests doing `chmod o+r+w /dev/sg*` to make the devices accessible. NOTE: third parties dispute the relevance of this report, noting that the requirement for an attacker to have both the CAP_SYS_ADMIN and CAP_SYS_RAWIO capabilities makes it "virtually impossible to exploit.
Affected
67 ranges· showing 25
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| canonical | ubuntu_linux | — | — |
| canonical | ubuntu_linux | — | — |
| canonical | ubuntu_linux | — | — |
| debian | debian_linux | — | — |
| debian | linux | < linux 5.16.18-1 (bookworm) | linux 5.16.18-1 (bookworm) |
| debian | linux | < linux 4.16.12-1 (bookworm) | linux 4.16.12-1 (bookworm) |
| debian | linux | < linux 6.1.159-1 (bookworm) | linux 6.1.159-1 (bookworm) |
| debian | linux-6.1 | < linux 6.1.159-1 (bookworm) | linux 6.1.159-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | — | — |
| linux | linux | — | — |
| linux | linux | — | — |
| linux | linux | — | — |
| linux | linux | — | — |
| linux | linux | — | — |
| linux | linux | — | — |
| linux | linux | >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < fd97de9c7b973f46a6103f4170c5efc7b8ef8797 | fd97de9c7b973f46a6103f4170c5efc7b8ef8797 |
| linux | linux | >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < aaf166f37eb6bb55d81c3e40a2a460c8875c8813 | aaf166f37eb6bb55d81c3e40a2a460c8875c8813 |
| linux | linux | >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < 06cb238b0f7ac1669cb06390704c61794724c191 | 06cb238b0f7ac1669cb06390704c61794724c191 |
| linux | linux | >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < b2f140a9f980806f572d672e1780acea66b9a25c | b2f140a9f980806f572d672e1780acea66b9a25c |
| linux | linux | >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < f3f2247ac31cb71d1f05f56536df5946c6652f4a | f3f2247ac31cb71d1f05f56536df5946c6652f4a |
| linux | linux | >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < 7007c894631cf43041dcfa0da7142bbaa7eb673c | 7007c894631cf43041dcfa0da7142bbaa7eb673c |
| linux | linux | >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < dcead36b19d999d687cd9c99b7f37520d9102b57 | dcead36b19d999d687cd9c99b7f37520d9102b57 |
| linux | linux | >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < f2141881b530738777c28bb51c62175895c8178b | f2141881b530738777c28bb51c62175895c8178b |
| linux | linux | >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < 901c7280ca0d5e2b4a8929fbe0bfb007ac2a6544 | 901c7280ca0d5e2b4a8929fbe0bfb007ac2a6544 |
CVSS provenance
nvdv3.05.3MEDIUMCVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N
nvdv2.06.3MEDIUMAV:N/AC:M/Au:S/C:C/I:N/A:N
osv7.8HIGH
vendor_ubuntu7.8HIGH
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-2025-68288: In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was ident
osv·2025-12-16·CVSS 5.3
CVE-2025-68288 [MEDIUM] CVE-2025-68288: In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was ident
In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the va
GHSA
GHSA-87cr-f8hp-2h8x: In the Linux kernel, the following vulnerability has been resolved:
usb: storage: Fix memory leak in USB bulk transport
A kernel memory leak was ide
ghsa_unreviewed·2025-12-16·CVSS 5.3
CVE-2025-68288 [MEDIUM] GHSA-87cr-f8hp-2h8x: In the Linux kernel, the following vulnerability has been resolved:
usb: storage: Fix memory leak in USB bulk transport
A kernel memory leak was ide
In the Linux kernel, the following vulnerability has been resolved:
usb: storage: Fix memory leak in USB bulk transport
A kernel memory leak was identified by the 'ioctl_sg01' test from Linux
Test Project (LTP). The following bytes were mainly observed: 0x53425355.
When USB storage devices incorrectly skip the data phase with status data,
the code extracts/validates the CSW from the sg buffer, but fails to clear
it afterwards. This leaves status protocol data in srb's transfer buffer,
such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can
lead to USB protocols leaks to user space through SCSI generic (/dev/sg*)
interfaces, such as the one seen here when the LTP test requested 512 KiB.
Fix the leak by zeroing the CSW data in srb's transfer buffer immediately
after th
OSV
usb: storage: Fix memory leak in USB bulk transport
osv·2025-12-16·CVSS 5.3
CVE-2025-68288 [MEDIUM] usb: storage: Fix memory leak in USB bulk transport
usb: storage: Fix memory leak in USB bulk transport
In the Linux kernel, the following vulnerability has been resolved:
usb: storage: Fix memory leak in USB bulk transport
A kernel memory leak was identified by the 'ioctl_sg01' test from Linux
Test Project (LTP). The following bytes were mainly observed: 0x53425355.
When USB storage devices incorrectly skip the data phase with status data,
the code extracts/validates the CSW from the sg buffer, but fails to clear
it afterwards. This leaves status protocol data in srb's transfer buffer,
such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can
lead to USB protocols leaks to user space through SCSI generic (/dev/sg*)
interfaces, such as the one seen here when the LTP test requested 512 KiB.
Fix the leak by zeroing the C
Kernel
usb: storage: Fix memory leak in USB bulk transport
kernel_security·2025-10-31·CVSS 5.3
CVE-2018-1000204 [MEDIUM] usb: storage: Fix memory leak in USB bulk transport
usb: storage: Fix memory leak in USB bulk transport
A kernel memory leak was identified by the 'ioctl_sg01' test from Linux
Test Project (LTP). The following bytes were mainly observed: 0x53425355.
When USB storage devices incorrectly skip the data phase with status data,
the code extracts/validates the CSW from the sg buffer, but fails to clear
it afterwards. This leaves status protocol data in srb's transfer buffer,
such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can
lead to USB protocols leaks to user space through SCSI generic (/dev/sg*)
interfaces, such as the one seen here when the LTP test requested 512 KiB.
Fix the leak by zeroing the CSW data in srb's transfer buffer immediately
after the validation of devices that skip data phase.
Note: Differently from
OSV
CVE-2022-48853: In the Linux kernel, the following vulnerability has been resolved: swiotlb: fix info leak with DMA_FROM_DEVICE The problem I'm addressing was discove
osv·2024-07-16·CVSS 5.5
CVE-2022-48853 [MEDIUM] CVE-2022-48853: In the Linux kernel, the following vulnerability has been resolved: swiotlb: fix info leak with DMA_FROM_DEVICE The problem I'm addressing was discove
In the Linux kernel, the following vulnerability has been resolved: swiotlb: fix info leak with DMA_FROM_DEVICE The problem I'm addressing was discovered by the LTP test covering cve-2018-1000204. A short description of what happens follows: 1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO interface with: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV and a corresponding dxferp. The peculiar thing about this is that TUR is not reading from the device. 2) In sg_start_req() the invocation of blk_rq_map_user() effectively bounces the user-space buffer. As if the device was to transfer into it. Since commit a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in sg_build_indirect()") we make sure this first bounce buffer is allocated with GFP_ZERO. 3) For the rest o
GHSA
GHSA-p622-mwq3-26f2: In the Linux kernel, the following vulnerability has been resolved:
swiotlb: fix info leak with DMA_FROM_DEVICE
The problem I'm addressing was disco
ghsa_unreviewed·2024-07-16
CVE-2022-48853 [MEDIUM] GHSA-p622-mwq3-26f2: In the Linux kernel, the following vulnerability has been resolved:
swiotlb: fix info leak with DMA_FROM_DEVICE
The problem I'm addressing was disco
In the Linux kernel, the following vulnerability has been resolved:
swiotlb: fix info leak with DMA_FROM_DEVICE
The problem I'm addressing was discovered by the LTP test covering
cve-2018-1000204.
A short description of what happens follows:
1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO
interface with: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV
and a corresponding dxferp. The peculiar thing about this is that TUR
is not reading from the device.
2) In sg_start_req() the invocation of blk_rq_map_user() effectively
bounces the user-space buffer. As if the device was to transfer into
it. Since commit a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in
sg_build_indirect()") we make sure this first bounce buffer is
allocated with GFP_ZERO.
3) For the res
GHSA
GHSA-xrfx-4wv5-78ww: ** DISPUTED ** Linux Kernel version 3
ghsa_unreviewed·2022-05-13
CVE-2018-1000204 [MEDIUM] GHSA-xrfx-4wv5-78ww: ** DISPUTED ** Linux Kernel version 3
** DISPUTED ** Linux Kernel version 3.18 to 4.16 incorrectly handles an SG_IO ioctl on /dev/sg0 with dxfer_direction=SG_DXFER_FROM_DEV and an empty 6-byte cmdp. This may lead to copying up to 1000 kernel heap pages to the userspace. This has been fixed upstream in https://github.com/torvalds/linux/commit/a45b599ad808c3c982fdcdc12b0b8611c2f92824 already. The problem has limited scope, as users don't usually have permissions to access SCSI devices. On the other hand, e.g. the Nero user manual suggests doing `chmod o+r+w /dev/sg*` to make the devices accessible. NOTE: third parties dispute the relevance of this report, noting that the requirement for an attacker to have both the CAP_SYS_ADMIN and CAP_SYS_RAWIO capabilities makes it "virtually impossible to exploit."
Kernel
swiotlb: fix info leak with DMA_FROM_DEVICE
kernel_security·2022-02-11
CVE-2018-1000204 swiotlb: fix info leak with DMA_FROM_DEVICE
swiotlb: fix info leak with DMA_FROM_DEVICE
The problem I'm addressing was discovered by the LTP test covering
cve-2018-1000204.
A short description of what happens follows:
1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO
interface with: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV
and a corresponding dxferp. The peculiar thing about this is that TUR
is not reading from the device.
2) In sg_start_req() the invocation of blk_rq_map_user() effectively
bounces the user-space buffer. As if the device was to transfer into
it. Since commit a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in
sg_build_indirect()") we make sure this first bounce buffer is
allocated with GFP_ZERO.
3) For the rest of the story we keep ignoring that we have a TUR, so the
device won
OSV
linux-azure, linux-oem, linux-gcp vulnerabilities
osv·2018-08-28·CVSS 5.5
CVE-2018-1000200 [MEDIUM] linux-azure, linux-oem, linux-gcp vulnerabilities
linux-azure, linux-oem, linux-gcp vulnerabilities
It was discovered that, when attempting to handle an out-of-memory
situation, a null pointer dereference could be triggered in the Linux
kernel in some circumstances. A local attacker could use this to cause a
denial of service (system crash). (CVE-2018-1000200)
Wen Xu discovered that the XFS filesystem implementation in the Linux
kernel did not properly validate meta-data information. An attacker could
use this to construct a malicious xfs image that, when mounted, could cause
a denial of service (system crash). (CVE-2018-10323)
Wen Xu discovered that the XFS filesystem implementation in the Linux
kernel did not properly validate xattr information. An attacker could use
this to construct a malicious xfs image that, when mounted, could c
OSV
linux, linux-aws, linux-gcp, linux-kvm, linux-raspi2 vulnerabilities
osv·2018-08-24·CVSS 5.5
CVE-2018-1000200 [MEDIUM] linux, linux-aws, linux-gcp, linux-kvm, linux-raspi2 vulnerabilities
linux, linux-aws, linux-gcp, linux-kvm, linux-raspi2 vulnerabilities
It was discovered that, when attempting to handle an out-of-memory
situation, a null pointer dereference could be triggered in the Linux
kernel in some circumstances. A local attacker could use this to cause a
denial of service (system crash). (CVE-2018-1000200)
Wen Xu discovered that the XFS filesystem implementation in the Linux
kernel did not properly validate meta-data information. An attacker could
use this to construct a malicious xfs image that, when mounted, could cause
a denial of service (system crash). (CVE-2018-10323)
Wen Xu discovered that the XFS filesystem implementation in the Linux
kernel did not properly validate xattr information. An attacker could use
this to construct a malicious xfs image that, wh
OSV
linux vulnerabilities
osv·2018-08-24·CVSS 4.3
CVE-2016-10208 [MEDIUM] linux vulnerabilities
linux vulnerabilities
Ralf Spenneberg discovered that the ext4 implementation in the Linux kernel
did not properly validate meta block groups. An attacker with physical
access could use this to specially craft an ext4 image that causes a denial
of service (system crash). (CVE-2016-10208)
It was discovered that an information disclosure vulnerability existed in
the ACPI implementation of the Linux kernel. A local attacker could use
this to expose sensitive information (kernel memory addresses).
(CVE-2017-11472)
It was discovered that a buffer overflow existed in the ACPI table parsing
implementation in the Linux kernel. A local attacker could use this to
construct a malicious ACPI table that, when loaded, caused a denial of
service (system crash) or possibly execute arbitrary code.
(CVE-
OSV
linux-hwe vulnerabilities
osv·2018-08-24·CVSS 5.5
CVE-2018-10002 [MEDIUM] linux-hwe vulnerabilities
linux-hwe vulnerabilities
USN-3752-1 fixed vulnerabilities in the Linux kernel for Ubuntu 18.04
LTS. This update provides the corresponding updates for the Linux
Hardware Enablement (HWE) kernel from Ubuntu 18.04 LTS for Ubuntu
16.04 LTS.
It was discovered that, when attempting to handle an out-of-memory
situation, a null pointer dereference could be triggered in the Linux
kernel in some circumstances. A local attacker could use this to cause a
denial of service (system crash). (CVE-2018-1000200)
Wen Xu discovered that the XFS filesystem implementation in the Linux
kernel did not properly validate meta-data information. An attacker could
use this to construct a malicious xfs image that, when mounted, could cause
a denial of service (system crash). (CVE-2018-10323)
Wen Xu discovered tha
OSV
linux-lts-xenial, linux-aws vulnerabilities
osv·2018-07-02·CVSS 7.8
CVE-2017-18255 [HIGH] linux-lts-xenial, linux-aws vulnerabilities
linux-lts-xenial, linux-aws vulnerabilities
USN-3696-1 fixed vulnerabilities in the Linux kernel for Ubuntu 16.04
LTS. This update provides the corresponding updates for the Linux
Hardware Enablement (HWE) kernel from Ubuntu 16.04 LTS for Ubuntu
14.04 LTS.
It was discovered that an integer overflow existed in the perf subsystem of
the Linux kernel. A local attacker could use this to cause a denial of
service (system crash). (CVE-2017-18255)
Wei Fang discovered an integer overflow in the F2FS filesystem
implementation in the Linux kernel. A local attacker could use this to
cause a denial of service. (CVE-2017-18257)
It was discovered that an information leak existed in the generic SCSI
driver in the Linux kernel. A local attacker could use this to expose
sensitive information (kernel me
OSV
linux, linux-aws, linux-kvm, linux-raspi2, linux-snapdragon vulnerabilities
osv·2018-07-02·CVSS 7.8
CVE-2017-18255 [HIGH] linux, linux-aws, linux-kvm, linux-raspi2, linux-snapdragon vulnerabilities
linux, linux-aws, linux-kvm, linux-raspi2, linux-snapdragon vulnerabilities
It was discovered that an integer overflow existed in the perf subsystem of
the Linux kernel. A local attacker could use this to cause a denial of
service (system crash). (CVE-2017-18255)
Wei Fang discovered an integer overflow in the F2FS filesystem
implementation in the Linux kernel. A local attacker could use this to
cause a denial of service. (CVE-2017-18257)
It was discovered that an information leak existed in the generic SCSI
driver in the Linux kernel. A local attacker could use this to expose
sensitive information (kernel memory). (CVE-2018-1000204)
It was discovered that the wait4() system call in the Linux kernel did not
properly validate its arguments in some situations. A local attacker could
possi
OSV
CVE-2018-1000204: Linux Kernel version 3
osv·2018-06-26·CVSS 5.3
CVE-2018-1000204 [MEDIUM] CVE-2018-1000204: Linux Kernel version 3
Linux Kernel version 3.18 to 4.16 incorrectly handles an SG_IO ioctl on /dev/sg0 with dxfer_direction=SG_DXFER_FROM_DEV and an empty 6-byte cmdp. This may lead to copying up to 1000 kernel heap pages to the userspace. This has been fixed upstream in https://github.com/torvalds/linux/commit/a45b599ad808c3c982fdcdc12b0b8611c2f92824 already. The problem has limited scope, as users don't usually have permissions to access SCSI devices. On the other hand, e.g. the Nero user manual suggests doing `chmod o+r+w /dev/sg*` to make the devices accessible. NOTE: third parties dispute the relevance of this report, noting that the requirement for an attacker to have both the CAP_SYS_ADMIN and CAP_SYS_RAWIO capabilities makes it "virtually impossible to exploit.
Red Hat
kernel: usb: storage: Fix memory leak in USB bulk transport
vendor_redhat·2025-12-16·CVSS 5.3
CVE-2025-68288 [MEDIUM] CWE-772 kernel: usb: storage: Fix memory leak in USB bulk transport
kernel: usb: storage: Fix memory leak in USB bulk transport
In the Linux kernel, the following vulnerability has been resolved:
usb: storage: Fix memory leak in USB bulk transport
A kernel memory leak was identified by the 'ioctl_sg01' test from Linux
Test Project (LTP). The following bytes were mainly observed: 0x53425355.
When USB storage devices incorrectly skip the data phase with status data,
the code extracts/validates the CSW from the sg buffer, but fails to clear
it afterwards. This leaves status protocol data in srb's transfer buffer,
such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can
lead to USB protocols leaks to user space through SCSI generic (/dev/sg*)
interfaces, such as the one seen here when the LTP test requested 512 KiB.
Fix the leak by zeroing t
Debian
CVE-2025-68288: linux - In the Linux kernel, the following vulnerability has been resolved: usb: storag...
vendor_debian·2025·CVSS 5.3
CVE-2025-68288 [MEDIUM] CVE-2025-68288: linux - In the Linux kernel, the following vulnerability has been resolved: usb: storag...
In the Linux kernel, the following vulnerability has been resolved: usb: storage: Fix memory leak in USB bulk transport A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the va
Red Hat
kernel: swiotlb: fix info leak with DMA_FROM_DEVICE
vendor_redhat·2024-07-16·CVSS 5.5
CVE-2022-48853 [MEDIUM] CWE-401 kernel: swiotlb: fix info leak with DMA_FROM_DEVICE
kernel: swiotlb: fix info leak with DMA_FROM_DEVICE
In the Linux kernel, the following vulnerability has been resolved:
swiotlb: fix info leak with DMA_FROM_DEVICE
The problem I'm addressing was discovered by the LTP test covering
cve-2018-1000204.
A short description of what happens follows:
1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO
interface with: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV
and a corresponding dxferp. The peculiar thing about this is that TUR
is not reading from the device.
2) In sg_start_req() the invocation of blk_rq_map_user() effectively
bounces the user-space buffer. As if the device was to transfer into
it. Since commit a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in
sg_build_indirect()") we make sure this first bounce
Debian
CVE-2022-48853: linux - In the Linux kernel, the following vulnerability has been resolved: swiotlb: fi...
vendor_debian·2022·CVSS 5.5
CVE-2022-48853 [MEDIUM] CVE-2022-48853: linux - In the Linux kernel, the following vulnerability has been resolved: swiotlb: fi...
In the Linux kernel, the following vulnerability has been resolved: swiotlb: fix info leak with DMA_FROM_DEVICE The problem I'm addressing was discovered by the LTP test covering cve-2018-1000204. A short description of what happens follows: 1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO interface with: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV and a corresponding dxferp. The peculiar thing about this is that TUR is not reading from the device. 2) In sg_start_req() the invocation of blk_rq_map_user() effectively bounces the user-space buffer. As if the device was to transfer into it. Since commit a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in sg_build_indirect()") we make sure this first bounce buffer is allocated with GFP_ZERO. 3) For the rest o
Ubuntu
Linux kernel (Azure, GCP, OEM) vulnerabilities
vendor_ubuntu·2018-08-28·CVSS 5.5
CVE-2018-1000200 [MEDIUM] Linux kernel (Azure, GCP, OEM) vulnerabilities
Title: Linux kernel (Azure, GCP, OEM) vulnerabilities
Summary: Several security issues were fixed in the Linux kernel.
It was discovered that, when attempting to handle an out-of-memory
situation, a null pointer dereference could be triggered in the Linux
kernel in some circumstances. A local attacker could use this to cause a
denial of service (system crash). (CVE-2018-1000200)
Wen Xu discovered that the XFS filesystem implementation in the Linux
kernel did not properly validate meta-data information. An attacker could
use this to construct a malicious xfs image that, when mounted, could cause
a denial of service (system crash). (CVE-2018-10323)
Wen Xu discovered that the XFS filesystem implementation in the Linux
kernel did not properly validate xattr information. An attacker could u
Ubuntu
Linux kernel vulnerabilities
vendor_ubuntu·2018-08-24·CVSS 5.5
CVE-2018-1000200 [MEDIUM] Linux kernel vulnerabilities
Title: Linux kernel vulnerabilities
Summary: Several security issues were fixed in the Linux kernel.
It was discovered that, when attempting to handle an out-of-memory
situation, a null pointer dereference could be triggered in the Linux
kernel in some circumstances. A local attacker could use this to cause a
denial of service (system crash). (CVE-2018-1000200)
Wen Xu discovered that the XFS filesystem implementation in the Linux
kernel did not properly validate meta-data information. An attacker could
use this to construct a malicious xfs image that, when mounted, could cause
a denial of service (system crash). (CVE-2018-10323)
Wen Xu discovered that the XFS filesystem implementation in the Linux
kernel did not properly validate xattr information. An attacker could use
this to constru
Ubuntu
Linux kernel (HWE) vulnerabilities
vendor_ubuntu·2018-08-24·CVSS 5.5
CVE-2018-1000200 [MEDIUM] Linux kernel (HWE) vulnerabilities
Title: Linux kernel (HWE) vulnerabilities
Summary: Several security issues were fixed in the Linux kernel.
USN-3752-1 fixed vulnerabilities in the Linux kernel for Ubuntu 18.04
LTS. This update provides the corresponding updates for the Linux
Hardware Enablement (HWE) kernel from Ubuntu 18.04 LTS for Ubuntu
16.04 LTS.
It was discovered that, when attempting to handle an out-of-memory
situation, a null pointer dereference could be triggered in the Linux
kernel in some circumstances. A local attacker could use this to cause a
denial of service (system crash). (CVE-2018-1000200)
Wen Xu discovered that the XFS filesystem implementation in the Linux
kernel did not properly validate meta-data information. An attacker could
use this to construct a malicious xfs image that, when mounted, could
Ubuntu
Linux kernel vulnerabilities
vendor_ubuntu·2018-08-24·CVSS 4.3
CVE-2016-10208 [MEDIUM] Linux kernel vulnerabilities
Title: Linux kernel vulnerabilities
Summary: Several security issues were fixed in the Linux kernel.
Ralf Spenneberg discovered that the ext4 implementation in the Linux kernel
did not properly validate meta block groups. An attacker with physical
access could use this to specially craft an ext4 image that causes a denial
of service (system crash). (CVE-2016-10208)
It was discovered that an information disclosure vulnerability existed in
the ACPI implementation of the Linux kernel. A local attacker could use
this to expose sensitive information (kernel memory addresses).
(CVE-2017-11472)
It was discovered that a buffer overflow existed in the ACPI table parsing
implementation in the Linux kernel. A local attacker could use this to
construct a malicious ACPI table that, when loaded, cau
Ubuntu
Linux kernel vulnerabilities
vendor_ubuntu·2018-07-02·CVSS 7.8
CVE-2017-13695 [HIGH] Linux kernel vulnerabilities
Title: Linux kernel vulnerabilities
Summary: Several security issues were fixed in the Linux kernel.
It was discovered that an integer overflow existed in the perf subsystem of
the Linux kernel. A local attacker could use this to cause a denial of
service (system crash). (CVE-2017-18255)
Wei Fang discovered an integer overflow in the F2FS filesystem
implementation in the Linux kernel. A local attacker could use this to
cause a denial of service. (CVE-2017-18257)
It was discovered that an information leak existed in the generic SCSI
driver in the Linux kernel. A local attacker could use this to expose
sensitive information (kernel memory). (CVE-2018-1000204)
It was discovered that the wait4() system call in the Linux kernel did not
properly validate its arguments in some situations. A
Ubuntu
Linux kernel (Xenial HWE) vulnerabilities
vendor_ubuntu·2018-07-02·CVSS 7.8
CVE-2017-13695 [HIGH] Linux kernel (Xenial HWE) vulnerabilities
Title: Linux kernel (Xenial HWE) vulnerabilities
Summary: Several security issues were fixed in the Linux kernel.
USN-3696-1 fixed vulnerabilities in the Linux kernel for Ubuntu 16.04
LTS. This update provides the corresponding updates for the Linux
Hardware Enablement (HWE) kernel from Ubuntu 16.04 LTS for Ubuntu
14.04 LTS.
It was discovered that an integer overflow existed in the perf subsystem of
the Linux kernel. A local attacker could use this to cause a denial of
service (system crash). (CVE-2017-18255)
Wei Fang discovered an integer overflow in the F2FS filesystem
implementation in the Linux kernel. A local attacker could use this to
cause a denial of service. (CVE-2017-18257)
It was discovered that an information leak existed in the generic SCSI
driver in the Linux kernel. A l
Red Hat
kernel: Infoleak caused by incorrect handling of the SG_IO ioctl
vendor_redhat·2018-05-18·CVSS 5.3
CVE-2018-1000204 [MEDIUM] CWE-200 kernel: Infoleak caused by incorrect handling of the SG_IO ioctl
kernel: Infoleak caused by incorrect handling of the SG_IO ioctl
Linux Kernel version 3.18 to 4.16 incorrectly handles an SG_IO ioctl on /dev/sg0 with dxfer_direction=SG_DXFER_FROM_DEV and an empty 6-byte cmdp. This may lead to copying up to 1000 kernel heap pages to the userspace. This has been fixed upstream in https://github.com/torvalds/linux/commit/a45b599ad808c3c982fdcdc12b0b8611c2f92824 already. The problem has limited scope, as users don't usually have permissions to access SCSI devices. On the other hand, e.g. the Nero user manual suggests doing `chmod o+r+w /dev/sg*` to make the devices accessible. NOTE: third parties dispute the relevance of this report, noting that the requirement for an attacker to have both the CAP_SYS_ADMIN and CAP_SYS_RAWIO capabilities makes it "virtually
Debian
CVE-2018-1000204: linux - Linux Kernel version 3.18 to 4.16 incorrectly handles an SG_IO ioctl on /dev/sg0...
vendor_debian·2018·CVSS 5.3
CVE-2018-1000204 [MEDIUM] CVE-2018-1000204: linux - Linux Kernel version 3.18 to 4.16 incorrectly handles an SG_IO ioctl on /dev/sg0...
Linux Kernel version 3.18 to 4.16 incorrectly handles an SG_IO ioctl on /dev/sg0 with dxfer_direction=SG_DXFER_FROM_DEV and an empty 6-byte cmdp. This may lead to copying up to 1000 kernel heap pages to the userspace. This has been fixed upstream in https://github.com/torvalds/linux/commit/a45b599ad808c3c982fdcdc12b0b8611c2f92824 already. The problem has limited scope, as users don't usually have permissions to access SCSI devices. On the other hand, e.g. the Nero user manual suggests doing `chmod o+r+w /dev/sg*` to make the devices accessible. NOTE: third parties dispute the relevance of this report, noting that the requirement for an attacker to have both the CAP_SYS_ADMIN and CAP_SYS_RAWIO capabilities makes it "virtually impossible to exploit.
Scope: local
bookworm: resolved (fixed in
No detection rules found.
No public exploits indexed.
Bugzilla
CVE-2025-68288 kernel: usb: storage: Fix memory leak in USB bulk transport
bugzilla·2025-12-16·CVSS 5.3
CVE-2025-68288 [MEDIUM] CVE-2025-68288 kernel: usb: storage: Fix memory leak in USB bulk transport
CVE-2025-68288 kernel: usb: storage: Fix memory leak in USB bulk transport
In the Linux kernel, the following vulnerability has been resolved:
usb: storage: Fix memory leak in USB bulk transport
A kernel memory leak was identified by the 'ioctl_sg01' test from Linux
Test Project (LTP). The following bytes were mainly observed: 0x53425355.
When USB storage devices incorrectly skip the data phase with status data,
the code extracts/validates the CSW from the sg buffer, but fails to clear
it afterwards. This leaves status protocol data in srb's transfer buffer,
such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can
lead to USB protocols leaks to user space through SCSI generic (/dev/sg*)
interfaces, such as the one seen here when the LTP test requested 512 KiB.
Fix th
Bugzilla
CVE-2018-1000204 kernel: Infoleak caused by incorrect handling of the SG_IO ioctl [fedora-all]
bugzilla·2018-06-11·CVSS 5.3
CVE-2018-1000204 [MEDIUM] CVE-2018-1000204 kernel: Infoleak caused by incorrect handling of the SG_IO ioctl [fedora-all]
CVE-2018-1000204 kernel: Infoleak caused by incorrect handling of the SG_IO ioctl [fedora-all]
This is an automatically created tracking bug! It was created to ensure
that one or more security vulnerabilities are fixed in affected versions
of fedora-all.
For comments that are specific to the vulnerability please use bugs filed
against the "Security Response" product referenced in the "Blocks" field.
For more information see:
http://fedoraproject.org/wiki/Security/TrackingBugs
When submitting as an update, use the fedpkg template provided in the next
comment(s). This will include the bug IDs of this tracking bug as well as
the relevant top-level CVE bugs.
Please also mention the CVE IDs being fixed in the RPM changelog and the
fedpkg commit message.
NOTE: this issue affects multiple s
Bugzilla
CVE-2018-1000204 kernel: Infoleak caused by incorrect handling of the SG_IO ioctl
bugzilla·2018-06-08·CVSS 5.3
CVE-2018-1000204 [MEDIUM] CVE-2018-1000204 kernel: Infoleak caused by incorrect handling of the SG_IO ioctl
CVE-2018-1000204 kernel: Infoleak caused by incorrect handling of the SG_IO ioctl
A malformed SG_IO ioctl issued for a SCSI device in the Linux kernel leads to a local kernel data leak manifesting in up to approx. 1000 memory pages copied to the userspace. The problem has limited scope, as non-privileged users usually have no permissions to access SCSI device files.
References:
http://seclists.org/oss-sec/2018/q2/168
An upstream patch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a45b599ad808c3c982fdcdc12b0b8611c2f92824
https://marc.info/?l=linux-scsi&m=152933023515279&w=2 (suggested but not approved at the time of this writing)
Discussion:
Created kernel tracking bugs for this issue:
Affects: fedora-all [bug 1589688]
---
This was fixed for Fedor
Wiz
CVE-2025-68288 Impact, Exploitability, and Mitigation Steps | Wiz
blogs_wiz·CVSS 5.3
CVE-2025-68288 [MEDIUM] CVE-2025-68288 Impact, Exploitability, and Mitigation Steps | Wiz
## CVE-2025-68288 :
Linux Kernel vulnerability analysis and mitigation
In the Linux kernel, the following vulnerability has been resolved:
usb: storage: Fix memory leak in USB bulk transport
A kernel memory leak was identified by the 'ioctl_sg01' test from Linux
Test Project (LTP). The following bytes were mainly observed: 0x53425355.
When USB storage devices incorrectly skip the data phase with status data,
the code extracts/validates the CSW from the sg buffer, but fails to clear
it afterwards. This leaves status protocol data in srb's transfer buffer,
such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can
lead to USB protocols leaks to user space through SCSI generic (/dev/sg*)
interfaces, such as the one seen here when the LTP test requested 512 KiB.
Fix the l
http://lists.opensuse.org/opensuse-security-announce/2019-05/msg00043.htmlhttp://www.openwall.com/lists/oss-security/2018/06/26/3https://access.redhat.com/errata/RHSA-2018:2948https://github.com/torvalds/linux/commit/a45b599ad808c3c982fdcdc12b0b8611c2f92824https://lists.debian.org/debian-lts-announce/2018/07/msg00015.htmlhttps://lists.debian.org/debian-lts-announce/2018/07/msg00016.htmlhttps://lists.debian.org/debian-lts-announce/2018/07/msg00020.htmlhttps://usn.ubuntu.com/3696-1/https://usn.ubuntu.com/3696-2/https://usn.ubuntu.com/3752-1/https://usn.ubuntu.com/3752-2/https://usn.ubuntu.com/3752-3/https://usn.ubuntu.com/3754-1/http://lists.opensuse.org/opensuse-security-announce/2019-05/msg00043.htmlhttp://www.openwall.com/lists/oss-security/2018/06/26/3https://access.redhat.com/errata/RHSA-2018:2948https://github.com/torvalds/linux/commit/a45b599ad808c3c982fdcdc12b0b8611c2f92824https://lists.debian.org/debian-lts-announce/2018/07/msg00015.htmlhttps://lists.debian.org/debian-lts-announce/2018/07/msg00016.htmlhttps://lists.debian.org/debian-lts-announce/2018/07/msg00020.htmlhttps://usn.ubuntu.com/3696-1/https://usn.ubuntu.com/3696-2/https://usn.ubuntu.com/3752-1/https://usn.ubuntu.com/3752-2/https://usn.ubuntu.com/3752-3/https://usn.ubuntu.com/3754-1/
2018-06-26
Published