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 <[email protected]>
---
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 <[email protected]>
---
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 <[email protected]>
> 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.
> }
>
> /* Perform I/O control on an active 6pack channel. */
On Wed, 10 Nov 2021 18:05:25 -0800 Jakub Kicinski wrote:
> > 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" <[email protected]>
> Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
> 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:
> > > 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:
> > 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:
> > > 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: <[email protected]>
Sorry about this disturbing :(
Best Regards
Lin