Bug 467988 - kernel: reading from /proc/acpi/video/GFX0/DD01/state crashes system
kernel: reading from /proc/acpi/video/GFX0/DD01/state crashes system
Status: CLOSED WONTFIX
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
high Severity high
: ---
: ---
Assigned To: Red Hat Product Security
:
Depends On: 467952 467989 467990 467991
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-22 02:28 EDT by Eugene Teo (Security Response)
Modified: 2015-07-29 13:47 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-03-09 11:21:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
acpidump output from affected machine. (154.92 KB, text/plain)
2008-10-22 14:16 EDT, Warren Lewis
no flags Details

  None (edit)
Description Eugene Teo (Security Response) 2008-10-22 02:28:21 EDT
From Warren Lewis:
Reading from /proc/acpi/video/GFX0/DD01/state crashes system. Permissions allow
this to be done by a non root user. I have set severity High as this at least
allows a DOS attack. System is a HP DV9334us with NVIDIA G70 [GeForce Go 7600] video.

Version-Release number of selected component (if applicable):
kernel-2.6.26.3-29.fc9.x86_64

How reproducible:
Always

Steps to Reproduce:
1. cat /proc/acpi/video/GFX0/DD01/state

Actual results:
System crashes (no panic) with screen display distorted.

Expected results:
No crash.

Additional info:
This also happens under Knoppix so it's not a Fedora specific problem.  I'm
reporting it here as I'm running a Fedora kernel and not a vanilla kernel.org
one.
Comment 3 Eugene Teo (Security Response) 2008-10-22 02:35:47 EDT
Proposed patch: https://bugzilla.redhat.com/show_bug.cgi?id=467952#c4
Comment 4 Eugene Teo (Security Response) 2008-10-22 02:35:58 EDT
Please post your updates to this top-level bug instead of bug #467952. Thanks.
Comment 5 Matthew Garrett 2008-10-22 07:42:34 EDT
To root cause this we'll need the output of the acpidump application from the pmtools package on the affected machine.
Comment 6 Eugene Teo (Security Response) 2008-10-22 08:29:10 EDT
(In reply to comment #5)
> To root cause this we'll need the output of the acpidump application from the
> pmtools package on the affected machine.

Warren, please provide us with the output as advised in comment #5. Thanks.
Comment 7 Warren Lewis 2008-10-22 14:12:17 EDT
The patch did remove read from other, however it also removed read from user
(root).  I added S_IRUSR to the modes to correct this.  

        /* 'state' [R/W] */
        acpi_video_device_state_fops.write = acpi_video_device_write_state;
-       entry = proc_create_data("state", S_IFREG | S_IRUGO | S_IWUSR,
+       entry = proc_create_data("state", S_IFREG | S_IRGRP | S_IRUSR |
S_IWUSR,
                                 device_dir,
                                 &acpi_video_device_state_fops,
                                 acpi_driver_data(device));

This seems to work ok.
Comment 8 Warren Lewis 2008-10-22 14:16:11 EDT
Created attachment 321185 [details]
acpidump output from affected machine.
Comment 9 Warren Lewis 2008-10-22 14:24:41 EDT
I made an error on the kernel version I am running, it's 2.6.26.5-45.fc9.x86_64
Comment 10 Matthew Garrett 2008-10-22 14:50:20 EDT
Right. Reading from state on this machine executes the following code:

Method (_DCS, 0, NotSerialized)
       {
             TRAP (0x01)
             If (And (CSTE, 0x01))
             {
                  Return (0x1F)
             }

             Return (0x1D)
        }

with TRAP being:

    Method (TRAP, 1, Serialized)
    {
        Store (Arg0, SMIF)
        Store (0x00, TRP0)
        Return (SMIF)
    }

SMIF is the system management interrupt function, and the write to TRP0 presumably initiates system management mode. At this point the system is now executing BIOS code that's entirely out of our control. On this specific machine, it results in the machine hanging.

This is pretty clearly a BIOS bug. I'm not convinced we need to change the default behaviour of the kernel for anyone else.
Comment 11 Warren Lewis 2008-10-22 16:20:29 EDT
Flashed latest BIOS from HP (F.2C) problem still happens.
Comment 12 Eugene Teo (Security Response) 2008-10-22 21:23:45 EDT
(In reply to comment #10)
> Right. Reading from state on this machine executes the following code:
> 
> Method (_DCS, 0, NotSerialized)
>        {
>              TRAP (0x01)
>              If (And (CSTE, 0x01))
>              {
>                   Return (0x1F)
>              }
> 
>              Return (0x1D)
>         }
> 
> with TRAP being:
> 
>     Method (TRAP, 1, Serialized)
>     {
>         Store (Arg0, SMIF)
>         Store (0x00, TRP0)
>         Return (SMIF)
>     }
> 
> SMIF is the system management interrupt function, and the write to TRP0
> presumably initiates system management mode. At this point the system is now
> executing BIOS code that's entirely out of our control. On this specific
> machine, it results in the machine hanging.
> 
> This is pretty clearly a BIOS bug. I'm not convinced we need to change the
> default behaviour of the kernel for anyone else.

Ok, so I guess in this case, restricting the state file from local unprivileged users is the way to go. Are you going to submit the patch upstream? If so, please CC me.

Thanks, Eugene
Comment 13 Eugene Teo (Security Response) 2008-10-22 21:27:03 EDT
(In reply to comment #12)
> (In reply to comment #10)
[...]
> > SMIF is the system management interrupt function, and the write to TRP0
> > presumably initiates system management mode. At this point the system is now
> > executing BIOS code that's entirely out of our control. On this specific
> > machine, it results in the machine hanging.
> > 
> > This is pretty clearly a BIOS bug. I'm not convinced we need to change the
> > default behaviour of the kernel for anyone else.
> 
> Ok, so I guess in this case, restricting the state file from local unprivileged
> users is the way to go. Are you going to submit the patch upstream? If so,
> please CC me.

Are there other ways to trigger the ACPI methods? I guess changing the permissions for these files would probably break userspace as well?

Eugene
Comment 14 Matthew Garrett 2008-10-22 21:33:31 EDT
Well, it works fine on most systems - it's simply pathologically broken on this one. If we knew what the SMI call actually did then it's possible that we could ensure that it didn't trash the system in the process. I don't think we can risk breaking userspace for the sake of one system with an awkward firmware.
Comment 15 Matthew Garrett 2008-10-22 21:48:56 EDT
Since it only affects this one system, I'd lean towards not applying this patch and instead trying to find out from HP what this SMI call actually does. There may be some aspect of system state that differs between us and Windows here, and if the firmware assumes that then there's the potential for things to go wrong.
Comment 16 Eugene Teo (Security Response) 2008-10-22 21:55:54 EDT
(In reply to comment #15)
> Since it only affects this one system, I'd lean towards not applying this patch
> and instead trying to find out from HP what this SMI call actually does. There
> may be some aspect of system state that differs between us and Windows here,
> and if the firmware assumes that then there's the potential for things to go
> wrong.

Thanks Matthew. As spoken, I'm taking this off-line with Linda.
Comment 17 Warren Lewis 2008-10-23 01:39:35 EDT
My machine is a laptop with no untrusted users so it's not a big deal for me however I wonder if this BIOS is modified and used on other HP systems such as desktops or servers as those would be more apt to have more then one user and be at risk from a local user.
Comment 20 Eugene Teo (Security Response) 2008-11-18 19:40:52 EST
(In reply to comment #17)
> My machine is a laptop with no untrusted users so it's not a big deal for me
> however I wonder if this BIOS is modified and used on other HP systems such as
> desktops or servers as those would be more apt to have more then one user and
> be at risk from a local user.

I have been trying to reach for someone from HP, via HP SSRT and HP Support, for the past few weeks, but no one there seems to want to investigate this. I was told by HP that this laptop is not supported in Linux, but they will look to see if this problem affects other HP hardware that they do support in Linux. Unfortunately, I am unable to determine when HP will get back to me wrt issue, but I will keep you posted as soon as I have an update. Thanks Warren.
Comment 24 Eugene Teo (Security Response) 2008-12-25 03:01:28 EST
Warren, just to keep you updated, we have contacted HP. Matthew will be working with them to resolve this after the season holidays. Thanks, Eugene
Comment 25 Warren Lewis 2009-01-11 17:14:12 EST
(In reply to comment #24)
> Warren, just to keep you updated, we have contacted HP. Matthew will be working
> with them to resolve this after the season holidays. Thanks, Eugene

Thanks Eugene.
Comment 29 Warren Lewis 2015-03-06 22:49:43 EST
At this point I would recommend closure of this bug as it is quite old and stale now.  It is unlikely that HP will be looking at this BIOS at this point.

Note You need to log in before you can comment on or make changes to this bug.