mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH v2] PCI: Reject negative resource alignment order
@ 2026-11-09 10:55 shao.mingyin
  2026-11-09 13:16 ` Ilpo Järvinen
  0 siblings, 1 reply; 2+ messages in thread
From: shao.mingyin @ 2026-11-09 10:55 UTC (permalink / raw)
  To: bhelgaas, linux-pci; +Cc: ilpo.jarvinen, linux-kernel

From: Shao Mingyin <shao.mingyin@zte.com.cn>

pci_specified_resource_alignment() parses the pci=resource_alignment=
boot parameter and rejects only orders above 63.  A negative order, such
as "pci=resource_alignment=-5@...", passes that check and later reaches
"align = 1ULL << align_order" with a negative shift count, which is
undefined behavior; on x86 the 64-bit shift count is masked to six bits,
silently producing a 2^59-byte alignment that mis-aligns (or fails to
align) the affected IOV resources.

align_order is a bit order, so parse it with %u.  vsscanf() does not
accept a sign for %u, so a negative order no longer converts: the
parameter is reported as invalid and no alignment is applied.  Orders
above 63 are still rejected and fall back to the page-size alignment.

Fixes: 6534aac198b5 ("PCI: Bounds-check command-line resource alignment requests")
Cc: stable@vger.kernel.org
Signed-off-by: Shao Mingyin <shao.mingyin@zte.com.cn>
---
This supersedes 1/5 of the v1 series; 2/5-5/5 are unchanged.

v2:
  - parse the order with %u instead of %d, as Ilpo Järvinen suggested; a
    bit order is unsigned, and this also removes the explicit < 0 test
    added by v1
  - pr_err() prints the order with %u as well
  - note the resulting behaviour: vsscanf() does not accept a sign for
    %u, so a negative order fails to parse instead of being clamped
v1: https://lore.kernel.org/all/20261107002311316z2o2PFtFGoXh-VbqXtTGg@zte.com.cn/

Tested on 7.3.0-next-20261030 (QEMU/TCG guest) with the
pci=resource_alignment= boot parameter and a QEMU e1000 NIC; no extra
hardware is needed.

Booting with pci=resource_alignment=-5@pci:8086:100e, the unpatched
kernel parses -5 and "align = 1ULL << align_order" shifts by -5 (masked
to 2^59 on x86-64); the e1000 BAR is resized to 2^59 bytes, which cannot
be assigned, and the e1000 fails to probe.  With this patch "-5" does not
convert and the parameter is rejected:

  unpatched                            patched
  requesting alignment to              PCI: Can't parse resource_alignment
  0x800000000000000                    parameter: -5@pci:8086:100e
  e1000 probe failed, no eth0          e1000 eth0 probes

 drivers/pci/pci.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index bca3a5d84cd9..e3f701ff9881 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -6585,7 +6585,8 @@ static DEFINE_SPINLOCK(resource_alignment_lock);
 static resource_size_t pci_specified_resource_alignment(struct pci_dev *dev,
 							bool *resize)
 {
-	int align_order, count;
+	unsigned int align_order;
+	int count;
 	resource_size_t align = pcibios_default_alignment();
 	const char *p;
 	int ret;
@@ -6602,11 +6603,11 @@ static resource_size_t pci_specified_resource_alignment(struct pci_dev *dev,
 
 	while (*p) {
 		count = 0;
-		if (sscanf(p, "%d%n", &align_order, &count) == 1 &&
+		if (sscanf(p, "%u%n", &align_order, &count) == 1 &&
 		    p[count] == '@') {
 			p += count + 1;
 			if (align_order > 63) {
-				pr_err("PCI: Invalid requested alignment (order %d)\n",
+				pr_err("PCI: Invalid requested alignment (order %u)\n",
 				       align_order);
 				align_order = PAGE_SHIFT;
 			}

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH v2] PCI: Reject negative resource alignment order
  2026-11-09 10:55 [PATCH v2] PCI: Reject negative resource alignment order shao.mingyin
@ 2026-11-09 13:16 ` Ilpo Järvinen
  0 siblings, 0 replies; 2+ messages in thread
From: Ilpo Järvinen @ 2026-11-09 13:16 UTC (permalink / raw)
  To: shao.mingyin; +Cc: bhelgaas, linux-pci, ilpo.jarvinen, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 3635 bytes --]

On Mon, 9 Nov 2026, shao.mingyin@zte.com.cn wrote:

> From: Shao Mingyin <shao.mingyin@zte.com.cn>
> 
> pci_specified_resource_alignment() parses the pci=resource_alignment=
> boot parameter and rejects only orders above 63.  A negative order, such
> as "pci=resource_alignment=-5@...", passes that check and later reaches
> "align = 1ULL << align_order" with a negative shift count, which is
> undefined behavior; on x86 the 64-bit shift count is masked to six bits,
> silently producing a 2^59-byte alignment that mis-aligns (or fails to
> align) the affected IOV resources.
> 
> align_order is a bit order, so parse it with %u.  vsscanf() does not
> accept a sign for %u, so a negative order no longer converts: the
> parameter is reported as invalid and no alignment is applied.  Orders
> above 63 are still rejected and fall back to the page-size alignment.
> 
> Fixes: 6534aac198b5 ("PCI: Bounds-check command-line resource alignment requests")
> Cc: stable@vger.kernel.org
> Signed-off-by: Shao Mingyin <shao.mingyin@zte.com.cn>
> ---
> This supersedes 1/5 of the v1 series; 2/5-5/5 are unchanged.
> 
> v2:
>   - parse the order with %u instead of %d, as Ilpo Järvinen suggested; a
>     bit order is unsigned, and this also removes the explicit < 0 test
>     added by v1
>   - pr_err() prints the order with %u as well
>   - note the resulting behaviour: vsscanf() does not accept a sign for
>     %u, so a negative order fails to parse instead of being clamped
> v1: https://lore.kernel.org/all/20261107002311316z2o2PFtFGoXh-VbqXtTGg@zte.com.cn/
> 
> Tested on 7.3.0-next-20261030 (QEMU/TCG guest) with the
> pci=resource_alignment= boot parameter and a QEMU e1000 NIC; no extra
> hardware is needed.
> 
> Booting with pci=resource_alignment=-5@pci:8086:100e, the unpatched
> kernel parses -5 and "align = 1ULL << align_order" shifts by -5 (masked
> to 2^59 on x86-64); the e1000 BAR is resized to 2^59 bytes, which cannot
> be assigned, and the e1000 fails to probe.  With this patch "-5" does not
> convert and the parameter is rejected:
> 
>   unpatched                            patched
>   requesting alignment to              PCI: Can't parse resource_alignment
>   0x800000000000000                    parameter: -5@pci:8086:100e
>   e1000 probe failed, no eth0          e1000 eth0 probes
> 
>  drivers/pci/pci.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index bca3a5d84cd9..e3f701ff9881 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -6585,7 +6585,8 @@ static DEFINE_SPINLOCK(resource_alignment_lock);
>  static resource_size_t pci_specified_resource_alignment(struct pci_dev *dev,
>  							bool *resize)
>  {
> -	int align_order, count;
> +	unsigned int align_order;
> +	int count;
>  	resource_size_t align = pcibios_default_alignment();
>  	const char *p;
>  	int ret;

I'd have preferred having count and ret on the same line.

Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>

--
 i.

> @@ -6602,11 +6603,11 @@ static resource_size_t pci_specified_resource_alignment(struct pci_dev *dev,
>  
>  	while (*p) {
>  		count = 0;
> -		if (sscanf(p, "%d%n", &align_order, &count) == 1 &&
> +		if (sscanf(p, "%u%n", &align_order, &count) == 1 &&
>  		    p[count] == '@') {
>  			p += count + 1;
>  			if (align_order > 63) {
> -				pr_err("PCI: Invalid requested alignment (order %d)\n",
> +				pr_err("PCI: Invalid requested alignment (order %u)\n",
>  				       align_order);
>  				align_order = PAGE_SHIFT;
>  			}
> 

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2026-11-09 13:16 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-11-09 10:55 [PATCH v2] PCI: Reject negative resource alignment order shao.mingyin
2026-11-09 13:16 ` Ilpo Järvinen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®