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] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANn89iLda2oxoPQaGd9r8frAaOu1LqxmWYm2O8W4HXaGRN8tcQ@mail.gmail.com>
Date:   Thu, 30 Jun 2022 16:44:29 +0200
From:   Eric Dumazet <edumazet@...gle.com>
To:     Duoming Zhou <duoming@....edu.cn>
Cc:     linux-hams@...r.kernel.org, netdev <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Jakub Kicinski <kuba@...nel.org>,
        David Miller <davem@...emloft.net>,
        Ralf Baechle <ralf@...ux-mips.org>
Subject: Re: [PATCH net] net: rose: fix UAF bug caused by rose_t0timer_expiry

On Thu, Jun 30, 2022 at 4:38 PM Duoming Zhou <duoming@....edu.cn> wrote:
>
> There are UAF bugs caused by rose_t0timer_expiry(). The
> root cause is that del_timer() could not stop the timer
> handler that is running and there is no synchronization.
> One of the race conditions is shown below:
>
>     (thread 1)             |        (thread 2)
>                            | rose_device_event
>                            |   rose_rt_device_down
>                            |     rose_remove_neigh
> rose_t0timer_expiry        |       rose_stop_t0timer(rose_neigh)
>   ...                      |         del_timer(&neigh->t0timer)
>                            |         kfree(rose_neigh) //[1]FREE
>   neigh->dce_mode //[2]USE |
>
> The rose_neigh is deallocated in position [1] and use in
> position [2].
>
> The crash trace triggered by POC is like below:
>
> BUG: KASAN: use-after-free in expire_timers+0x144/0x320
> Write of size 8 at addr ffff888009b19658 by task swapper/0/0
> ...
> Call Trace:
>  <IRQ>
>  dump_stack_lvl+0xbf/0xee
>  print_address_description+0x7b/0x440
>  print_report+0x101/0x230
>  ? expire_timers+0x144/0x320
>  kasan_report+0xed/0x120
>  ? expire_timers+0x144/0x320
>  expire_timers+0x144/0x320
>  __run_timers+0x3ff/0x4d0
>  run_timer_softirq+0x41/0x80
>  __do_softirq+0x233/0x544
>  ...
>
> This patch changes del_timer() in rose_stop_t0timer() and
> rose_stop_ftimer() to del_timer_sync() in order that the
> timer handler could be finished before the resources such as
> rose_neigh and so on are deallocated. As a result, the UAF
> bugs could be mitigated.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Duoming Zhou <duoming@....edu.cn>
> ---
>  net/rose/rose_link.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/rose/rose_link.c b/net/rose/rose_link.c
> index 8b96a56d3a4..9734d1264de 100644
> --- a/net/rose/rose_link.c
> +++ b/net/rose/rose_link.c
> @@ -54,12 +54,12 @@ static void rose_start_t0timer(struct rose_neigh *neigh)
>
>  void rose_stop_ftimer(struct rose_neigh *neigh)
>  {
> -       del_timer(&neigh->ftimer);
> +       del_timer_sync(&neigh->ftimer);
>  }

Are you sure this is safe ?

del_timer_sync() could hang if the caller holds a lock that the timer
function would need to acquire.



>
>  void rose_stop_t0timer(struct rose_neigh *neigh)
>  {
> -       del_timer(&neigh->t0timer);
> +       del_timer_sync(&neigh->t0timer);
>  }

Same here, please explain why it is safe.

>
>  int rose_ftimer_running(struct rose_neigh *neigh)
> --
> 2.17.1
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ