Re: [PATCH] scsi: megaraid_sas: fix PRP list out-of-bounds write

On 7/1/26 2:24 PM, Thorsten Leemhuis wrote:
> On 7/1/26 13:09, Mira Limbeck wrote:
>> We've seen some similar looking logs, but since they didn't mention
>> `prp` at all, we haven't responded here before.
> 
> Thx for chiming in here.
> 
>> Instead we sent a mail
>> to the linux-scsi list [0], but got no response so far.
>>
>> In our case the issue was first introduced by commit:
>> 9b8b84879d4a ("block: Increase BLK_DEF_MAX_SECTORS_CAP")
> 
> Any reason why you didn't CC the author and the committer of that
> change? Even if the bug is in the driver that might have been a good
> idea, but before doing that, let's do something else first:
> 
>> This is similar to an issue we previously reported with the mpt3sas
>> driver [1].
>>
>> At least for our tests and one of our users we can say with certainty
>> that reducing the queue sectors back to the previous value fixed the
>> issue. In our tests this was done manually, and for one of our users
>> with their root on the disks, it was handled via udev rules.
>>
>> echo 1280 > /sys/block/<dev>/queue/max_sectors_kb
> You also in your [0] mentioned that 12da89e8844a ("block: open code
> bio_add_page and fix handling of mismatching P2P ranges") fixed things
> in v7.0. Make me wonder if that is the case for the others affected by
> this. Hence:
> 
> Lukasz, Mats, Daniel, have you checked if 7.1 or 7.2-rc2 are still affected?
> 
> Ciao, Thorsten
Actually, this only helped in our test cases. Some of our users that
were affected with kernel 6.17 had no issues with kernel 7.0, while
others still experience those issues.
So those 2 patches only fixed the issues for a subset of users.

Originally we thought that it fixes the issue for those using KIOXIA
NVMes, while those with Microns were still affected. But since then we
had additional reports where users with KIOXIA NVMes also still
experienced issues with kernel 7.0.
This we only found out last week though.

We're still in the process of finding a reproducer that isn't fixed by
that change.

> 
>> [0]
>> https://lore.kernel.org/all/[email protected]/
>> [1]
>> https://lore.kernel.org/all/[email protected]/
>