[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <142a177f-4e3b-473b-871a-2e929240efef@oracle.com>
Date: Mon, 13 Jan 2025 16:25:29 +0000
From: Joao Martins <joao.m.martins@...cle.com>
To: Jason Gunthorpe <jgg@...pe.ca>
Cc: Qasim Ijaz <qasdev00@...il.com>, iommu@...ts.linux.dev,
linux-kernel@...r.kernel.org, Kevin Tian <kevin.tian@...el.com>,
Joerg Roedel <joro@...tes.org>, Will Deacon <will@...nel.org>,
Robin Murphy <robin.murphy@....com>
Subject: Re: [PATCH] iommu: Fix shift-out-of-bounds in
iova_bitmap_offset_to_index()
On 13/01/2025 16:22, Jason Gunthorpe wrote:
> On Mon, Jan 13, 2025 at 12:00:29PM +0000, Joao Martins wrote:
>> On 12/01/2025 12:39, Qasim Ijaz wrote:
>>> This patch resolves a UBSAN shift-out-of-bounds issue in
>>
>> Avoid the 'this patch' e.g. Resolve a UBSAN shift-out-of-bonds (...)
>>
>> The Subject component part could also be a bit more specific e.g.
>>
>> iommufd/iova_bitmap: Fix shift-out-of-bounds in iova_bitmap_offset_to_index()
>>
>>> iova_bitmap_offset_to_index() where shifting the constant "1" (of type int)
>>> by bitmap->mapped.pgshift (an unsigned long value) could result in undefined behavior.
>>>
>>> The constant "1" defaults to a 32-bit "int", and when "pgshift" exceeds 31 (e.g., pgshift = 63)
>>> the shift operation overflows, as the result cannot be represented in a 32-bit type.
>>>
>>> To resolve this, the constant is updated to "1UL", promoting it to an unsigned long type
>>> to match the operand's type.
>>>
>>> Reported-by: syzbot <syzbot+85992ace37d5b7b51635@...kaller.appspotmail.com>
>>> Closes: https://syzkaller.appspot.com/bug?extid=85992ace37d5b7b51635
>>> Signed-off-by: Qasim Ijaz <qasdev00@...il.com>
>>
>> With those two nits:
>>
>> Reviewed-by: Joao Martins <joao.m.martins@...cle.com>
>
> It needs a fixes line too
It should be
Fixes: 495c06d82ba ("vfio: Add an IOVA bitmap support")
Joao
Powered by blists - more mailing lists