From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 32430C5472E for ; Mon, 26 Aug 2024 19:47:01 +0000 (UTC) Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.97.1) (envelope-from ) id 1siffp-000000000MF-2adk; Mon, 26 Aug 2024 15:46:45 -0400 Received: from mail-qk1-x731.google.com ([2607:f8b0:4864:20::731]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.97.1) (envelope-from ) id 1siffo-000000000M7-35qJ for kernelnewbies@kernelnewbies.org; Mon, 26 Aug 2024 15:46:44 -0400 Received: by mail-qk1-x731.google.com with SMTP id af79cd13be357-7a1d436c95fso282829885a.3 for ; Mon, 26 Aug 2024 12:46:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vt-edu.20230601.gappssmtp.com; s=20230601; t=1724701601; x=1725306401; darn=kernelnewbies.org; h=message-id:date:mime-version:references:in-reply-to:subject:cc:to :from:sender:from:to:cc:subject:date:message-id:reply-to; bh=ldNdAhKKzaSqr9ERET8WGas8/RLyJLHDmEozqXzjuf4=; b=kySyGNvAbTw4M1QSUSrrP6gQI3GoBXLOcdz4UANRn8tpvxG6FNVUbNTCUisT3GOIY2 UN3x8+FRyu9z9iNHzqWAKwKN8fbrfoFS3KxZs2g872iNpv6nV8XVX/2ZSm8ygY/WXrkO +0ZejjVY5dhKnVNPJ5VvEnOZPWurOVmtIqrf1KFGKdjOIyrbG7+txq2XVUusRNSga8Q0 MhcWyd0o/ynP7Dea1YRRoqT7i/ckBMXBkULpWog+jEQIP/g/QwoytImAV2kyT1qiQfkz 0wV4ddSXjWa74IP3AL9yjwkxrzu0ZsQzbaHrYMkdyFUx9S3xJuTtT0gQMo1oAv+4oNoF kwSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724701601; x=1725306401; h=message-id:date:mime-version:references:in-reply-to:subject:cc:to :from:sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ldNdAhKKzaSqr9ERET8WGas8/RLyJLHDmEozqXzjuf4=; b=FIO0b4fw/IcB4pdx+87yfAvnF3nivXdXpE7+Rp+BQ7BMzNAiXp/xNBL0eS1XWD8h8j K6/AY0wVp0Lv2dacxvPJn5ebKc7S4jVRpPYTZc6jKPmEk+cIWjyxJmUKN39e12Uvn0YT RxlASzNp6yvd+2XB8z5xWigjTsXMi2g+yV94/R24dQCI/A85wgSFHZPa52cR9M8zpv8C JL0AKxuSQAwfr1aiNLbTePJ9LpGbBvhdC5+LYby/LSIpsppbjglTPb4pHyJVzI7B6dB7 Mmf2AT1dwhH+oKvwG9JKEwmpgT/yShBsHm50QLwHvQQmSE4WmXwe1HWIEEdp41jtISM/ zRQg== X-Gm-Message-State: AOJu0Yx4g01UU5IGKP7aBmVzDHyN0XKu881OZARuvRQgIm5u8rPDAtgV ALiha2VFXpjwr65pqx+JvSHjzx3eqUb2EZATvQkAaqKyECd0qLzVm54yM6u1Wow= X-Google-Smtp-Source: AGHT+IHSt2ZDjFKsrx8cKZdACVC77PYM0eLmNVQqOPrI9VKnbgSdrVONsF4R2q9XInSB/Qof3/IWCQ== X-Received: by 2002:a05:620a:2401:b0:79e:fcb5:55e2 with SMTP id af79cd13be357-7a6896d66b9mr1306069385a.5.1724701600998; Mon, 26 Aug 2024 12:46:40 -0700 (PDT) Received: from turing-police (c-73-31-28-59.hsd1.va.comcast.net. [73.31.28.59]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7a67f41d415sm485696185a.125.2024.08.26.12.46.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Aug 2024 12:46:40 -0700 (PDT) From: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" X-Google-Original-From: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" X-Mailer: exmh version 2.10.0-pre 07/05/2021 with nmh-1.8+dev To: Muni Sekhar Subject: Re: Query Regarding Stack-Out-of-Bounds Error In-reply-to: References: Mime-Version: 1.0 Date: Mon, 26 Aug 2024 15:46:39 -0400 Message-ID: <212937.1724701599@turing-police> Cc: LKML , kernelnewbies X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kernelnewbies-bounces@kernelnewbies.org On Mon, 26 Aug 2024 18:04:39 +0530, Muni Sekhar said: > static struct cmd_info *find_cmd_entry_any_ring(struct intel_gvt *gvt, > unsigned int opcode, int rings) > { > struct cmd_info *info = NULL; > unsigned int ring; > ... > for_each_set_bit(ring, (unsigned long *)&rings, I915_NUM_ENGINES) { > > In the above code, a 32-bit integer pointer (rings) is being cast to a > 64-bit unsigned long pointer, which leads to an extra 4 bytes being > accessed. This raises a concern regarding a stack-out-of-bounds bug. > > My specific query is: While it is logically understandable that a > write operation involving these extra 4 bytes could cause a kernel > crash, in this case, it is a read operation that is occurring. Note that 'ring' is located in the stack frame for the current function. So to complete the analysis - is there any way that the stack frame can be located in such a way that 'ring' is the *very last* 4 bytes on a page, and the next page *isn't* allocated, *and* I915_NUM_ENGINES is big enough to cause the loop to walk off the end? For bonus points, part 1: Does the answer depend on whether the architecture has stacks that grow up, or grow down in address? For bonus points, part 2: can this function be called quickly enough, and enough times, that it can be abused to do something interesting to L1/L2 cache and speculative execution, because some systems will fetch not only the bytes needed, but as much as 64 or 128 bytes of cache line? Can you name 3 security bugs that abused this sort of thing? Free hint: There's a bit of interesting code in kernel/exit.c that tells you if your system has gotten close to running out of kernel stack. [/usr/src/linux-next] dmesg | grep 'greatest stack' [ 1.093400] [ T40] pgdatinit0 (40) used greatest stack depth: 13920 bytes left [ 3.832907] [ T82] modprobe (82) used greatest stack depth: 8 bytes left Hmm... wonder how that modprobe managed *that* :) _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies