netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: 梁文韬 <wentao_liang_g@163.com>
Cc: jdmason@kudzu.us, davem@davemloft.net, edumazet@google.com,
	pabeni@redhat.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [PATCH net v2]vexy: Fix a use-after-free bug in vxge-main.c
Date: Thu, 16 Jun 2022 08:50:59 -0700	[thread overview]
Message-ID: <20220616085059.680dc215@kernel.org> (raw)
In-Reply-To: <1f10f9f8.6c02.1816cb0dc51.Coremail.wentao_liang_g@163.com>

On Thu, 16 Jun 2022 21:25:39 +0800 (CST) 梁文韬 wrote:
> >The driver is not called "vexy" as far as I can tell.
> >  
> >> The pointer vdev points to a memory region adjacent to a net_device
> >> structure ndev, which is a field of hldev. At line 4740, the invocation
> >> to vxge_device_unregister unregisters device hldev, and it also releases
> >> the memory region pointed by vdev->bar0. At line 4743, the freed memory
> >> region is referenced (i.e., iounmap(vdev->bar0)), resulting in a
> >> use-after-free vulnerability. We can fix the bug by calling iounmap
> >> before vxge_device_unregister.  
> >
> >Are you sure the bar0 is not needed by the netdev? You're freeing  
> >memory that the netdev may need until it's unregistered.  

> We try unregister the device in a patched kernel. The device is successfully
>  removed and there is not any warning or exception. See the following 
> snapshot. I use lspci to list pci devices, we can see that the device 
> (00:03.0 Unclassified ...Gigabit ethernet PCIe (rev 10)) is removed safely. 
> Thus, I believe that the bar0 is not needed when freeing the device.

You need to reply in plain text, no HTML, the mailing lit rejects
emails with HTML in them.

No errors happening during a test is not a sufficient proof of
correctness. You need to analyze the driver and figure out what bar0 
is used for.

Alternatively just save the address of bar0 to a local variable, let
the netdev unregister happen, and then call *unmap() on the local
variable. That won't move the unmap and avoid the UAF.

But please LMK how you use these cards first.

> /********************************************************************************/
> root@kernel:~# lspci
> 00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM 
> Controller
> 00:01.0 VGA compatible controller: Device 1234:1111 (rev 02)
> 00:02.0 Ethernet controller: Intel Corporation 82574L Gigabit Network 
> Connection
> 00:03.0 Unclassified device [00ff]: Exar Corp. X3100 Series 10 Gigabit 
> Ethernet PCIe (rev 10)

Is this a real NIC card, or just a emulated / virtualized one? 
Do you use it day to day? 

> 00:1d.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
> Controller #1 (rev 03)
> 00:1d.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
> Controller #2 (rev 03)
> 00:1d.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
> Controller #3 (rev 03)
> 00:1d.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI 
> Controller #1 (rev 03)
> 00:1f.0 ISA bridge: Intel Corporation 82801IB (ICH9) LPC Interface 
> Controller (rev 02)
> 00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6
>  port SATA Controller [AHCI mode] (rev 02)
> 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller 
> (rev 02)
> root@kernel:~# echo 1 > /sys/bus/pci/devices/0000:00:03.0/remove
> root@kernel:~# lspci
> 00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM
>  Controller
> 00:01.0 VGA compatible controller: Device 1234:1111 (rev 02)
> 00:02.0 Ethernet controller: Intel Corporation 82574L Gigabit Network
>  Connection
> 00:1d.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
>  Controller #1 (rev 03)
> 00:1d.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
>  Controller #2 (rev 03)
> 00:1d.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
>  Controller #3 (rev 03)
> 00:1d.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI
>  Controller #1 (rev 03)
> 00:1f.0 ISA bridge: Intel Corporation 82801IB (ICH9) LPC Interface 
> Controller (rev 02)
> 00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 
> port SATA Controller [AHCI mode] (rev 02)
> 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus 
> Controller (rev 02)

  parent reply	other threads:[~2022-06-16 15:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-15  1:38 [PATCH] [PATCH net v2]vexy: Fix a use-after-free bug in vxge-main.c Wentao_Liang
2022-06-16  2:50 ` Jakub Kicinski
     [not found]   ` <1f10f9f8.6c02.1816cb0dc51.Coremail.wentao_liang_g@163.com>
2022-06-16 15:50     ` Jakub Kicinski [this message]
2022-06-20 14:40   ` Jon Mason
2022-06-20 15:02     ` Jakub Kicinski

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=20220616085059.680dc215@kernel.org \
    --to=kuba@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=jdmason@kudzu.us \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=wentao_liang_g@163.com \
    /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;
as well as URLs for NNTP newsgroup(s).