On Wed, 13 Jul 2016 03:26:34 +0200, Alexander Hall wrote:
> Then wouldn't EINVAL be a reasonable response? Am I missing something?
We typically ignore flags that don't make sense. For example,
chmod(2) doesn't return an error if you pass in a mode with the
directory bit set, it just masks it ou
On July 12, 2016 8:55:50 PM GMT+02:00, "Todd C. Miller"
wrote:
>On Tue, 12 Jul 2016 07:22:57 -1000, Tim Newsham wrote:
>
>> Here's another root-only (unless kern.usermount is set) panic issue.
>We
>> exercise it through tmpfs but it might be more general than that.
>We're
>> not sure what the
On Tue, Jul 12, 2016 at 12:55:50PM -0600, Todd C. Miller wrote:
> On Tue, 12 Jul 2016 07:22:57 -1000, Tim Newsham wrote:
>
> > Here's another root-only (unless kern.usermount is set) panic issue. We
> > exercise it through tmpfs but it might be more general than that. We're
> > not sure what the
On Tue, 12 Jul 2016 07:22:57 -1000, Tim Newsham wrote:
> Here's another root-only (unless kern.usermount is set) panic issue. We
> exercise it through tmpfs but it might be more general than that. We're
> not sure what the proper remediation should be here.
The only valid flag for umount(2) is
*
* gcc -g unmount_panic.c -o unmount_panic
*/
#ifdef BUG_WRITEUP //---
Unmounting with MNT_DOOMED flag can lead to a kernel panic
Impact:
Root users or users on systems with kern.usermount set to true can
trigger a kernel panic when unmounting a
