linux-kernel - Re: [PATCH v3] can, slip: Protect tty->disc_data in write

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20200122.203252.1974816529601154217.davem@davemloft.net>
Date:   Wed, 22 Jan 2020 20:32:52 +0100 (CET)
From:   David Miller <davem@...emloft.net>
To:     rpalethorpe@...e.com
Cc:     linux-can@...r.kernel.org,
        syzbot+017e491ae13c0068598a@...kaller.appspotmail.com,
        wg@...ndegger.com, mkl@...gutronix.de, tylerwhall@...il.com,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        syzkaller@...glegroups.com
Subject: Re: [PATCH v3] can, slip: Protect tty->disc_data in write_wakeup
 and close with RCU

From: Richard Palethorpe <rpalethorpe@...e.com>
Date: Tue, 21 Jan 2020 14:42:58 +0100

> write_wakeup can happen in parallel with close/hangup where tty->disc_data
> is set to NULL and the netdevice is freed thus also freeing
> disc_data. write_wakeup accesses disc_data so we must prevent close from
> freeing the netdev while write_wakeup has a non-NULL view of
> tty->disc_data.
> 
> We also need to make sure that accesses to disc_data are atomic. Which can
> all be done with RCU.
> 
> This problem was found by Syzkaller on SLCAN, but the same issue is
> reproducible with the SLIP line discipline using an LTP test based on the
> Syzkaller reproducer.
> 
> A fix which didn't use RCU was posted by Hillf Danton.
> 
> Fixes: 661f7fda21b1 ("slip: Fix deadlock in write_wakeup")
> Fixes: a8e83b17536a ("slcan: Port write_wakeup deadlock fix from slip")
> Reported-by: syzbot+017e491ae13c0068598a@...kaller.appspotmail.com
> Signed-off-by: Richard Palethorpe <rpalethorpe@...e.com>

Applied and queued up for -stable, thanks.