[PATCH v1 1/2] hamradio: defer ax25 kfree after unregister_netdev

There is a possible race condition (use-after-free) like below

 (USE)                       |  (FREE)
ax25_sendmsg                 |
 ax25_queue_xmit             |
  dev_queue_xmit             |
   __dev_queue_xmit          |
    __dev_xmit_skb           |
     sch_direct_xmit         | ...
      xmit_one               |
       netdev_start_xmit     | tty_ldisc_kill
        __netdev_start_xmit  |  mkiss_close
         ax_xmit             |   kfree
          ax_encaps          |
                             |

Even though there are two synchronization primitives before the kfree:
1. wait_for_completion(&ax->dead). This can prevent the race with
routines from mkiss_ioctl. However, it cannot stop the routine coming
from upper layer, i.e., the ax25_sendmsg.

2. netif_stop_queue(ax->dev). It seems that this line of code aims to
halt the transmit queue but it fails to stop the routine that already
being xmit.

This patch reorder the kfree after the unregister_netdev to avoid the
possible UAF as the unregister_netdev() is well synchronized and won't
return if there is a running routine.

Signed-off-by: Lin Ma <redacted>
---
 drivers/net/hamradio/mkiss.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/net/hamradio/mkiss.c b/drivers/net/hamradio/mkiss.c
index 867252a0247b..e2b332b54f06 100644
--- a/drivers/net/hamradio/mkiss.c
+++ b/drivers/net/hamradio/mkiss.c

@@ -792,13 +792,14 @@ static void mkiss_close(struct tty_struct *tty)
 	 */
 	netif_stop_queue(ax->dev);
 
-	/* Free all AX25 frame buffers. */
-	kfree(ax->rbuff);
-	kfree(ax->xbuff);
-
 	ax->tty = NULL;
 
 	unregister_netdev(ax->dev);
+
+	/* Free all AX25 frame buffers after unreg. */
+	kfree(ax->rbuff);
+	kfree(ax->xbuff);
+
 	free_netdev(ax->dev);
 }
 

-- 
2.33.1

There is a possible race condition (use-after-free) like below

 (USE)                       |  (FREE)
  dev_queue_xmit             |
   __dev_queue_xmit          |
    __dev_xmit_skb           |
     sch_direct_xmit         | ...
      xmit_one               |
       netdev_start_xmit     | tty_ldisc_kill
        __netdev_start_xmit  |  6pack_close
         sp_xmit             |   kfree
          sp_encaps          |
                             |

According to the patch "defer ax25 kfree after unregister_netdev", this
patch reorder the kfree after the unregister_netdev to avoid the possible
UAF as the unregister_netdev() is well synchronized and won't return if
there is a running routine.

Signed-off-by: Lin Ma <redacted>
---
 drivers/net/hamradio/6pack.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/hamradio/6pack.c b/drivers/net/hamradio/6pack.c
index 49f10053a794..bfdf89e54752 100644
--- a/drivers/net/hamradio/6pack.c
+++ b/drivers/net/hamradio/6pack.c

@@ -672,11 +672,13 @@ static void sixpack_close(struct tty_struct *tty)
 	del_timer_sync(&sp->tx_t);
 	del_timer_sync(&sp->resync_t);
 
-	/* Free all 6pack frame buffers. */
+	unregister_netdev(sp->dev);
+
+	/* Free all 6pack frame buffers after unreg. */
 	kfree(sp->rbuff);
 	kfree(sp->xbuff);
 
-	unregister_netdev(sp->dev);
+	free_netdev(sp->dev);
 }
 
 /* Perform I/O control on an active 6pack channel. */

-- 
2.33.1

On Mon,  8 Nov 2021 18:37:59 +0800 Lin Ma wrote:

There is a possible race condition (use-after-free) like below

 (USE)                       |  (FREE)
  dev_queue_xmit             |
   __dev_queue_xmit          |
    __dev_xmit_skb           |
     sch_direct_xmit         | ...
      xmit_one               |
       netdev_start_xmit     | tty_ldisc_kill
        __netdev_start_xmit  |  6pack_close
         sp_xmit             |   kfree
          sp_encaps          |
                             |

According to the patch "defer ax25 kfree after unregister_netdev", this

This is the previous patch of the series? Maybe call it "previous
patch"?

patch reorder the kfree after the unregister_netdev to avoid the possible
UAF as the unregister_netdev() is well synchronized and won't return if
there is a running routine.

Signed-off-by: Lin Ma <redacted>

You should mention in the commit message why you think it's safe to add
free_netdev() which wasn't here before...

This driver seems to be setting:

	dev->needs_free_netdev	= true;

so unregister_netdev() will free the netdev automatically.

That said I don't see a reason why this driver needs the automatic
cleanup.

You can either remove that setting and then you can call free_netdev()
like you do, or you need to move the cleanup to dev->priv_destructor.

 }
 
 /* Perform I/O control on an active 6pack channel. */

On Wed, 10 Nov 2021 18:05:25 -0800 Jakub Kicinski wrote:

quoted

diff --git a/drivers/net/hamradio/6pack.c b/drivers/net/hamradio/6pack.c
index 49f10053a794..bfdf89e54752 100644
--- a/drivers/net/hamradio/6pack.c
+++ b/drivers/net/hamradio/6pack.c

@@ -672,11 +672,13 @@ static void sixpack_close(struct tty_struct *tty)
 	del_timer_sync(&sp->tx_t);
 	del_timer_sync(&sp->resync_t);
 
-	/* Free all 6pack frame buffers. */
+	unregister_netdev(sp->dev);
+
+	/* Free all 6pack frame buffers after unreg. */
 	kfree(sp->rbuff);
 	kfree(sp->xbuff);
 
-	unregister_netdev(sp->dev);
+	free_netdev(sp->dev);  

You should mention in the commit message why you think it's safe to add
free_netdev() which wasn't here before...

This driver seems to be setting:

	dev->needs_free_netdev	= true;

so unregister_netdev() will free the netdev automatically.

That said I don't see a reason why this driver needs the automatic
cleanup.

You can either remove that setting and then you can call free_netdev()
like you do, or you need to move the cleanup to dev->priv_destructor.

Looks like this go applied already, please send a follow up fix.

Hi there,

Sent Time: 2021-11-11 10:06:12 (Thursday)
To: "Lin Ma" <redacted>
Cc: netdev@vger.kernel.org, davem@davemloft.net, jirislaby@kernel.org, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 2/2] hamradio: defer 6pack kfree after unregister_netdev

On Wed, 10 Nov 2021 18:05:25 -0800 Jakub Kicinski wrote:

quoted

quoted

diff --git a/drivers/net/hamradio/6pack.c b/drivers/net/hamradio/6pack.c
index 49f10053a794..bfdf89e54752 100644
--- a/drivers/net/hamradio/6pack.c
+++ b/drivers/net/hamradio/6pack.c

@@ -672,11 +672,13 @@ static void sixpack_close(struct tty_struct *tty)
 	del_timer_sync(&sp->tx_t);
 	del_timer_sync(&sp->resync_t);
 
-	/* Free all 6pack frame buffers. */
+	unregister_netdev(sp->dev);
+
+	/* Free all 6pack frame buffers after unreg. */
 	kfree(sp->rbuff);
 	kfree(sp->xbuff);
 
-	unregister_netdev(sp->dev);
+	free_netdev(sp->dev);  

You should mention in the commit message why you think it's safe to add
free_netdev() which wasn't here before...

This driver seems to be setting:

	dev->needs_free_netdev	= true;

so unregister_netdev() will free the netdev automatically.

That said I don't see a reason why this driver needs the automatic
cleanup.

You can either remove that setting and then you can call free_netdev()
like you do, or you need to move the cleanup to dev->priv_destructor.

Looks like this go applied already, please send a follow up fix.

Oooops, thanks for the remind. XD

I just found that the mkill adds the free_netdev after the unregister_netdev so I did it too. No idea about this automatic cleanup.

Should I send the fix in this thread or open a new one?

Thanks

Lin 

On Thu, 11 Nov 2021 10:09:59 +0800 (GMT+08:00) Lin Ma wrote:

quoted

Looks like this go applied already, please send a follow up fix.  

Oooops, thanks for the remind. XD

I just found that the mkill adds the free_netdev after the
unregister_netdev so I did it too. No idea about this automatic
cleanup.

Should I send the fix in this thread or open a new one?

New thread is better for me.

Hi there,

On Thu, 11 Nov 2021 10:09:59 +0800 (GMT+08:00) Lin Ma wrote:

quoted

quoted

Looks like this go applied already, please send a follow up fix.  

Oooops, thanks for the remind. XD

I just found that the mkill adds the free_netdev after the
unregister_netdev so I did it too. No idea about this automatic
cleanup.

Should I send the fix in this thread or open a new one?

New thread is better for me.

The fix for the erroneous patch is sent, information is like below

Subject: [PATCH v0] hamradio: delete unnecessary free_netdev()
Date: Thu, 11 Nov 2021 22:00:07 +0800
Message-Id: [off-list ref]

Sorry about this disturbing :(

Best Regards
Lin