Bug 203553
Summary: | possible memory exposure in ASM1062 SATA driver | ||
---|---|---|---|
Product: | Drivers | Reporter: | john kuras (w7og) |
Component: | Other | Assignee: | drivers_other |
Status: | NEW --- | ||
Severity: | normal | ||
Priority: | P1 | ||
Hardware: | Intel | ||
OS: | Linux | ||
Kernel Version: | 4.15.0-48-generic | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: | supporting data: lspci -vvv ; fdisk -l ; dmesg ; dd if=/dev/sdc | hexdump -C |
Created attachment 282681 [details] supporting data: lspci -vvv ; fdisk -l ; dmesg ; dd if=/dev/sdc | hexdump -C I recently purchased an SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 02) No linux driver was supplied with the device, but it appears to work just fine out-of-the-box on ubuntu 18.04. I will attach a copy of the lspci -vvv output for this device. When installed (regardless of whether or not anything is plugged into its SATA ports) a 100MB (un-partitioned) device appears in /dev. I have no idea what this storage is for and I can find no mention of it on the web. My guess is that it is possibly a memory mapped buffer used by the driver. Although, I don't understand why it would be exposed to the outside world. When I first dd'ed from this device (I haven't dared to try to write to it) with no SATA drives plugged into it, I was surprised to see a dump of what appeared to be some stuff left behind by my firefox session. When I plug in a SATA drive, the data (from a dd of the mystery device) looks like it could possibly be cached data from the SATA drive. I don't suppose that this would be a security concern, since the dd from the device needs to run as root anyway... But, is this normal behaviour for a device? If it is grabbing some RAM as a cache, shouldn't it be zeroing it out before exposing it as a pseudo device? Is there really a need for this device to be exposed at all?