lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 7 Dec 2015 11:29:41 -0600
From:	Bjorn Helgaas <helgaas@...nel.org>
To:	Babu Moger <babu.moger@...cle.com>
Cc:	bhelgaas@...gle.com, linux-pci@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4] pci: Limit VPD length for megaraid_sas adapter

Hi Babu,

On Thu, Dec 03, 2015 at 12:25:19PM -0800, Babu Moger wrote:
> Reading or Writing of PCI VPD data causes system panic.
> We saw this problem by running "lspci -vvv" in the beginning.
> However this can be easily reproduced by running
>  cat /sys/bus/devices/XX../vpd

What sort of panic is this?

This seems like a defect in the megaraid hardware or firmware.  If the
VPD ROM contains junk, there's no hope that software can read the data
and figure out how much is safe to read.

I assume VPD is useful for somebody, and I hate to silently disable
the whole thing.  We might want to at least log a note about what
we're doing.

Bjorn

> VPD length has been set as 32768 by default. Accessing vpd
> will trigger read/write of 32k. This causes problem as we
> could read data beyond the VPD end tag. Behaviour is un-
> predictable when this happens. I see some other adapter doing
> similar quirks(commit bffadffd43d4 ("PCI: fix VPD limit quirk
> for Broadcom 5708S"))
> 
> I see there is an attempt to fix this right way.
> https://patchwork.ozlabs.org/patch/534843/ or
> https://lkml.org/lkml/2015/10/23/97
> 
> Tried to fix it this way, but problem is I dont see the proper
> start/end TAGs(at least for this adapter) at all. The data is
> mostly junk or zeros. This patch fixes the issue by setting the
> vpd length to 0x80.
> 
> Signed-off-by: Babu Moger <babu.moger@...cle.com>
> Reviewed-by: Khalid Aziz <khalid.aziz@...cle.com>
> Tested-by: Dmitry Klochkov <dmitry.klochkov@...cle.com>
> 
> Orabug: 22104511
> 
> Changes since v3 -> v4
> We found some options of the lspci does not work very well if
> it cannot find the valid vpd tag(Example command "lspci -s 10:00.0 -vv").
> It displays the error message and exits right away. Setting the length
> back to 0 fixes the problem.
> 
> Changes since v2 -> v3
> Changed the vpd length from 0 to 0x80 which leaves the
> option open for someone to read first few bytes.
> 
> Changes since v1 -> v2
> Removed the changes in pci_id.h. Kept all the vendor
> ids in quirks.c
> ---
>  drivers/pci/quirks.c |   38 ++++++++++++++++++++++++++++++++++++++
>  1 files changed, 38 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index b03373f..f739e47 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -2123,6 +2123,44 @@ static void quirk_via_cx700_pci_parking_caching(struct pci_dev *dev)
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, 0x324e, quirk_via_cx700_pci_parking_caching);
>  
>  /*
> + * A read/write to sysfs entry ('/sys/bus/pci/devices/<id>/vpd')
> + * will dump 32k of data. The default length is set as 32768.
> + * Reading a full 32k will cause an access beyond the VPD end tag.
> + * The system behaviour at that point is mostly unpredictable.
> + * Also I dont believe vendors have implemented this VPD headers properly.
> + * Atleast I dont see it in following megaraid sas controller.
> + * That is why adding the quirk here.
> + */
> +static void quirk_megaraid_sas_limit_vpd(struct pci_dev *dev)
> +{
> +	if (dev->vpd)
> +		dev->vpd->len = 0;
> +}
> +
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0060,
> +		quirk_megaraid_sas_limit_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x007c,
> +		quirk_megaraid_sas_limit_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0413,
> +		quirk_megaraid_sas_limit_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0078,
> +		quirk_megaraid_sas_limit_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0079,
> +		quirk_megaraid_sas_limit_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0073,
> +		quirk_megaraid_sas_limit_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x0071,
> +		quirk_megaraid_sas_limit_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005b,
> +		quirk_megaraid_sas_limit_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x002f,
> +		quirk_megaraid_sas_limit_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005d,
> +		quirk_megaraid_sas_limit_vpd);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005f,
> +		quirk_megaraid_sas_limit_vpd);
> +
> +/*
>   * For Broadcom 5706, 5708, 5709 rev. A nics, any read beyond the
>   * VPD end tag will hang the device.  This problem was initially
>   * observed when a vpd entry was created in sysfs
> -- 
> 1.7.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ