linux-kernel - Re: [PATCH] iommu/vt-d: Fix shift overflow in qi_flush_dev

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171213101518.7807ae4b@t450s.home>
Date:   Wed, 13 Dec 2017 10:15:18 -0700
From:   Alex Williamson <alex.williamson@...hat.com>
To:     "Hook, Gary" <ghook@....com>
Cc:     Peter Xu <peterx@...hat.com>, iommu@...ts.linux-foundation.org,
        dwmw2@...radead.org, linux-kernel@...r.kernel.org,
        tursulin@...ulin.net
Subject: Re: [PATCH] iommu/vt-d: Fix shift overflow in qi_flush_dev_iotlb

On Wed, 13 Dec 2017 10:41:47 -0600
"Hook, Gary" <ghook@....com> wrote:

> On 12/13/2017 9:58 AM, Alex Williamson wrote:
> > On Wed, 13 Dec 2017 15:13:55 +0800
> > Peter Xu <peterx@...hat.com> wrote:
> >   
> >> On Tue, Dec 12, 2017 at 03:43:08PM -0700, Alex Williamson wrote:
> >>
> >> [...]
> >>  
> >>> diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
> >>> index 9a7ffd13c7f0..87888b102057 100644
> >>> --- a/drivers/iommu/dmar.c
> >>> +++ b/drivers/iommu/dmar.c
> >>> @@ -1345,7 +1345,9 @@ void qi_flush_dev_iotlb(struct intel_iommu *iommu, u16 sid, u16 qdep,
> >>>   	struct qi_desc desc;
> >>>   
> >>>   	if (mask) {
> >>> -		BUG_ON(addr & ((1 << (VTD_PAGE_SHIFT + mask)) - 1));
> >>> +		BUG_ON((mask > MAX_AGAW_PFN_WIDTH) ||
> >>> +		       ((mask == MAX_AGAW_PFN_WIDTH) && addr) ||
> >>> +		       (addr & ((1 << (VTD_PAGE_SHIFT + mask)) - 1)));  
> >>
> >> Could it work if we just use 1ULL instead of 1 here?  Thanks,  
> > 
> > In either case we're talking about shifting off the end of the
> > variable, which I understand to be undefined.  Right?  Thanks,  
> 
> How so? Bits fall off the left (MSB) end, zeroes fill in the right (LSB) 
> end. I believe that behavior is pretty set.

Maybe I'm relying too much on stackoverflow, but:

https://stackoverflow.com/questions/11270492/what-does-the-c-standard-say-about-bitshifting-more-bits-than-the-width-of-type

Thanks,
Alex