From owner-freebsd-hackers@freebsd.org Thu Jun 13 05:02:31 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 862B015CBB57 for ; Thu, 13 Jun 2019 05:02:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 38D466B668 for ; Thu, 13 Jun 2019 05:02:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x835.google.com with SMTP id p15so1755537qtl.3 for ; Wed, 12 Jun 2019 22:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cjEEqS1T1py9UYbvil/IjCXRJQfgZqfldpkYSVBpdQE=; b=qlMiqEBY1a5VVQBoO79t+0EVI85xl20uidNN0GdlEwjwRl3Lnc9ZE+cY1BoatLGrDY if03QuBXB/PCi6CxpEEPr/PDjbPtk4AvcBIJmKC7wHxJrmNku5SP9l+HlgSy3BY2bifQ fyUwNSnKU+idGWxDU9kBMTSUoPQs6d5wg3neBui/vOKcb3Ok04vK66hTosBhixcE0iwd AodQOsTfyGJnQWIjid7J73PaxrkWepmNdAOxhjN8dm5qkx8mMARQ2P+c10lUJiS0wbJY 33HwYsVV7rIP1iaeLULmo4onLwfZ5KnM8YWbKNEmFDHV8RWbDtuda6p9exgBZvPo18R0 UlMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cjEEqS1T1py9UYbvil/IjCXRJQfgZqfldpkYSVBpdQE=; b=OTOpazGpde4VbN0Q+o7hkayVVnFolEVyoDlTwOxOdeNGU3Caszwj5OOXCedUz/AV97 5Z19nrVnwnLCc4Hb3OGkrdVNt7D4IYNXWoLi7uPyHxfsuEn7sbOLU8pK+WSurQCDfOHA 9EAUsduMUyJgtmLECSz7GHVnT3bu4NAS/n9wRwcbRKyj5cnNKOxbmYkYaRFreHsZeMjR YexRranHi0rbb0iDsekNIECdpL6vC3Ljz1/IU7werv6C/Lch1zmePZLhFB4h2zCCTuEz c54UyxmFvd5t31tGgzJd35iGHUFb/UxePkSqthaoaF/8j5Qv+edjROhwIqz+MUg7kXRW CWnQ== X-Gm-Message-State: APjAAAUTW+rr9dFcT9OCU4bcMB8sWylRvSbaGbJdBHiSmB6XkpGdJE0V n89Y7qWj3jUONlH7Lp22yy7G7+rew7YNDHIZiQySLooXxEQ= X-Google-Smtp-Source: APXvYqzNpygNkSl+JvEdTeCCxON8pVPJJJajLf8T+9Bvm6WELuaHe5NWOn9sQxriQg0CwyphB1jdBb4bxllFz27CKPM= X-Received: by 2002:a0c:d91b:: with SMTP id p27mr1818877qvj.236.1560402148512; Wed, 12 Jun 2019 22:02:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Wed, 12 Jun 2019 23:02:16 -0600 Message-ID: Subject: Re: Dev:Ciss: A kernel address leakage in sys/dev/ciss/ciss.c To: Fuqian Huang Cc: FreeBSD Hackers X-Rspamd-Queue-Id: 38D466B668 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=qlMiqEBY X-Spamd-Result: default: False [-5.98 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.974,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[5.3.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; IP_SCORE(-2.99)[ip: (-9.44), ipnet: 2607:f8b0::/32(-3.16), asn: 15169(-2.31), country: US(-0.06)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2019 05:02:31 -0000 Because CISS_FLAG_NOTIFY_OK will be clear in sc->ciss_flags. It's only set when we have the notifier armed, which is only armed when we have outanding commands in the CISS hardware. Since we know that all the outstanding requests have completed before the close, it should be clear. But again, this only gets called at the end of ciss_attach (on the error path before the notifier is setup) or in ciss_detach (which is only called when the ciss driver is unloaded with the device attached, but unused, or if the user has administratively put the interface down). So even if I've read things and a notifier is running, the only way to provoke it is to do a root-only operation. Disclosing kernel addresses to root doesn't seem like a big deal, especially since the dmesg can be secured from non-root users. This is why I've said this is more theoretical than actual. You need root permissions to provoke it, and then root permissions to read the dmesg. I'll commit a #if 0 out of an abundance of caution, but I'm having trouble seeing how non-root users could provoke it. Then again, the ciss driver is for older hardware that is somewhat rare these days. Thanks for the report... Warner On Wed, Jun 12, 2019 at 8:54 PM Fuqian Huang wrote: > But, why there will be no commands that are printed? > 'cr' is get from ciss_get_request and 'cr->cr_data' is the result of > malloc in ciss_notify_abort, and they are freed after the 'out' label. > At the printing point, some address has been printed out. > I know what you mean that this only happens when detaching the device. > But it seems that some address is printed out before the free > operation, and is it necessary to print the address? > > Warner Losh =E6=96=BC 2019=E5=B9=B46=E6=9C=8813=E6=97=A5= =E9=80=B1=E5=9B=9B =E4=B8=8A=E5=8D=885:51=E5=AF=AB=E9=81=93=EF=BC=9A > > > > > > > > On Wed, Jun 12, 2019 at 7:02 AM Fuqian Huang > wrote: > >> > >> In freebsd/sys/dev/ciss/ciss.c, function ciss_print_request will dump > >> the address of a kernel object cr to user space. Each time when a > >> device is detached, it will call > >> ciss_free->ciss_notify_abort->ciss_print_request, and this finally > >> dump a kernel address to user space. > > > > > > This is, at best, a theoretical concern. ciss_detach isn't called excep= t > when detaching the device. This only happens if you are unloading the > module or using devctl to detach it. Second, the bit you chopped out of > ciss_detach ensure that the controller isn't open. Close is only called > when there's no pending requests from geom to the device, and we get call= ed > for the LAST close, meaning nothing else has it open. This means there wi= ll > be no commands to abort when ciss_notify_abort() is called. Since there's > no commands to abort, there will be no commands that are printed, so no > user address will be disclosed. > > > > Having said that, do you have a test case that can trigger this? It > would be most unexpected indeed... > > > > Warner > > > >> > >> static int > >> ciss_detach(device_t dev) > >> { > >> struct ciss_softc *sc =3D device_get_softc(dev); > >> ... > >> ciss_free(sc); > >> return (0); > >> } > >> > >> static void > >> ciss_free(struct ciss_softc *sc) > >> { > >> ... > >> -> ciss_notify_abort(sc); > >> ... > >> } > >> > >> static int > >> ciss_notify_abort(struct ciss_softc *sc) > >> { > >> struct ciss_request *cr; > >> ... > >> if ((error =3D ciss_get_request(sc, &cr)) > >> goto out; > >> ... > >> -> ciss_print_request(cr); > >> ... > >> } > >> > >> static void > >> ciss_print_request(struct ciss_request *cr) > >> { > >> struct ciss_softc *sc; > >> ... > >> sc =3D cr->cr_sc; > >> ... > >> -> ciss_printf(sc, "REQUEST @ %p\n", cr); > >> ciss_printf(sc, " data %p/%d tag %d flags %b\n", > >> cr->cr_data, cr->cr_length, cr->cr_tag, cr->cr_flags, > >> "\20\1mapped\2sleep\3poll\4dataout\5datain\n"); > >> } > >> _______________________________________________ > >> freebsd-hackers@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > >> To unsubscribe, send any mail to " > freebsd-hackers-unsubscribe@freebsd.org" >