linux-kernel - Re: [PATCH v2] dax: fix NULL pointer in __dax_pmd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Tue, 22 Sep 2015 14:26:30 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	Ross Zwisler <ross.zwisler@...ux.intel.com>,
	Dan Williams <dan.j.williams@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Matthew Wilcox <willy@...ux.intel.com>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	"linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
	Dave Chinner <david@...morbit.com>,
	Linux MM <linux-mm@...ck.org>
Subject: Re: [PATCH v2] dax: fix NULL pointer in __dax_pmd_fault()

On Tue, Sep 22, 2015 at 2:17 PM, Ross Zwisler
<ross.zwisler@...ux.intel.com> wrote:
> On Tue, Sep 22, 2015 at 01:51:04PM -0700, Dan Williams wrote:
>> [ adding Andrew ]
>>
>> On Tue, Sep 22, 2015 at 12:36 PM, Ross Zwisler
>> <ross.zwisler@...ux.intel.com> wrote:
>> > The following commit:
>> >
>> > commit 46c043ede471 ("mm: take i_mmap_lock in unmap_mapping_range() for
>> >         DAX")
>> >
>> > moved some code in __dax_pmd_fault() that was responsible for zeroing
>> > newly allocated PMD pages.  The new location didn't properly set up
>> > 'kaddr', though, so when run this code resulted in a NULL pointer BUG.
>> >
>> > Fix this by getting the correct 'kaddr' via bdev_direct_access().
>> >
>> > Signed-off-by: Ross Zwisler <ross.zwisler@...ux.intel.com>
>> > Reported-by: Dan Williams <dan.j.williams@...el.com>
>>
>> Taking into account the comment below,
>>
>> Reviewed-by: Dan Williams <dan.j.williams@...el.com>
>>
>> > ---
>> >  fs/dax.c | 13 ++++++++++++-
>> >  1 file changed, 12 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/fs/dax.c b/fs/dax.c
>> > index 7ae6df7..bcfb14b 100644
>> > --- a/fs/dax.c
>> > +++ b/fs/dax.c
>> > @@ -569,8 +569,20 @@ int __dax_pmd_fault(struct vm_area_struct *vma, unsigned long address,
>> >         if (!buffer_size_valid(&bh) || bh.b_size < PMD_SIZE)
>> >                 goto fallback;
>> >
>> > +       sector = bh.b_blocknr << (blkbits - 9);
>> > +
>> >         if (buffer_unwritten(&bh) || buffer_new(&bh)) {
>> >                 int i;
>> > +
>> > +               length = bdev_direct_access(bh.b_bdev, sector, &kaddr, &pfn,
>> > +                                               bh.b_size);
>> > +               if (length < 0) {
>> > +                       result = VM_FAULT_SIGBUS;
>> > +                       goto out;
>> > +               }
>> > +               if ((length < PMD_SIZE) || (pfn & PG_PMD_COLOUR))
>> > +                       goto fallback;
>> > +
>>
>> Hmm, we don't need the PG_PMD_COLOUR check since we aren't using the
>> pfn in this path, right?
>
> I think we care, because we'll end up bailing anyway at the later
> PG_PMD_COLOUR check before we actually insert the pfn via
> vmf_insert_pfn_pmd().  If we don't check the alignment we'll do 2 MiB worth of
> zeroing to the media, then later fall back to PTE faults.

Ok, good point.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/