From: Tony Nguyen <anthony.l.nguyen@intel.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [PATCH S44 12/14] ice: fix potential double free in probe unrolling
Date: Fri, 15 May 2020 17:42:24 -0700 [thread overview]
Message-ID: <20200516004226.4795-12-anthony.l.nguyen@intel.com> (raw)
In-Reply-To: <20200516004226.4795-1-anthony.l.nguyen@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
If ice_init_interrupt_scheme fails, ice_probe will jump to clearing up
the interrupts. This can lead to some static analysis tools such as the
compiler sanitizers complaining about double free problems.
Since ice_init_interrupt_scheme already unrolls internally on failure,
there is no need to call ice_clear_interrupt_scheme when it fails. Add
a new unroll label and use that instead.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
---
drivers/net/ethernet/intel/ice/ice_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index 1853dca3f364..943fde5abdb7 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -3443,7 +3443,7 @@ ice_probe(struct pci_dev *pdev, const struct pci_device_id __always_unused *ent)
if (err) {
dev_err(dev, "ice_init_interrupt_scheme failed: %d\n", err);
err = -EIO;
- goto err_init_interrupt_unroll;
+ goto err_init_vsi_unroll;
}
/* In case of MSIX we are going to setup the misc vector right here
@@ -3564,6 +3564,7 @@ ice_probe(struct pci_dev *pdev, const struct pci_device_id __always_unused *ent)
ice_free_irq_msix_misc(pf);
err_init_interrupt_unroll:
ice_clear_interrupt_scheme(pf);
+err_init_vsi_unroll:
devm_kfree(dev, pf->vsi);
err_init_pf_unroll:
ice_deinit_pf(pf);
--
2.20.1
next prev parent reply other threads:[~2020-05-16 0:42 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-16 0:42 [Intel-wired-lan] [PATCH S44 01/14] ice: Don't allow VLAN stripping change when pvid set Tony Nguyen
2020-05-16 0:42 ` [Intel-wired-lan] [PATCH S44 02/14] ice: Handle critical FW error during admin queue initialization Tony Nguyen
2020-05-26 20:22 ` Bowers, AndrewX
2020-05-16 0:42 ` [Intel-wired-lan] [PATCH S44 03/14] ice: Change number of XDP TxQ to 0 when destroying rings Tony Nguyen
2020-05-26 20:23 ` Bowers, AndrewX
2020-05-16 0:42 ` [Intel-wired-lan] [PATCH S44 04/14] ice: Add XDP Tx to VSI ring stats Tony Nguyen
2020-05-26 20:23 ` Bowers, AndrewX
2020-05-16 0:42 ` [Intel-wired-lan] [PATCH S44 05/14] ice: Change number of XDP Tx queues to match number of Rx queues Tony Nguyen
2020-05-26 20:24 ` Bowers, AndrewX
2020-05-16 0:42 ` [Intel-wired-lan] [PATCH S44 06/14] ice: avoid undefined behavior Tony Nguyen
2020-05-26 20:24 ` Bowers, AndrewX
2020-05-16 0:42 ` [Intel-wired-lan] [PATCH S44 07/14] ice: Refactor Rx checksum checks Tony Nguyen
2020-05-26 20:24 ` Bowers, AndrewX
2020-05-16 0:42 ` [Intel-wired-lan] [PATCH S44 08/14] ice: Check UMEM FQ size when allocating bufs Tony Nguyen
2020-05-26 20:25 ` Bowers, AndrewX
2020-05-16 0:42 ` [Intel-wired-lan] [PATCH S44 09/14] ice: Refactor ice_setup_rx_ctx Tony Nguyen
2020-05-26 20:25 ` Bowers, AndrewX
2020-05-16 0:42 ` [Intel-wired-lan] [PATCH S44 10/14] ice: Poll for reset completion when DDP load fails Tony Nguyen
2020-05-26 20:25 ` Bowers, AndrewX
2020-05-16 0:42 ` [Intel-wired-lan] [PATCH S44 11/14] ice: cleanup VSI context initialization Tony Nguyen
2020-05-26 20:26 ` Bowers, AndrewX
2020-05-16 0:42 ` Tony Nguyen [this message]
2020-05-26 20:26 ` [Intel-wired-lan] [PATCH S44 12/14] ice: fix potential double free in probe unrolling Bowers, AndrewX
2020-05-16 0:42 ` [Intel-wired-lan] [PATCH S44 13/14] ice: fix kernel BUG if register_netdev fails Tony Nguyen
2020-05-26 20:26 ` Bowers, AndrewX
2020-05-16 0:42 ` [Intel-wired-lan] [PATCH S44 14/14] ice: Declare functions static Tony Nguyen
2020-05-26 20:26 ` Bowers, AndrewX
2020-05-26 20:22 ` [Intel-wired-lan] [PATCH S44 01/14] ice: Don't allow VLAN stripping change when pvid set Bowers, AndrewX
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=20200516004226.4795-12-anthony.l.nguyen@intel.com \
--to=anthony.l.nguyen@intel.com \
--cc=intel-wired-lan@osuosl.org \
/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