In the driver code for the MV‑based queue variant (struct hpt_iopmu_mv of the hptiop driver), the field "inbound_head" is read from the hardware register and used as an index into the array "inbound_q[MVIOP_QUEUE_LEN]". For example:
u32 inbound_head = readl(&hba->u.mv.mu->inbound_head); /* ... */ memcpy_toio(&hba->u.mv.mu->inbound_q[inbound_head], &p, 8);
The code then increments head and wraps it to zero when it equals MVIOP_QUEUE_LEN. However, the driver does *not* check that the initial value of "inbound_head" is strictly less than "MVIOP_QUEUE_LEN". If the hardware (or attacker‑controlled firmware/hardware device) writes a malicious value into the inbound_head register (which could be ≥ MVIOP_QUEUE_LEN), then subsequent "memcpy_toio" will write past the end of "inbound_q", leading to an out‑of‑bounds write condition.
Since inbound_q is allocated with exactly MVIOP_QUEUE_LEN entries (see:
__le64 inbound_q[MVIOP_QUEUE_LEN]; /* MVIOP_QUEUE_LEN == 512 */
), indexing at e.g. "inbound_head == 512" or greater results in undefined memory access and potential corruption of adjacent fields or memory regions.
This issue is particularly concerning in scenarios where an attacker has control or influence over the hardware/firmware on the adapter card (for example a malicious or compromised controller), because they could deliberately set "inbound_head" to a value outside the expected [0, MVIOP_QUEUE_LEN‑1] range, thus forcing the driver to write arbitrary data beyond the queue bounds.
To mitigate this issue, we add a check to validate the value of "inbound_head" before it is used as an index. If "inbound_head" is found to be out of bounds (≥ MVIOP_QUEUE_LEN), the head will be reset to 0, and "head" will be set to 1 to ensure that a valid entry is written to the queue. The resetting of "inbound_head" to 0 ensures that the queue processing can continue safely and predictably, while the adjustment of "head = 1" ensures that the next valid index is used for subsequent writes.
This prevents any out-of-bounds writes and ensures that the queue continues to operate safely even if the hardware is compromised.
Fixes: 00f5970193e22 ("[SCSI] hptiop: add more adapter models and other fixes") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li lgs201920130244@gmail.com --- drivers/scsi/hptiop.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/drivers/scsi/hptiop.c b/drivers/scsi/hptiop.c index c01370893a81..a1a3840e6ea8 100644 --- a/drivers/scsi/hptiop.c +++ b/drivers/scsi/hptiop.c @@ -166,6 +166,14 @@ static void mv_inbound_write(u64 p, struct hptiop_hba *hba) if (head == MVIOP_QUEUE_LEN) head = 0;
+ if (inbound_head >= MVIOP_QUEUE_LEN) { + dev_err(&hba->pdev->dev, + "hptiop: inbound_head out of range (%u)\n", + inbound_head); + inbound_head = 0; + head = 1; + } + memcpy_toio(&hba->u.mv.mu->inbound_q[inbound_head], &p, 8); writel(head, &hba->u.mv.mu->inbound_head); writel(MVIOP_MU_INBOUND_INT_POSTQUEUE,
Hi Guangshuo,
kernel test robot noticed the following build errors:
[auto build test ERROR on mkp-scsi/for-next] [also build test ERROR on jejb-scsi/for-next akpm-mm/mm-everything linus/master v6.18-rc7 next-20251124] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Guangshuo-Li/hptiop-Add-inbou... base: https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next patch link: https://lore.kernel.org/r/20251124145848.45687-1-lgs201920130244%40gmail.com patch subject: [PATCH] [SCSI] hptiop: Add inbound queue offset bounds check in iop_get_config_itl config: x86_64-kexec (https://download.01.org/0day-ci/archive/20251125/202511251457.AUHUgeyl-lkp@i...) compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251125/202511251457.AUHUgeyl-lkp@i...)
If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot lkp@intel.com | Closes: https://lore.kernel.org/oe-kbuild-all/202511251457.AUHUgeyl-lkp@intel.com/
All errors (new ones prefixed by >>):
drivers/scsi/hptiop.c:170:17: error: no member named 'pdev' in 'struct hptiop_hba'
170 | dev_err(&hba->pdev->dev, | ~~~ ^ include/linux/dev_printk.h:154:44: note: expanded from macro 'dev_err' 154 | dev_printk_index_wrap(_dev_err, KERN_ERR, dev, dev_fmt(fmt), ##__VA_ARGS__) | ^~~ include/linux/dev_printk.h:110:11: note: expanded from macro 'dev_printk_index_wrap' 110 | _p_func(dev, fmt, ##__VA_ARGS__); \ | ^~~ 1 error generated.
vim +170 drivers/scsi/hptiop.c
160 161 static void mv_inbound_write(u64 p, struct hptiop_hba *hba) 162 { 163 u32 inbound_head = readl(&hba->u.mv.mu->inbound_head); 164 u32 head = inbound_head + 1; 165 166 if (head == MVIOP_QUEUE_LEN) 167 head = 0; 168 169 if (inbound_head >= MVIOP_QUEUE_LEN) {
170 dev_err(&hba->pdev->dev,
171 "hptiop: inbound_head out of range (%u)\n", 172 inbound_head); 173 inbound_head = 0; 174 head = 1; 175 } 176 177 memcpy_toio(&hba->u.mv.mu->inbound_q[inbound_head], &p, 8); 178 writel(head, &hba->u.mv.mu->inbound_head); 179 writel(MVIOP_MU_INBOUND_INT_POSTQUEUE, 180 &hba->u.mv.regs->inbound_doorbell); 181 } 182
linux-stable-mirror@lists.linaro.org