On Wed, Aug 07, 2024 at 02:44:54PM -0700, Andrew Morton wrote: > On Wed, 7 Aug 2024 17:34:10 -0400 Peter Xu <peterx@xxxxxxxxxx> wrote: > > > The problem is mprotect() will skip the dax 1G PUD while it shouldn't; > > meanwhile it'll dump some bad PUD in dmesg. Both of them look like (corner > > case) bugs to me.. where: > > > > - skipping the 1G pud means mprotect() will succeed even if the pud won't > > be updated with the correct permission specified. Logically that can > > cause e.g. in mprotect(RO) then write the page can cause data corrupt, > > as the pud page will still be writable. > > > > - the bad pud will generate a pr_err() into dmesg, with no limit so far I > > can see. So I think it means an userspace can DoS the kernel log if it > > wants.. simply by creating the PUD and keep mprotect-ing it > > > > I edited this important info into the [0/n] text, thanks. > > So current kernels can be made to spew into the kernel logs? That's I suppose yes to this one. > considered serious. Can unprivileged userspace code do this? AFAIU, /dev/dax* require root privilege by default, so looks not. But anyone more familiar with real life dax usages please correct me otherwise. Thanks, -- Peter Xu
