On Mon, Aug 19, 2013 at 9:10 AM, Matthew Garrett <matthew.garrett@xxxxxxxxxx> wrote: > We have no way of validating what all of the Asus WMI methods do on a > given machine, and there's a risk that some will allow hardware state to > be manipulated in such a way that arbitrary code can be executed in the > kernel, circumventing module loading restrictions. Prevent that if any of > these features are enabled. > > Signed-off-by: Matthew Garrett <matthew.garrett@xxxxxxxxxx> > --- > drivers/platform/x86/asus-wmi.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c > index 19c313b..8105530 100644 > --- a/drivers/platform/x86/asus-wmi.c > +++ b/drivers/platform/x86/asus-wmi.c > @@ -1618,6 +1618,9 @@ static int show_dsts(struct seq_file *m, void *data) > int err; > u32 retval = -1; > > + if (secure_modules()) > + return -EPERM; > + > err = asus_wmi_get_devstate(asus, asus->debug.dev_id, &retval); > > if (err < 0) > @@ -1634,6 +1637,9 @@ static int show_devs(struct seq_file *m, void *data) > int err; > u32 retval = -1; > > + if (!capable(CAP_COMPROMISE_KERNEL)) Looks like this and the next chunk weren't changed to the secure_modules() API... -Kees > + return -EPERM; > + > err = asus_wmi_set_devstate(asus->debug.dev_id, asus->debug.ctrl_param, > &retval); > > @@ -1658,6 +1664,9 @@ static int show_call(struct seq_file *m, void *data) > union acpi_object *obj; > acpi_status status; > > + if (!capable(CAP_COMPROMISE_KERNEL)) > + return -EPERM; > + > status = wmi_evaluate_method(ASUS_WMI_MGMT_GUID, > 1, asus->debug.method_id, > &input, &output); > -- > 1.8.3.1 > -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html