From owner-freebsd-security@freebsd.org Mon Aug 6 20:45:34 2018 Return-Path: Delivered-To: freebsd-security@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 4B35A1064EBA for ; Mon, 6 Aug 2018 20:45:34 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 033D28A47E; Mon, 6 Aug 2018 20:45:34 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1035) id EFAFF1A3C; Mon, 6 Aug 2018 20:45:33 +0000 (UTC) From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-18:08.tcp Reply-To: freebsd-security@freebsd.org Precedence: bulk Message-Id: <20180806204533.EFAFF1A3C@freefall.freebsd.org> Date: Mon, 6 Aug 2018 20:45:33 +0000 (UTC) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.27 List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 20:45:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-18:08.tcp Security Advisory The FreeBSD Project Topic: Resource exhaustion in TCP reassembly Category: core Module: inet Announced: 2018-08-06 Credits: Juha-Matti Tilli from Aalto University, Department of Communications and Networking and Nokia Bell Labs Affects: All supported versions of FreeBSD. Corrected: 2018-08-06 18:46:09 UTC (stable/11, 11.1-STABLE) 2018-08-06 17:47:47 UTC (releng/11.2, 11.2-RELEASE-p1) 2018-08-06 17:48:46 UTC (releng/11.1, 11.1-RELEASE-p12) 2018-08-06 18:47:03 UTC (stable/10, 10.4-STABLE) 2018-08-06 17:50:40 UTC (releng/10.4, 10.4-RELEASE-p10) CVE Name: CVE-2018-6922 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The Transmission Control Protocol (TCP) of the TCP/IP protocol suite provides a connection-oriented, reliable, sequence-preserving data stream service. To transmit a stream of data, TCP breaks the data stream into segments for transmission through the Internet, and reassembles the segments at the receiving side to recreate the data stream. II. Problem Description One of the data structures that holds TCP segments uses an inefficient algorithm to reassemble the data. This causes the CPU time spent on segment processing to grow linearly with the number of segments in the reassembly queue. III. Impact An attacker who has the ability to send TCP traffic to a victim system can degrade the victim system's network performance and/or consume excessive CPU by exploiting the inefficiency of TCP reassembly handling, with relatively small bandwidth cost. IV. Workaround As a workaround, system administrators should configure their systems to only accept TCP connections from trusted end-stations, if it is possible to do so. For systems which must accept TCP connections from untrusted end-stations, the workaround is to limit the size of each reassembly queue. The capability to do that is added by the patches noted in the "Solution" section below. V. Solution As a temporary solution to this problem, these patches limit the size of each TCP connection's reassembly queue. The value is controlled by a sysctl (net.inet.tcp.reass.maxqueuelen), which sets the maximum number of TCP segments that can be outstanding on a session's reassembly queue. This value defaults to 100. Note that setting this value too low could impact the throughput of TCP connections which experience significant loss or reordering. However, the higher this number is set, the more resources can be consumed on TCP reassembly processing. Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. Afterward, reboot the system. 2) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install Afterward, reboot the system. 3) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. [FreeBSD 10.4] # fetch https://security.FreeBSD.org/patches/SA-18:08/tcp-10.patch # fetch https://security.FreeBSD.org/patches/SA-18:08/tcp-10.patch.asc # gpg --verify tcp-10.patch.asc [FreeBSD 11.x] # fetch https://security.FreeBSD.org/patches/SA-18:08/tcp-11.patch # fetch https://security.FreeBSD.org/patches/SA-18:08/tcp-11.patch.asc # gpg --verify tcp-11.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in and reboot the system. VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/10/ r337392 releng/10.4/ r337389 stable/11/ r337391 releng/11.1/ r337388 releng/11.2/ r337387 - ------------------------------------------------------------------------- To see which files were modified by a particular revision, run the following command, replacing NNNNNN with the revision number, on a machine with Subversion installed: # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base Or visit the following URL, replacing NNNNNN with the revision number: VII. References The latest revision of this advisory is available at -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.2.9 (FreeBSD) iQIzBAEBCgAdFiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAltosd4ACgkQ05eS9J6n 5cKLRRAApitUTx46nToGtbCr/fzEZtYpjU0L/kMDwFw8ngfrb3MR4yht087t8JK1 jZlbeKRQwYjN+ecLrO3QdWoM4LavQK/cYuWq2tCpJiwqXK15rDJGBJjlBiAsmupF fGGSD2DcJ/Jz7zTKDkjybCh83QGGTt/HBZRYLc85ipJPHgPQQtnD/OLjFK34Lr45 vEss9AAkBEe4ZWiSltrQYzqMYf8+sCz/OYP+NGluz4eUjuzKogqyLIAA29auqoNp UY5tIUhf8dcB9oeARxWlvmxTKSLB5kevF5jsBzxB8Ap1xUfLFip02h6ApL0xuWz2 ouX/gN8KBgmJoNIP+GbBY29sQCEY0GTIR9q/dO1ZB3CePJFQsvWjtNeBBjIK66On xJSSrUXDPANfcePbnCN9JdsclSEJ0+EBYol3hSWVY8bX3OMcOZw1wRXXCwN0T3of QQwbuP0ORt5OdsOObwaxDJEWLEma7N2swWF5YR0oQl0+ETvkIsqFilsTlY6qEB/L WG9G1Y9uVn++AJs7HzI+vKVEhhwtJep+7ks28sH5J0LQiUGYfwRACYfVLgi6iXNV YKPB4hUFd2d8QaYWdgU92YBJWrR8bqyDdetifMEG5tP+TFCeNCh6SMpRnL7Lzns+ hkZiRHJeIT7tGu77xZknFI6ghDHOdemtZ/QiL0NsrM05spWkdIA= =HNsD -----END PGP SIGNATURE----- From owner-freebsd-security@freebsd.org Mon Aug 6 23:02:19 2018 Return-Path: Delivered-To: freebsd-security@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 C83F61068ED5 for ; Mon, 6 Aug 2018 23:02:19 +0000 (UTC) (envelope-from robtsgt@sgt.com) Received: from diablo.sgt.com (diablo.SGT.COM [204.107.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "diablo.sgt.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 36BDD8FCEF for ; Mon, 6 Aug 2018 23:02:19 +0000 (UTC) (envelope-from robtsgt@sgt.com) Received: from w245.sgt.com (w245.sgt.com [192.168.99.245] (may be forged)) by diablo.sgt.com (8.15.2/8.15.2) with ESMTPS id w76MVoSF001530 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 6 Aug 2018 22:31:56 GMT (envelope-from robtsgt@sgt.com) Received: from sgtlaptop3.sgt.com (sgtlaptop3.sgt.com [192.168.99.11]) (authenticated bits=0) by w245.sgt.com (8.15.2/8.15.2) with ESMTPSA id w76MVovO001994 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 6 Aug 2018 22:31:50 GMT (envelope-from robtsgt@sgt.com) From: Rob Sargent Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: FreeBSD Security Advisory FreeBSD-SA-18:08.tcp Date: Mon, 6 Aug 2018 18:31:49 -0400 References: <20180806204534.001611A3E@freefall.freebsd.org> To: freebsd-security@freebsd.org In-Reply-To: <20180806204534.001611A3E@freefall.freebsd.org> Message-Id: X-Mailer: Apple Mail (2.3445.8.2) X-Virus-Scanned: clamav-milter 0.100.1 at diablo.sgt.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (diablo.sgt.com [192.168.99.202]); Mon, 06 Aug 2018 22:31:56 +0000 (UTC) X-Mailman-Approved-At: Mon, 06 Aug 2018 23:36:13 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 23:02:20 -0000 Did you forget to increment version# on purpose?? Should have changed = p9 to p10 ? On Aug 6, 2018, at 4:45 PM, FreeBSD Security Advisories = wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D FreeBSD-SA-18:08.tcp Security = Advisory The FreeBSD = Project Topic: Resource exhaustion in TCP reassembly=20 Category: core Module: inet Announced: 2018-08-06 Credits: Juha-Matti Tilli from Aalto University, Department of Communications and = Networking and Nokia Bell Labs Affects: All supported versions of FreeBSD. Corrected: 2018-08-06 18:46:09 UTC (stable/11, 11.1-STABLE) 2018-08-06 17:47:47 UTC (releng/11.2, 11.2-RELEASE-p1) 2018-08-06 17:48:46 UTC (releng/11.1, 11.1-RELEASE-p12) 2018-08-06 18:47:03 UTC (stable/10, 10.4-STABLE) 2018-08-06 17:50:40 UTC (releng/10.4, 10.4-RELEASE-p10) CVE Name: CVE-2018-6922 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The Transmission Control Protocol (TCP) of the TCP/IP protocol suite provides a connection-oriented, reliable, sequence-preserving data stream service. To transmit a stream of data, TCP breaks the data stream into segments for transmission through the Internet, and reassembles the segments at the receiving side to recreate the data stream. II. Problem Description One of the data structures that holds TCP segments uses an inefficient algorithm to reassemble the data. This causes the CPU time spent on segment processing to grow linearly with the number of segments in the reassembly queue. III. Impact An attacker who has the ability to send TCP traffic to a victim system can degrade the victim system's network performance and/or consume excessive CPU by exploiting the inefficiency of TCP reassembly handling, with relatively small bandwidth cost. IV. Workaround As a workaround, system administrators should configure their systems to only accept TCP connections from trusted end-stations, if it is possible to do so. For systems which must accept TCP connections from untrusted end-stations, the workaround is to limit the size of each reassembly queue. The capability to do that is added by the patches noted in the "Solution" section below. V. Solution As a temporary solution to this problem, these patches limit the size of each TCP connection's reassembly queue. The value is controlled by a sysctl (net.inet.tcp.reass.maxqueuelen), which sets the maximum number of TCP segments that can be outstanding on a session's reassembly queue. This value defaults to 100. Note that setting this value too low could impact the throughput of TCP connections which experience significant loss or reordering. However, the higher this number is set, the more resources can be consumed on TCP reassembly processing. Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. Afterward, reboot the system. 2) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install Afterward, reboot the system. 3) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. [FreeBSD 10.4] # fetch https://security.FreeBSD.org/patches/SA-18:08/tcp-10.patch # fetch https://security.FreeBSD.org/patches/SA-18:08/tcp-10.patch.asc # gpg --verify tcp-10.patch.asc [FreeBSD 11.x] # fetch https://security.FreeBSD.org/patches/SA-18:08/tcp-11.patch # fetch https://security.FreeBSD.org/patches/SA-18:08/tcp-11.patch.asc # gpg --verify tcp-11.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in and reboot the system. VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path = Revision - = ------------------------------------------------------------------------- stable/10/ = r337392 releng/10.4/ = r337389 stable/11/ = r337391 releng/11.1/ = r337388 releng/11.2/ = r337387 - = ------------------------------------------------------------------------- To see which files were modified by a particular revision, run the following command, replacing NNNNNN with the revision number, on a machine with Subversion installed: # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base Or visit the following URL, replacing NNNNNN with the revision number: VII. References The latest revision of this advisory is available at -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.2.9 (FreeBSD) iQIzBAEBCgAdFiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAltosd4ACgkQ05eS9J6n 5cKLRRAApitUTx46nToGtbCr/fzEZtYpjU0L/kMDwFw8ngfrb3MR4yht087t8JK1 jZlbeKRQwYjN+ecLrO3QdWoM4LavQK/cYuWq2tCpJiwqXK15rDJGBJjlBiAsmupF fGGSD2DcJ/Jz7zTKDkjybCh83QGGTt/HBZRYLc85ipJPHgPQQtnD/OLjFK34Lr45 vEss9AAkBEe4ZWiSltrQYzqMYf8+sCz/OYP+NGluz4eUjuzKogqyLIAA29auqoNp UY5tIUhf8dcB9oeARxWlvmxTKSLB5kevF5jsBzxB8Ap1xUfLFip02h6ApL0xuWz2 ouX/gN8KBgmJoNIP+GbBY29sQCEY0GTIR9q/dO1ZB3CePJFQsvWjtNeBBjIK66On xJSSrUXDPANfcePbnCN9JdsclSEJ0+EBYol3hSWVY8bX3OMcOZw1wRXXCwN0T3of QQwbuP0ORt5OdsOObwaxDJEWLEma7N2swWF5YR0oQl0+ETvkIsqFilsTlY6qEB/L WG9G1Y9uVn++AJs7HzI+vKVEhhwtJep+7ks28sH5J0LQiUGYfwRACYfVLgi6iXNV YKPB4hUFd2d8QaYWdgU92YBJWrR8bqyDdetifMEG5tP+TFCeNCh6SMpRnL7Lzns+ hkZiRHJeIT7tGu77xZknFI6ghDHOdemtZ/QiL0NsrM05spWkdIA=3D =3DHNsD -----END PGP SIGNATURE----- _______________________________________________ freebsd-security-notifications@freebsd.org mailing list = https://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications To unsubscribe, send any mail to = "freebsd-security-notifications-unsubscribe@freebsd.org" From owner-freebsd-security@freebsd.org Tue Aug 7 20:43:37 2018 Return-Path: Delivered-To: freebsd-security@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 90F09106AB64 for ; Tue, 7 Aug 2018 20:43:37 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2B6BB80F9D for ; Tue, 7 Aug 2018 20:43:37 +0000 (UTC) (envelope-from delphij@gmail.com) Received: by mail-it0-x232.google.com with SMTP id 139-v6so734581itf.0 for ; Tue, 07 Aug 2018 13:43:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zaNc8eGNBOK1kph+00p56yZsDkjEShMXkGW4s3pvX/8=; b=MzmYXm7opIqzO9T3rsihiuWU+cnxi4spYcf/59HQjd9/zXjNWBg9rqUA6OZrnQOc1s iOQBTMK8JB7/Mxk/L9rQc+XTHiMkePGV57Sdgi32zQE1kHWwAfqsXJZjCvY2Vwhxv6cF pCIPHabOU8Hdbq4ZWWHliKO5vJc2qL2L4XwAkc5Np2ZXJ+xNV6YgbaNGQr1rxuQavxEr SZNVf5ipbaXeceGKz9tawbBBH4KYvENzLR5R420F35x+uQOWbAmzITG6oAg7M1Pt7DVy qVMhbMcU4ifG8Gh5LvWA9mzxvSM9BdX0XX26E2YdPcmUuo2K1g+Verv3TyCIoyudnBsP QZBA== 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=zaNc8eGNBOK1kph+00p56yZsDkjEShMXkGW4s3pvX/8=; b=N9hX8z0MdYceuBSP1hcq560Rep0yoTWw/HsfsmSJDfV7ew1s537n0MjbvhgVDFoAlN GXrv7UTr+bQDKPvfD4izc0E74kaU2F0BuFCFk72jv7OoccjZXKe761ZWRPGuDep6KjVk CdXOhB9HN4e37gSeZ8ybcycc2ul7JjXt236e+HIs1T67MrBLyNi1gFAy99rJz/h1jyew 1blAy8qB7xui7e6i2+iV/+nGgkw6PCpyF1ruzk9gWiG/vvxmH//BZConig2HL3QEg+0l 06W5KRHnGTsnPeOmNmg8ffIM2NjA+x8MFYYPW6uclf5im+IPrEgPqjoyH77co2ynYuNN lKEw== X-Gm-Message-State: AOUpUlFBFJ1wAfwXNXmNvSv0A+w3nnzyeSP88n1tZtcjJ9C3HzqQsC6g A0z23ZMM2wtAniF/e1BZt86+B1b0tA3Sxgi6vr1P4ICV X-Google-Smtp-Source: AA+uWPwQfzeY1SDFa3IJ0AJ+2mktj78GV8/JF2pH9A3IcMW4l4KHRka3OPOVJyiNOo8ICPrKYEstfsM7jcYswjuz3ro= X-Received: by 2002:a02:702:: with SMTP id f2-v6mr7003jaf.70.1533674616161; Tue, 07 Aug 2018 13:43:36 -0700 (PDT) MIME-Version: 1.0 References: <20180806204534.001611A3E@freefall.freebsd.org> In-Reply-To: From: Xin LI Date: Tue, 7 Aug 2018 13:43:25 -0700 Message-ID: Subject: Re: FreeBSD Security Advisory FreeBSD-SA-18:08.tcp To: robtsgt@sgt.com Cc: freebsd-security@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2018 20:43:37 -0000 On Mon, Aug 6, 2018 at 4:38 PM Rob Sargent via freebsd-security wrote: > > Did you forget to increment version# on purpose?? Should have changed p9 to p10 ? The version was bumped here: https://svnweb.freebsd.org/base/releng/10.4/sys/conf/newvers.sh?r1=333371&r2=337395 But since the bump itself is not for completeness, we used the actual revision of the security fix. From owner-freebsd-security@freebsd.org Wed Aug 8 15:57:50 2018 Return-Path: Delivered-To: freebsd-security@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 4CB72105FFD6 for ; Wed, 8 Aug 2018 15:57:50 +0000 (UTC) (envelope-from pravkin.a@bks.tv) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B384383213 for ; Wed, 8 Aug 2018 15:57:49 +0000 (UTC) (envelope-from pravkin.a@bks.tv) Received: by mail-lj1-x233.google.com with SMTP id w16-v6so2100986ljh.12 for ; Wed, 08 Aug 2018 08:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bks-tv.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=8S5VL4I/DoiohRz+AF9w18pkQaWMkGSZ6ja+TqDgypg=; b=hZ0Dl/pQvDE//oTooS3MMzqz1PiHt6T1ljtB1YRSdz1kso0Snr5UzW3nfk5SC6AV1T YOH+foqj5QB2VFb9c68QTicoS8SjWYRI9tmssJcZAEyfDy1RW1QNXdA8RdEBVGlIAdvy 0/wNuMTpbQnkLJa4viIXfUritNt0XVpHQfRnqBxLz62BIIYgr/8J9qLe9thXPqObCuBz ypT/YYKIcV5vJi/BBJWp0ghgIeRwSSZ/joisvAMRcnNuiwvLNFUlqRgv2gDsCg6EN5fN up0DwS0teWoZ1lqdpNngIyirkgBE3yHLlu6k2eduMJOhPmgO3au0LDLh8W0rhIYWv3F4 AY5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=8S5VL4I/DoiohRz+AF9w18pkQaWMkGSZ6ja+TqDgypg=; b=bcD5De0fMTngcWWyP05n18Sa6pNxwQ25EA586KfktnBK4n/HFjNo+3PMf/XZnd46Kk tLxJ25+9HMfzc594AHnmgHcMag64+Fq7odRb73d8DRYlVeU9/ZWrmbYbhD7domiIpP2T +ULVQsaDdzgI22ObH/1rmgn/1MU89hnR85IvQ9qPCE8qFq7+GqJx8PHvPW+A8noONUtE GA4JkWupVp6mTY3t+gFvxbbM0S1Vk1xfUijovCfcWlKtn/jf9wa/5HlzjKoWEkMeAItu u1l4e06FVFnQurJxcH7p85enKOYwI4iraqUgSWqSfesuOnTalrHsBAme2NaxJG72aFuY SqCQ== X-Gm-Message-State: AOUpUlG97pF76evPnChRAiPmzEonpSdJgLo6A0N7YHn+CBCWzI92uDK9 qLOqYV91dWmGRiNcztpqkCRzDDVMdd/fAg== X-Google-Smtp-Source: AA+uWPw9ONLCdh6la3kGLG5Q3loLiBRH/6pDwt6gQyo7xi9eBx3EE6nHRpEacUpu6eLKdYmz6xvf2w== X-Received: by 2002:a2e:97c8:: with SMTP id m8-v6mr1565105ljj.52.1533743867980; Wed, 08 Aug 2018 08:57:47 -0700 (PDT) Received: from fduch.bks-tv.ru ([31.132.174.227]) by smtp.gmail.com with ESMTPSA id a16-v6sm726872ljj.28.2018.08.08.08.57.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Aug 2018 08:57:47 -0700 (PDT) Date: Wed, 8 Aug 2018 18:57:37 +0300 From: "Alexander M. Pravkin" To: Denis Polygalov Cc: freebsd-security Subject: Re: Recent security patch cause reboot loop on 11.1 RELEASE Message-ID: <20180808155735.GA64503@fduch.bks-tv.ru> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 15:57:50 -0000 On Thu, Jun 21, 2018 at 09:13:54PM +0900, Denis Polygalov wrote: > Seems like I did not cc my reply to the mailing list. > Doing it now because I found a hint which may > lead to the cause of the reboot loop. > > Removing: > > linux_load="YES" > linprocfs_load="YES" > linsysfs_load="YES" > > prevent the reboot loop in multi-user mode but > leave me without Linux emulation... Same thing when upgrading two amd64 machines from 11.1-p9, 11.1-p10 to 11.2-p1. Panic occurs when boot process is almost complete (most of rc.d scripts started) and looks like this: fault virtual address = 0x134 fault code = supervisor read data, page not present current process = 800 (kldload) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: ... #8 0x................ at VBoxDrvFreeBSDModuleEvent+0x117 ... And yes, virtualbox-ose-kmod was installed and enabled on both machines. Disabled it, completed freebsd-update install, and reinstalled kmod package: everything is OK now. Conclusion: don't forget that 3rd-party kernel modules can break things during/after upgrade. > Regards, > Denis. > > > Hi Gordon, > > > > this is real hardware. I found the reason (see below). > > Setting hw.lazy_fpu_switch=1 in /boot/loader.conf makes no difference. > > No panic messages. > > I can tell you when it happen. Here is the boot messages: > > ... skipped ... > > Timecounters tick every 1.000 msec > > nvme cam probe device init > > ugen2.1: at usbus2 > > ugen1.1: at usbus1 > > ugen0.1: at usbus0 > > uhub0: on usbus2 > > uhub1: on usbus0 > > uhub2: on usbus1 > > uhub1: 2 ports with 2 removable, self powered > > uhub2: 2 ports with 2 removable, self powered > > uhub0: 4 ports with 4 removable, self powered > > > > <---- here screen (local monitor) goes black and machine restarted. > > > > ada0 at ata2 bus 0 scbus8 target 0 lun 0 > > ada0: ATA8-ACS SATA 3.x device > > ada0: Serial Number WD-WMC1P0D1KEHJ > > ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) > > ada0: 1907729MB (3907029168 512 byte sectors) > > da0 at ciss0 bus 0 scbus0 target 0 lun 0 > > da0: Fixed Direct Access SCSI device > > da0: 135.168MB/s transfers > > da0: Command Queueing enabled > > da0: 858293MB (1757784604 512 byte sectors) > > Trying to mount root from ufs:/dev/da0s1a [rw]... > > > > I noticed that I can boot the *patched* kernel in single user mode. > > Removing these 3 lines from the /boot/loader.conf fixed rebooting loop problem: > > > > linux_load="YES" > > linprocfs_load="YES" > > linsysfs_load="YES" > > > > This machine is used as a test bench to test stuff > > before deploying on a production server. > > We need Linux emulation support on the production > > server to run closed source software... > > So... maybe this will help someone. > > > > Blaming evil penguins, > > Denis > > > > On 21/06/2018 4:19 PM, Gordon Tetlow wrote: > > On Wed, Jun 20, 2018 at 11:14 PM, Denis Polygalov wrote: > >> What I did is following: > >> > >> # uname -a > >> FreeBSD my_host_name 11.1-RELEASE-p10 FreeBSD 11.1-RELEASE-p10 #0: Tue > >> May 8 05:21:56 UTC 2018 > >> root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 > >> > >> # freebsd-update fetch > >> Looking up update.FreeBSD.org mirrors... 3 mirrors found. > >> Fetching metadata signature for 11.1-RELEASE from update6.freebsd.org... done. > >> Fetching metadata index... done. > >> Inspecting system... done. > >> Preparing to download files... done. > >> > >> The following files will be updated as part of updating to 11.1-RELEASE-p11: > >> /boot/kernel/kernel > >> > >> Installing this update cause endless reboot loop. > >> > >> # cat /boot/loader.conf > >> kern.maxfiles="32768" > >> zfs_load="YES" > >> linux_load="YES" > >> linprocfs_load="YES" > >> linsysfs_load="YES" > >> > >> # dmesg |grep CPU > >> CPU: Intel(R) Xeon(TM) CPU 3.40GHz (3400.19-MHz K8-class CPU) > >> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > >> SMP: AP CPU #1 Launched! > >> SMP: AP CPU #3 Launched! > >> SMP: AP CPU #2 Launched! > >> cpu0: on acpi0 > >> cpu1: on acpi0 > >> cpu2: on acpi0 > >> cpu3: on acpi0 > >> acpi_perf0: on cpu0 > >> est: CPU supports Enhanced Speedstep, but is not recognized. > >> est: CPU supports Enhanced Speedstep, but is not recognized. > >> est: CPU supports Enhanced Speedstep, but is not recognized. > >> > >> The machine is HP ProLiant ML350 > > > > Sorry to hear you are having a problem. > > > > Just to confirm, this is running on hardware and not on a Xen > > hypervisor, correct? > > > > Assuming it's running directly on the hardware, can you see if setting: > > hw.lazy_fpu_switch=1 > > in /boot/loader.conf makes any difference? > > > > Is there any panic message? > > > > Thanks, > > Gordon > > > _______________________________________________ > freebsd-security@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" -- С уважением, Правкин Александр ООО "Брянск Связь-ТВ" +7 (4832) 595-000 доб. 458 JID: pravkin.a@bks.tv