From: David Laight <David.Laight@ACULAB.COM>
To: 'Breno Leitao' <leitao@debian.org>,
Sathya Prakash <sathya.prakash@broadcom.com>,
Sreekanth Reddy <sreekanth.reddy@broadcom.com>,
Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com>,
"James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Chaitra P B <chaitra.basappa@broadcom.com>
Cc: "leit@meta.com" <leit@meta.com>,
"stable@vger.kernel.org" <stable@vger.kernel.org>,
Keith Busch <kbusch@kernel.org>,
"open list:LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)"
<MPT-FusionLinux.pdl@broadcom.com>,
"open list:LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)"
<linux-scsi@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v2] mpt3sas: Avoid test/set_bit() operating in non-allocated memory
Date: Thu, 6 Jun 2024 08:47:11 +0000 [thread overview]
Message-ID: <f5bfddf9ec23402498df688e98f6bb29@AcuMS.aculab.com> (raw)
In-Reply-To: <20240605085530.499432-1-leitao@debian.org>
From: Breno Leitao <leitao@debian.org>
> Sent: 05 June 2024 09:55
>
> There is a potential out-of-bounds access when using test_bit() on a
> single word. The test_bit() and set_bit() functions operate on long
> values, and when testing or setting a single word, they can exceed the
> word boundary. KASAN detects this issue and produces a dump:
>
> BUG: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0
> (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/bitops/instrumented-atomic.h:29
> drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas
>
> Write of size 8 at addr ffff8881d26e3c60 by task kworker/u1536:2/2965
>
> For full log, please look at [1].
>
> Make the allocation at least the size of sizeof(unsigned long) so that
> set_bit() and test_bit() have sufficient room for read/write operations
> without overwriting unallocated memory.
>
...
> @@ -8512,6 +8512,12 @@ mpt3sas_base_attach(struct MPT3SAS_ADAPTER *ioc)
> ioc->pd_handles_sz = (ioc->facts.MaxDevHandle / 8);
> if (ioc->facts.MaxDevHandle % 8)
> ioc->pd_handles_sz++;
> + /* pd_handles_sz should have, at least, the minimal room
> + * for set_bit()/test_bit(), otherwise out-of-memory touch
> + * may occur
> + */
> + ioc->pd_handles_sz = ALIGN(ioc->pd_handles_sz, sizeof(unsigned long));
> +
> ioc->pd_handles = kzalloc(ioc->pd_handles_sz,
> GFP_KERNEL);
That is entirely stupid code.
IIRC there is a BITMAP_SIZE() that does ((x) + 63u) & ~63)/8
(on 64bit systems).
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
prev parent reply other threads:[~2024-06-06 8:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-05 8:55 [PATCH v2] mpt3sas: Avoid test/set_bit() operating in non-allocated memory Breno Leitao
2024-06-05 17:04 ` Keith Busch
2024-06-06 0:24 ` Martin K. Petersen
2024-06-06 8:47 ` David Laight [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f5bfddf9ec23402498df688e98f6bb29@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=MPT-FusionLinux.pdl@broadcom.com \
--cc=chaitra.basappa@broadcom.com \
--cc=kbusch@kernel.org \
--cc=leit@meta.com \
--cc=leitao@debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=sathya.prakash@broadcom.com \
--cc=sreekanth.reddy@broadcom.com \
--cc=stable@vger.kernel.org \
--cc=suganath-prabu.subramani@broadcom.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox