From: axboe@kernel.dk (Jens Axboe)
Subject: [PATCH] nvme: fix out-of-bounds access during irq vectors allocation
Date: Wed, 16 Jan 2019 20:51:42 -0700 [thread overview]
Message-ID: <0a01d310-c949-af4e-edc0-44859fb277c5@kernel.dk> (raw)
In-Reply-To: <1547694610-31879-1-git-send-email-chenhc@lemote.com>
On 1/16/19 8:10 PM, Huacai Chen wrote:
> While reducing irq_queues in the do-while loop in nvme_setup_irqs(),
> the reduction of irq_sets[] is behind irq_queues. Below is an example.
>
> On a 8 cpu platform, with default setting, nvme_setup_irqs() begin with
> irq_queues = 8 (but when allocating irq vectors it will become 9 due to
> the admin queue), affd.pre_vectors = 1, affd.nr_sets = 1, affd.sets[0]
> = 8. If MSI-X resources are not enough, then the do-while loop will
> reduce irq vectors:
>
> The 1st time call pci_alloc_irq_vectors_affinity(),
> irq_queues = 9, affd.pre_vectors = 1, affd.nr_sets = 1, affd.sets[0] = 8
> The 2nd time call pci_alloc_irq_vectors_affinity(),
> irq_queues = 8, affd.pre_vectors = 1, affd.nr_sets = 1, affd.sets[0] = 8
> The 3rd time call pci_alloc_irq_vectors_affinity(),
> irq_queues = 7, affd.pre_vectors = 1, affd.nr_sets = 1, affd.sets[0] = 7
>
> However, this will cause an out of bounds access in __pci_enable_msix()
> --> ... --> irq_create_affinity_masks() --> irq_build_affinity_masks().
>
> In the 2nd round of reduction, let's pay attention to the calling of
> irq_build_affinity_masks(affd, curvec, this_vecs, curvec, node_to_cpumask, masks):
>
> The number of elements in masks is 8 (depends on nvecs which is equal to
> irq_queues), curvec is 1 (depends on affd.pre_vectors), then
> irq_build_affinity_masks() will access 8 elements in masks (depends on
> this_vecs which is equal to affd.sets[0]), and the last element is out
> of bounds.
>
> So the root cause is affd.sets[] + affd.pre_vectors should not be larger
> than vectors to be allocated. In this patch we introduce alloc_queues to
> indicate how many queues to allocate (not reuse irq_queues), and so we
> can adjust affd.set[] correctly (depends on irq_queues) to avoid out of
> bounds access.
>
> After this patch:
>
> The 1st time call pci_alloc_irq_vectors_affinity(),
> irq_queues = 8, alloc_queues = 9, affd.pre_vectors = 1, affd.nr_sets = 1, affd.sets[0] = 8
> The 2nd time call pci_alloc_irq_vectors_affinity(),
> irq_queues = 7, alloc_queues = 8, affd.pre_vectors = 1, affd.nr_sets = 1, affd.sets[0] = 7
> The 3rd time call pci_alloc_irq_vectors_affinity(),
> irq_queues = 6, alloc_queues = 7, affd.pre_vectors = 1, affd.nr_sets = 1, affd.sets[0] = 6
We currently have this one queued up:
http://git.kernel.dk/cgit/linux-block/commit/?h=for-linus&id=c45b1fa2433c65e44bdf48f513cb37289f3116b9
can you check if it fixes the issue for you?
--
Jens Axboe
next prev parent reply other threads:[~2019-01-17 3:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-17 3:10 [PATCH] nvme: fix out-of-bounds access during irq vectors allocation Huacai Chen
2019-01-17 3:51 ` Jens Axboe [this message]
2019-01-17 3:57 ` Jens Axboe
2019-01-17 15:22 ` Keith Busch
2019-01-17 15:24 ` Jens Axboe
2019-01-18 1:48 ` Huacai Chen
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=0a01d310-c949-af4e-edc0-44859fb277c5@kernel.dk \
--to=axboe@kernel.dk \
/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