Re: [BUG] KASAN: slab-use-after-free Read in slip_receive_buf

[Eric Dumazet]

On Wed, Aug 26, 2026 at 7:38 AM Qingfang Deng <qingfang.deng@xxxxxxxxx> wrote:
>
> Hi,
>
> On 2026/8/25 23:27, Eric Dumazet wrote:
> > On Tue, Aug 25, 2026 at 5:07 PM Jaeyoung Chung <jjy600901@xxxxxxxxx> wrote:
> >> Hello,
> >>
> >> We found a "KASAN: slab-use-after-free Read in slip_receive_buf" on Linux v7.2.
> >> The issue was found by our own race fuzzer. We have not analyzed the root cause,
> >> so we do not have a proposed fix to offer.
> >>
> >> To reproduce the race reliably, we applied the delay patch below to the
> >> kernel and ran the C reproducer as root inside an x86_64 QEMU guest. The
> >> crash log we observed, the delay patch and the reproducer are all included
> >> below.
> >>
> >> The following kernel config options are required to reproduce the issue:
> >>      CONFIG_SLIP=y
> >>      CONFIG_LEGACY_TIOCSTI=y
> >>      CONFIG_UNIX98_PTYS=y
> >>      CONFIG_TTY=y
> >>      CONFIG_KASAN=y
> >>
> >> We hope this report is useful. Please let us know if any further
> >> information would help.
> >>
> >> Reported-by: Eulgyu Kim <eulgyukim@xxxxxxxxx>
> >> Reported-by: Jaeyoung Chung <jjy600901@xxxxxxxxx>
> > This rings a bell; I had a local syzbot report for this issue a while back.
> >
> > I think we should remove slip_hangup().
> ppp_async.c and ppp_synctty.c have the same anti-pattern. Should we
> remove theirs as well?

Probably, akthough ppp_async and ppp_synctty historically suffered
from this exact race, they added their own workaround: a global disc_data_lock,
refcount_t refcnt, and wait_for_completion(&ap->dead) on every callback.

Oh well.