On Tue, Dec 18, 2012 at 12:09 PM, Kees Cook wrote:
>
> Do you mean a printk should be emitted on this error path? I can add that if
> so.
dev_err() should be better. With that, please feel free to add
Acked-by: Ming Lei
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the lin
On Mon, Dec 17, 2012 at 6:15 PM, Ming Lei wrote:
> On Tue, Dec 18, 2012 at 9:37 AM, Kees Cook wrote:
>> On Mon, Dec 17, 2012 at 5:30 PM, Ming Lei wrote:
>>> On Sat, Dec 15, 2012 at 6:51 AM, Kees Cook wrote:
Some devices have configurable firmware locations. If these configuration
mech
On Tue, Dec 18, 2012 at 9:37 AM, Kees Cook wrote:
> On Mon, Dec 17, 2012 at 5:30 PM, Ming Lei wrote:
>> On Sat, Dec 15, 2012 at 6:51 AM, Kees Cook wrote:
>>> Some devices have configurable firmware locations. If these configuration
>>> mechanisms are exposed to unprivileged userspace, it may be
On Mon, Dec 17, 2012 at 5:30 PM, Ming Lei wrote:
> On Sat, Dec 15, 2012 at 6:51 AM, Kees Cook wrote:
>> Some devices have configurable firmware locations. If these configuration
>> mechanisms are exposed to unprivileged userspace, it may be possible to
>
> I an wondering how the unprivileged user
On Sat, Dec 15, 2012 at 6:51 AM, Kees Cook wrote:
> Some devices have configurable firmware locations. If these configuration
> mechanisms are exposed to unprivileged userspace, it may be possible to
I an wondering how the unprivileged userspace can write the firmware sysfs
to trigger loading fir
Some devices have configurable firmware locations. If these configuration
mechanisms are exposed to unprivileged userspace, it may be possible to
load firmware from an unexpected location. To minimize the risk of this,
make sure the string "../" does not appear in the firmware name. This
means that
6 matches
Mail list logo