From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 4E171398A42F; Thu, 3 Jun 2021 05:54:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4E171398A42F From: "siddhesh at sourceware dot org" To: glibc-bugs@sourceware.org Subject: [Bug nptl/27896] mq_notify does not handle separately allocated thread attributes (CVE-2021-33574) Date: Thu, 03 Jun 2021 05:54:38 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nptl X-Bugzilla-Version: 2.34 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: siddhesh at sourceware dot org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: 2.34 X-Bugzilla-Flags: security+ X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2021 05:54:38 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D27896 --- Comment #4 from Siddhesh Poyarekar --- Fixed commits: https://sourceware.org/git/?p=3Dglibc.git;a=3Dcommit;h=3D42d359350510506b87= 101cf77202fefcbfc790cb https://sourceware.org/git/?p=3Dglibc.git;a=3Dcommit;h=3D217b6dc298156bdb0d= 6aea9ea93e7e394a5ff091 A note on the security impact based on my analysis of the bug. In order to mount a minimal attack using this flaw, an attacker needs many pre-requisites to be able to even crash a program using this mq_notify bug: 1. The program call to mq_notify needs to be controlled by the attacker 2. The program must provide attributes to control creation of the notification thread in mq_notify 3. The program must have the race condition where it may potentially destroy the notification thread attributes before the notification thread is created 4. The program must set CPU affinity or signal mask of the notification thread to actually cause the use-after-free dereference There are no known applications in distributions that have *all* these pre-requisites and it's quite rare to have all of those conditions together, so I reckon the attack complexity is very high. In the worst (or theoretical) case that such an application exists, an attacker would at best be able to control on which CPU the notification thread runs; the signal mask, even if set is overwritten (i.e. all signals unblocked) before the notification function is called. The change in scheduling should not have an impact on confidentiality or integrity of a compliant application. --=20 You are receiving this mail because: You are on the CC list for the bug.=