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

[Damien Le Moal <dlemoal@kernel.org>]

On 7/28/26 22:43, Mats Topstad / Intility AS wrote:
> Hi all,
> 
> Adding a data point from an HPE ProLiant DL360 Gen11 with the MR408i-o Gen11
> controller (megaraid_sas), 960 GB SAS SSDs presented as sd*, running kernel
> 6.18.32 (Talos Linux v1.12.8). Without a cap the node panics within seconds of
> sustained block I/O to the controller, with the same megasas_make_prp_nvme
> signature discussed in this thread.
> 
> Capping max_sectors_kb=1280 on the sd* devices resolves it on this controller
> by itself. I pushed roughly 85 GB of dd bs=4M oflag=direct through it, so every
> request is split at the 1280 KB boundary, with zero panics, where the uncapped
> case dies almost immediately. On the MR416i-o you found the cap necessary but
> not sufficient because of a second problem in the SG advance path. I did not
> reach that second failure on the MR408i-o; the cap alone was enough here.
> 
> Both of our worker nodes have now run on kernel 6.18 throughout this testing
> with the cap applied by a udev rule at device add:
> 
>   ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="sd[a-z]", DRIVERS=="megaraid_sas", ATTR{queue/max_sectors_kb}="1280"
> 
> This lines up with Martin's suggestion to cap max_hw_sectors on the driver side
> for NVMe behind MR. If a driver side patch would help, I am happy to build and
> test it on this exact hardware and report back, and I can provide a full dmesg
> or a serial panic capture from the uncapped case if that is useful.

This looks about the same problem as what commit 04631f55afc5 ("scsi: mpt3sas:
Limit NVMe request size to 2 MiB") fixes.

I strongly suspect that all Broadcom drivers (mpi3mr and megaraid) all need a
similar fix.

-- 
Damien Le Moal
Western Digital Research