NetBSD Problem Report #56903

From www@netbsd.org  Sun Jun 26 21:28:10 2022
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 5F9231A921F
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 26 Jun 2022 21:28:10 +0000 (UTC)
Message-Id: <20220626212738.D29701A9239@mollari.NetBSD.org>
Date: Sun, 26 Jun 2022 21:27:38 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: ppp_create and pppalloc are racy
X-Send-Pr-Version: www-1.0

>Number:         56903
>Category:       kern
>Synopsis:       ppp_create and pppalloc are racy
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jun 26 21:30:00 +0000 2022
>Originator:     Taylor R Campbell
>Release:        current
>Organization:
That NetBSD Foundation
>Environment:
syzbot amd64
>Description:
Under the lock, ppp_create inserts a new uninitialized ppp_softc into ppp_softcs.list, then releases the lock and initializes the entry.

A concurrent pppalloc call can find the uninitialized entry and try to use it, leading to mayhem, like:

[  83.6561894] panic: bpf_change_type
[  83.6561894] cpu1: Begin traceback...
[  83.6661684] vpanic() at netbsd:vpanic+0x282 sys/kern/subr_prf.c:293
[  83.7061693] panic() at netbsd:panic+0x9e sys/kern/subr_prf.c:1043
[  83.7261711] _bpf_change_type() at netbsd:_bpf_change_type+0x9e sys/net/bpf.c:2264
[  83.7561691] pppopen() at netbsd:pppopen+0x154 sys/net/ppp_tty.c:222
[  83.7861716] ttioctl() at netbsd:ttioctl+0x13de sys/kern/tty.c:1232
[  83.8061686] compat_43_ttioctl() at netbsd:compat_43_ttioctl+0xb08 sys/compat/common/tty_43.c:265
[  83.8261685] ttioctl() at netbsd:ttioctl+0xa4f sys/kern/tty.c:1441
[  83.8561694] comioctl() at netbsd:comioctl+0x13b sys/dev/ic/com.c:1305
[  83.8761696] cdev_ioctl() at netbsd:cdev_ioctl+0x1e7 sys/kern/subr_devsw.c:1223
[  83.8961675] spec_ioctl() at netbsd:spec_ioctl+0x148 sys/miscfs/specfs/spec_vnops.c:1294
[  83.9261704] VOP_IOCTL() at netbsd:VOP_IOCTL+0x132 sys/kern/vnode_if.c:934
[  83.9461696] vn_ioctl() at netbsd:vn_ioctl+0x1b9 sys/kern/vfs_vnops.c:865
[  83.9761740] sys_ioctl() at netbsd:sys_ioctl+0x8f5 sys/kern/sys_generic.c:673
[  83.9961699] sys_syscall() at netbsd:sys_syscall+0x10e sy_call sys/sys/syscallvar.h:65 [inline]
[  83.9961699] sys_syscall() at netbsd:sys_syscall+0x10e sys/kern/sys_syscall.c:90
[  84.0261771] syscall() at netbsd:syscall+0x25a sy_call sys/sys/syscallvar.h:65 [inline]
[  84.0261771] syscall() at netbsd:syscall+0x25a sy_invoke sys/sys/syscallvar.h:94 [inline]
[  84.0261771] syscall() at netbsd:syscall+0x25a sys/arch/x86/x86/syscall.c:138
[  84.0361748] --- syscall (number 0) ---

pppalloc and ppp_create need more coherent locking, and maybe a condvar to wait for initialization to complete if it's in progress -- both pppalloc and ppp_create have independent bugs with two threads stomping over the other.  The softint_establish error branch in pppalloc is also leaky.

Reported-by: syzbot+9c44d309942301988adf@syzkaller.appspotmail.com
>How-To-Repeat:
  intptr_t res = 0;
  memcpy((void*)0x20000000, "./file0\000", 8);
  syscall(SYS_mknod, 0x20000000ul, 0x2876ul, 0x40000800ul);
  memcpy((void*)0x20000080, "./file0\000", 8);
  res = syscall(SYS_open, 0x20000080ul, 0ul, 0ul);
  if (res != -1)
    r[0] = res;
  *(uint32_t*)0x20000140 = 5;
  *(uint32_t*)0x20000144 = 0;
  syscall(SYS_ioctl, r[0], 0x80047401ul, 0x20000140ul);
  syscall(SYS_ioctl, r[0], 0x8010744dul, 0ul);

https://syzkaller.appspot.com/bug?id=8029c7296c5e7960eaaecc7a5cf05316ccd7aa4a
>Fix:
Yes, please!

Home	PR Database Search