netdev - RE: [net-qed] question about potential null pointer dereference

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] [day] [month] [year] [list]

Message-ID: <BLUPR0701MB20042E7C15ACCCA7160AF60A8DF10@BLUPR0701MB2004.namprd07.prod.outlook.com>
Date:   Wed, 31 May 2017 17:51:11 +0000
From:   "Mintz, Yuval" <Yuval.Mintz@...ium.com>
To:     "Gustavo A. R. Silva" <garsilva@...eddedor.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [net-qed] question about potential null pointer dereference

> While looking into Coverity ID 1362293 I ran into the following piece of code
> at drivers/net/ethernet/qlogic/qed/qed_sriov.c:3863:
> 
> 3863static int
> 3864qed_iov_configure_min_tx_rate(struct qed_dev *cdev, int vfid, u32 rate)
> 3865{
> 3866        struct qed_vf_info *vf;
> 3867        u8 vport_id;
> 3868        int i;
> 3869
> 3870        for_each_hwfn(cdev, i) {
> 3871                struct qed_hwfn *p_hwfn = &cdev->hwfns[i];
> 3872
> 3873                if (!qed_iov_pf_sanity_check(p_hwfn, vfid)) {
> 3874                        DP_NOTICE(p_hwfn,
> 3875                                  "SR-IOV sanity check failed,
> can't set min rate\n");
> 3876                        return -EINVAL;
> 3877                }
> 3878        }
> 3879
> 3880        vf = qed_iov_get_vf_info(QED_LEADING_HWFN(cdev), (u16)vfid,
> true);

Unless I'm missing something, this sounds like a false-positive from coverity.
The validation of qed_iov_pf_sanity_check() should be sufficient for qed_iov_get_vf_info()
to always return a valid value, and there's no scenario where we'd reach this
part of the code if the hw-functions aren't initialized; so we're bound to enter the loop.