From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from YT3PR01CU008.outbound.protection.outlook.com (mail-canadacentralazon11020099.outbound.protection.outlook.com [52.101.189.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 574C8451056 for ; Tue, 16 Jun 2026 16:09:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.189.99 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781626151; cv=fail; b=uoARdRUGdFCg6Bbnu+TdXnUaYMPG0wu74oF372KqyQPGfjnt5oZt9WZp0hd0WozIcj41Y5E3mZBa70XzF2JlgeFlrhX+S/dRO8MMXOJFSFVXbtBeG4keOr2vIBcjcX3IzTDnnQ4LQac1v2JyTrXO+EMLPAVE8iOJVjiA5k0gMzU= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781626151; c=relaxed/simple; bh=0ZJRKBSwAwi833NIa1HssfH2Ztvo3bVUbdrvfzGO0nQ=; h=Message-ID:Date:Subject:To:Cc:References:From:In-Reply-To: Content-Type:MIME-Version; b=I355neLfFk8DJigHJFAyGwBnX7yFTMojaYq/eVxiPgcL9ZRm2vhKNe21zazebS+JR6u/y+A0aUgxcHMU6U3crhuKjC5VDaHbllqt7e+g1cMKXybeIrt2NmUBGEfOShzPf2V/fJyP9nmgbMssvcKMmkJ5NpGKt8np9ZdddE/sqJI= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=efficios.com; spf=pass smtp.mailfrom=efficios.com; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b=Jx48IVk5; arc=fail smtp.client-ip=52.101.189.99 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=efficios.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=efficios.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b="Jx48IVk5" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=TJKVWDjoAfAI75P8hxR+RywuARwnsdr6iXs5kmkysQYit5lAzmBgjYtXmda0GJ+xMp1mdvxA2M/aKP+hrlCa1z0q5NgtXwr7mGdP4HCyjKcUO5RBadK/1uRQdnXeSILB9frF1ty3aKgwYc/t7sfArAlnekQW0aIhnl5N3JP49zcEIsHfo1DfSlrT4Xm3QUzXn3kGLHeMDpgxAtmyO5YoVnrSbASIFwlJN/AIUQ82B9JwKesraKVcZHmPBytM+7blp5qfy0WrO5dAMBmVMw67ha4qmWG4pvR4wNqafuEZkmw9G+lfg8ZbJKghQQ248Hrp/Ijceoi5XpiCjZxhQ7YGuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=eEk8JCCH/TkmYy/Fz0FCmCBrhap6QbL2eVyDj84GjWk=; b=mJwYrT0ZGtx/0yAAKP+FiuyhdaHPmjMYYAd7wWWKMz/i01SRsnKNOXnMtijDZLTkJcrUseiAkPDAR48nKexeUwB0jM0/FRblwZWZ4KVW4PQyRLtyqe6E9g8OA0IWwFMC33xjDY8RDHWkbihi2MfGt/Ek5X9e/gZTqXmTl7nnNJWWVpqzo47fjWdGnoMvoT2LqWXescilN6RfP9ZGoWcPXI9/VOJ24WsUYUPCIgYo4oDe34cem8ubZPeeC2velbDPZKiwzV+cfNVRE+GjMDwYusxZif9hLmW7bjb9ZM+GQFF7rJJTP7OAWZXAKqwaGtaauZ8VUivjhzRLnMAkqDoBiA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=efficios.com; dmarc=pass action=none header.from=efficios.com; dkim=pass header.d=efficios.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eEk8JCCH/TkmYy/Fz0FCmCBrhap6QbL2eVyDj84GjWk=; b=Jx48IVk54hrooNZBiiMP4eQhvwVV4JfYDHvBB8t9Cxabe/hIoY1u3q+5Q3K9fnRK9lcfw0XiJYHGUCkVmI4pAUAKdfHiijxDoGUZJ31lZO/tUsZFGWUqMIfe/maHRuAQ013lL2ifWZWXYnOop5bhMde89bP62+mBRUdO4F7Q89mS0pifW3e6Qs5R6Om76a+SPf8f0Jso7jeIx7uKxifV0X4POE1mybDxDPRW8Wi1ZldjkZEs87+76iMgy3XF8d6dYyX5Jw5YszHX5PEsrOzdOyR1A2jB7GNsb9ftRNetBBRXyiwti3QeOoUCWPbRjOEfjdkHRf02ws9jZfm2COLSfA== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=efficios.com; Received: from YT2PR01MB9175.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:be::5) by YT3PR01MB9915.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:8f::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.139.11; Tue, 16 Jun 2026 16:09:04 +0000 Received: from YT2PR01MB9175.CANPRD01.PROD.OUTLOOK.COM ([fe80::6004:a862:d45d:90c1]) by YT2PR01MB9175.CANPRD01.PROD.OUTLOOK.COM ([fe80::6004:a862:d45d:90c1%3]) with mapi id 15.21.0139.009; Tue, 16 Jun 2026 16:09:03 +0000 Message-ID: Date: Tue, 16 Jun 2026 12:09:02 -0400 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] sched/mmcid: fix OOB clear_bit when CID is MM_CID_UNSET in fixup path To: Rik van Riel , linux-kernel@vger.kernel.org Cc: kernel-team@meta.com, Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Thomas Gleixner , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , K Prateek Nayak References: <20260616145343.1491887-1-riel@surriel.com> From: Mathieu Desnoyers Content-Language: en-US In-Reply-To: <20260616145343.1491887-1-riel@surriel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: YT4PR01CA0500.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:10c::29) To YT2PR01MB9175.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:be::5) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: YT2PR01MB9175:EE_|YT3PR01MB9915:EE_ X-MS-Office365-Filtering-Correlation-Id: 916fbff6-4383-4f99-4c11-08decbc195ae X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|376014|1800799024|366016|23010399003|6133799003|22082099003|18002099003|3023799007|56012099006; X-Microsoft-Antispam-Message-Info: iWDQPJJT43WLe+fkMUY1FEmI3Qci6vYBJkWxqb9NCRI4TCun0kLNB1o/aPY3m/YZooUPS//uLZUy1AwbNRWAi2pTKjtevGPWf5nac9qhNflowXqGwQxgvZMtUr2ZrFGP27MQKv5cOW0/UYy78VXzAYm34ktpJI3mNz7bODIaviKcwbtM6Hoz7kKuAafn7fxaU0S5Um/rDtWFeZddRQK9NubxWUiMS2QqXqpM3s1l3pTFoAN2yCNf6T3ixBK1Lm0cvUx+Zn9UIi0qWqnQCax0s4n3POOrR9yrVtNSXo7uYPxJNBHoFNQv3Ygdmm5iu9/8AZL7iiV5qHTZMV8tFexs4ntU6ukwDHN7g7CPY++rTKYtkUbnrEmNO0jhZ318ZpRkFw80tDFE++F4zgWEBEnsIe2GmGiVR48tJKRG/N3CbLG5pm7SyR5VkVR8LC+hgBI9tpLXi/wJSuL/Q/ijnKL8fN6/7ZY7cuNW+5Gn5Yb3CLSwbpFLVhBJBMylB3g67julvybCFo1rsR+bE/4uVeUTJKeOE1NjjwvrC3euOQM6Ij9k2pVvjTBjJkA7dBzrTyg1uF1WFrgwobvCkRtS/KZykCtP2RhD4WB6AOdj2lmEC/YvavGjHNjKQri1QaY8d8ur1sXVt0Bkj4aAM80z6eA3xQ== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YT2PR01MB9175.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(1800799024)(366016)(23010399003)(6133799003)(22082099003)(18002099003)(3023799007)(56012099006);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SHRxdUl2a2hvSHB3WVRuWHovOEdrNVhSYzRHaDhOSW13YnNkeEJPL1gvS0RF?= =?utf-8?B?ZWJQQ05aN29pc1JWbUprTGQzd3ptMTlCNno5OWdhZzZUbWNvS2R3dHZ0OE1a?= =?utf-8?B?YncySWFYSWJHdTVxa2w3TjhqWTBkeFVUR0VsaVViVmxOc3pBMjJqbjJuVjhQ?= =?utf-8?B?SHJkYlNYM3JVa3FlNUF0YVdZREVxWFlsbTZMbmgvQXRZV1AzZjFJZHRWSzBD?= =?utf-8?B?eUpSYjNBanpkdlYyWlNESWlVYjRYSW43SHlBNE9qM3k5WFZRRlI2bGZRTEpO?= =?utf-8?B?emlsTWgrcmRjeFBhSVV6U0RUM0lZbjYzZ21FLy9CWHJLOXBUM3o3NE5LVFdz?= =?utf-8?B?RG1LUVdFaytjVnhuZ2JheFhHL2VhZ24zMFFFc2RIOFIvMkNTNkJua21WeVRy?= =?utf-8?B?YUpWMXMxc1p5c0grU1RKK1hqSmtYcytlRWU4dTJIUnZ2ajFkbEdKRDMwTXdm?= =?utf-8?B?VnNlQXNFcWlrbDkrWEo0ZEhtZ2tIdWQ4bVFlMHZBUUtxanlFb1c3MElpc3Iv?= =?utf-8?B?VmMxMlE3ZXZDUHBkbVc4a1VpQktOZUUrYnFEclNiKzdGazRpbUlLMnE2bUxF?= =?utf-8?B?UWpaazRoejVBRVRUZUIwVlFPV0VzR212NHM5UkhxYVJIZld5elNoaTdReVJa?= =?utf-8?B?WmFTd0t2UEUvSGt6dkVuOGpIenowelluUE5jSExrNnhIOENMYjdWZGJ1MUFq?= =?utf-8?B?amdZYUJKeGkyeGdMOUo2NGR4SjBadm1NQTAxbXd1eDNnVzZtVnBqWVdJVTdS?= =?utf-8?B?VTV1REo2WmF3MytGT2xSM0JEdnFJNEloSkFkR0lMdGgyejNJcnhZdWljdlVW?= =?utf-8?B?UVdOYmJRbnZRd3dtS1NIeTdueUc0L3JRUzZuRDZxSnp0cnhoWDlqeTZRZ0FB?= =?utf-8?B?bURyMCt5RXVzZi9iTmkrcDhvTGZjSEh6OVhXTGdveUJGRVA0dXFLNlM2c1Ux?= =?utf-8?B?QXR1VXppL1lldVo4eW4zZjlKU1A5UlJYdTU3aVU3azVmTThjT0gzMXJvakJB?= =?utf-8?B?bmtSMm8veHNLRHRmTG5BVFlQQ25pMXRhWTdmRjBYZENQSlNFMWJ6Z0NmejNS?= =?utf-8?B?SldGcG5SZzJvcllsYjU3czVrclQxZmttalprZ08weG9ybWFEYjQySnY0eHRX?= =?utf-8?B?MzRtazdSOHBKa2Y2SFkyRjNyUkhqNkE1a2ZmdlJiZndFZ2w3VzZEWTBydXA2?= =?utf-8?B?OEx2SWhaNHpzWUhJTGJTQmtvbGppb25aOWxNeVczVDIvU3FjcURmWE5wNmFO?= =?utf-8?B?T0NXczVYcjF5S1ZERkx3VWxEeDR1dy9mU3BYUmxldExOUjhoOE5TUXBrWXE3?= =?utf-8?B?eEhOYyttZXVVaG45YnpLTXZPZ0xoK3djZmtTUEhrSDU2NTlDNVkyQlFOQkg0?= =?utf-8?B?WUZLR21FS0xzbGtmdXVmcVhTWDJ3M2Q0SVF1dWw1WTlSdzNiTFpDamdtYnpE?= =?utf-8?B?bzFrdTJxUDMwcHE0SEdWVDVLekN3bjVCME55YkdKYkJabmJ3cHh4eFlkZnJ6?= =?utf-8?B?TXpkMXN0MEt3UXlyOFp4Y2wrUnRSbFd3NHhMOS90cUZKZ2xsekQ4UDcvNUZ6?= =?utf-8?B?dHB1bnhOaHVSUWo3KzJCMUlnWDd1eUhjZ04xVXhDejhGTnd0S2JCcXhIaU1F?= =?utf-8?B?ZGd0cjF4UlNhOUtZTG40bHd3NDB0WGJ6ZXZtTXJlT3VncXZGY0VaRnNYVnpH?= =?utf-8?B?S3ZZTXppc0NqWmtxN2xkYk5Uc0NTd3p5dnRaRUt0Z1J3VzgzWFdYSnhzcHl3?= =?utf-8?B?NG1qWkVKTEUxS0RZaGZzVjNWczRWSzFCZzJ2YlgvYW84MmNGdnJuNkdzZmho?= =?utf-8?B?YlY4RTRsYzJEdm5iYkh4aVQvSXRXN1YwODNndmhrRmZhWXcwU3JPRHEyUU42?= =?utf-8?B?dmhEaDlVMFR6M3p3bmJoRVpkbm9MTW5qZ2ZYbFlGaFNtOXUvOHVnNzBFZDJG?= =?utf-8?B?SWtUU2Qvc1NRd2FlOVQ3azVSSmFocEp2NjY3NjRmYkRBdGhTUTdyYkVBV0VL?= =?utf-8?B?ODFZTkJyNWI5S0J3Nk5xMThjcmJzM2VuZG4zZWI4ZFBhVHF0b0xJT0ljWk9l?= =?utf-8?B?QURxc0xVYy80MzJKSzFSMDFrU1VVaUhXelJreXptU282N3J0QjNwWXl3NzNp?= =?utf-8?B?WDBnd296Zm1FSUlmTjdjZVRveDlxNVRDN1dEano1OW1rbUdDRVAzQStPazJ5?= =?utf-8?B?OGtvMFFRTTNMWTBsZVlmRm9PaDhDdlA4SGV6U1JqQnFwLzJWQ2Y5eXFra0Nh?= =?utf-8?B?YlhYWEFSZlZ3a0dxbm81WFNMVTBIcW1DTU1aOVBFNTNxSjhwR04vMlRORW5K?= =?utf-8?B?NGsyM3F5cDUwbDJiTnVoTG1VWWR2c0pGc0tNMWtyQ0N2UXZqKzJtbHJWOWs1?= =?utf-8?Q?ABcL1h5ERD+mTGQI5tQ7VgDQmVYW81xGsnkfA?= X-OriginatorOrg: efficios.com X-MS-Exchange-CrossTenant-Network-Message-Id: 916fbff6-4383-4f99-4c11-08decbc195ae X-MS-Exchange-CrossTenant-AuthSource: YT2PR01MB9175.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jun 2026 16:09:03.5885 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4f278736-4ab6-415c-957e-1f55336bd31e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: QgkhiOwfhJZ/dIh4nGVto0u0/apZWfJ6zJrezueCfkePr99vD76MjIS/qBvzru7qbGUmU8srHWImpQ5oxXlmK5OjtELLkctJvzHsmEzfStU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT3PR01MB9915 On 2026-06-16 10:53, Rik van Riel wrote: > In mm_cid_fixup_cpus_to_tasks(), when rq->curr has the target mm and > mm_cid.active is set, the CID is checked with cid_in_transit() before > setting the transition bit. In per-CPU mode a newly forked or exec'd > task can be running with mm_cid.cid == MM_CID_UNSET because CIDs are > assigned lazily on schedule-in. With cid_in_transit() the guard passes > for MM_CID_UNSET (no transit bit), converts it to MM_CID_UNSET | > MM_CID_TRANSIT and stores it back; later mm_cid_schedout() feeds this > to clear_bit() with MM_CID_UNSET as the bit number, triggering an > out-of-bounds write. > > Symptoms: this is genuine memory corruption, but a bounded out-of-bounds > write, not an arbitrary one. MM_CID_UNSET is the fixed sentinel BIT(31), > so once the bad value reaches mm_cid_schedout() the cid_from_transit_cid() > strip leaves MM_CID_UNSET, which fails the "cid < max_cids" convergence > test and falls into mm_drop_cid() -> clear_bit(MM_CID_UNSET, > mm_cidmask(mm)). The cid bitmap is embedded in the mm_struct slab object > (after cpu_bitmap and mm_cpus_allowed) and is only num_possible_cpus() > bits wide, so clearing bit 31 is a deterministic OOB bit-clear at a > fixed offset of 2^31 / 8 == 256 MiB past the bitmap base. The address is > not attacker-influenced (fixed sentinel -> fixed offset) and the op only > clears a single bit; what sits 256 MiB further along the direct map is > whatever kernel object happens to live there, so this corrupts one bit of > unpredictable kernel memory -- it is not an arbitrary-address or > arbitrary-value write. > > It triggers only in per-CPU CID mode, when a CPU is running an active > task of the target mm whose cid is still MM_CID_UNSET -- the > fork()/execve() window before that task's next schedule-in assigns it a > real CID -- and a per-CPU -> per-task fixup walks over it (the mode > fallback driven by a thread exit, sched_mm_cid_exit(), or by the deferred > max_cids recompute in mm_cid_work_fn()). > > In practice syzkaller surfaced it as a KASAN use-after-free reported in > __schedule -> mm_cid_switch_to, where the offending clear_bit() is inlined > via mm_cid_schedout() -> mm_drop_cid(). > > Switch to cid_on_task() which excludes MM_CID_UNSET, MM_CID_ONCPU, and > MM_CID_TRANSIT, so we only set the transition bit on a genuine > task-owned CID. [...] > --- > kernel/sched/core.c | 15 +++++++++++++-- > 1 file changed, 13 insertions(+), 2 deletions(-) > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > index 8b791e9e9f67..4c8b6ca254ce 100644 > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -10909,8 +10909,19 @@ static void mm_cid_fixup_cpus_to_tasks(struct mm_struct *mm) > } else if (rq->curr->mm == mm && rq->curr->mm_cid.active) { > unsigned int cid = rq->curr->mm_cid.cid; > > - /* Ensure it has the transition bit set */ > - if (!cid_in_transit(cid)) { > + /* > + * Only a genuine task-owned CID needs the transition > + * bit. A running active task can legitimately have > + * MM_CID_UNSET here: in per-CPU mode CIDs are assigned > + * lazily on schedule-in, so fork()/execve() leave the > + * task active with no owned CID until its next > + * schedule-in. cid_on_task() excludes the > + * MM_CID_UNSET/ONCPU/TRANSIT bits, so we never turn > + * e.g. MM_CID_UNSET into MM_CID_UNSET|MM_CID_TRANSIT, > + * which mm_cid_schedout() would later feed to > + * clear_bit() as an out-of-bounds bit number. > + */ > + if (cid_on_task(cid)) { I agree that something is wrong with the "unset" bit handling here, but I'm not sure I fully understand why we would gate the "fixup_cpus_to_tasks" on "cid_on_task()". AFAIU there are the following relevant states: - cid_on_task: True if none of the MM_CID_ONCPU, MM_CID_TRANSIT, MM_CID_UNSET bits is set - MM_CID_TRANSIT: what this fixup aims to set if not already set. - MM_CID_UNSET: tag indicating that the mm_cid is unset. This triggers the issue here because the "!cid_in_transit(cid)" check does not cover it. - MM_CID_ONCPU: tag indicating that the cid is on cpu. Technically the "origin" state we are trying to transition from. The cid_on_task() check will eliminate the "unset" case, but will also eliminate the "oncpu" case, which I suspect is the initial state we want to transition from. Did you try changing this to the following (completely untested) check instead: if (!cid_in_transit(cid) && !(cid & MM_CID_UNSET)) { ? Thanks, Mathieu > cid = cid_to_transit_cid(cid); > rq->curr->mm_cid.cid = cid; > pcp->cid = cid; -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com