From nobody Sat Apr 11 15:26:33 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A2A3EC19F2D for ; Tue, 9 Aug 2022 18:09:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343993AbiHISJH (ORCPT ); Tue, 9 Aug 2022 14:09:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53034 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345038AbiHISIf (ORCPT ); Tue, 9 Aug 2022 14:08:35 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5232926556; Tue, 9 Aug 2022 11:03:32 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id ED61261118; Tue, 9 Aug 2022 18:03:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 65754C433D6; Tue, 9 Aug 2022 18:03:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068211; bh=pKGNa/7akYFG3JtPthS6ZvcLNCEiB9Sy7wDPP9iBe9o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kIoBIRM2vJt5HIwz3YVbC1oJzmOlrq+5zT5rE0PoX16wLphOHQCVVmJb8hSkhADgY tLAFXGw67t3Vd9ZSUlpSQk/ZlA8ss+oN7SZ8ZchIn5FItusu40g9TbZUjJ/Z/Ga1R+ Js/ExIdCsIROrjLOkpaSL/fFk4yiu0WUKR8WgOf8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, David Collins , Subbaraman Narayanamurthy , Daniel Lezcano , "Rafael J. Wysocki" , Mark-PK Tsai Subject: [PATCH 5.4 01/15] thermal: Fix NULL pointer dereferences in of_thermal_ functions Date: Tue, 9 Aug 2022 20:00:19 +0200 Message-Id: <20220809175510.361664166@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175510.312431319@linuxfoundation.org> References: <20220809175510.312431319@linuxfoundation.org> User-Agent: quilt/0.66 X-stable: review X-Patchwork-Hint: ignore MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Subbaraman Narayanamurthy commit 96cfe05051fd8543cdedd6807ec59a0e6c409195 upstream. of_parse_thermal_zones() parses the thermal-zones node and registers a thermal_zone device for each subnode. However, if a thermal zone is consuming a thermal sensor and that thermal sensor device hasn't probed yet, an attempt to set trip_point_*_temp for that thermal zone device can cause a NULL pointer dereference. Fix it. console:/sys/class/thermal/thermal_zone87 # echo 120000 > trip_point_0_temp ... Unable to handle kernel NULL pointer dereference at virtual address 000000= 0000000020 ... Call trace: of_thermal_set_trip_temp+0x40/0xc4 trip_point_temp_store+0xc0/0x1dc dev_attr_store+0x38/0x88 sysfs_kf_write+0x64/0xc0 kernfs_fop_write_iter+0x108/0x1d0 vfs_write+0x2f4/0x368 ksys_write+0x7c/0xec __arm64_sys_write+0x20/0x30 el0_svc_common.llvm.7279915941325364641+0xbc/0x1bc do_el0_svc+0x28/0xa0 el0_svc+0x14/0x24 el0_sync_handler+0x88/0xec el0_sync+0x1c0/0x200 While at it, fix the possible NULL pointer dereference in other functions as well: of_thermal_get_temp(), of_thermal_set_emul_temp(), of_thermal_get_trend(). Suggested-by: David Collins Signed-off-by: Subbaraman Narayanamurthy Acked-by: Daniel Lezcano Signed-off-by: Rafael J. Wysocki Signed-off-by: Mark-PK Tsai Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/thermal/of-thermal.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) --- a/drivers/thermal/of-thermal.c +++ b/drivers/thermal/of-thermal.c @@ -91,7 +91,7 @@ static int of_thermal_get_temp(struct th { struct __thermal_zone *data =3D tz->devdata; =20 - if (!data->ops->get_temp) + if (!data->ops || !data->ops->get_temp) return -EINVAL; =20 return data->ops->get_temp(data->sensor_data, temp); @@ -188,6 +188,9 @@ static int of_thermal_set_emul_temp(stru { struct __thermal_zone *data =3D tz->devdata; =20 + if (!data->ops || !data->ops->set_emul_temp) + return -EINVAL; + return data->ops->set_emul_temp(data->sensor_data, temp); } =20 @@ -196,7 +199,7 @@ static int of_thermal_get_trend(struct t { struct __thermal_zone *data =3D tz->devdata; =20 - if (!data->ops->get_trend) + if (!data->ops || !data->ops->get_trend) return -EINVAL; =20 return data->ops->get_trend(data->sensor_data, trip, trend); @@ -336,7 +339,7 @@ static int of_thermal_set_trip_temp(stru if (trip >=3D data->ntrips || trip < 0) return -EDOM; =20 - if (data->ops->set_trip_temp) { + if (data->ops && data->ops->set_trip_temp) { int ret; =20 ret =3D data->ops->set_trip_temp(data->sensor_data, trip, temp); From nobody Sat Apr 11 15:26:33 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 78669C25B07 for ; Tue, 9 Aug 2022 18:07:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344857AbiHISHj (ORCPT ); Tue, 9 Aug 2022 14:07:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43954 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344853AbiHISG4 (ORCPT ); Tue, 9 Aug 2022 14:06:56 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 361FB2611B; Tue, 9 Aug 2022 11:03:03 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id A23F7CE18A6; Tue, 9 Aug 2022 18:03:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D66E6C433D7; Tue, 9 Aug 2022 18:03:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068181; bh=t6omEt3IXRTOqFA+8zsUIm7gKxitv9ZMWRIYZ/i/uR4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bV8b7VwwtcldX63Hw6JKShsr9hbe45zk787KQ4uKeFv0lSIMjGV4//LlCAuq1NSgG NZ9gffEXU3E7COY1c0YApJJgvmq5/YwyABUPNi5bRQ2q0dOwpXvlEOJU3SIx//eI9h yV+dtdb5f722jK7xo0LmTdgaqgGlTVEKiKygTlzM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Werner Sembach , Hans de Goede , "Rafael J. Wysocki" Subject: [PATCH 5.4 02/15] ACPI: video: Force backlight native for some TongFang devices Date: Tue, 9 Aug 2022 20:00:20 +0200 Message-Id: <20220809175510.391904671@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175510.312431319@linuxfoundation.org> References: <20220809175510.312431319@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Werner Sembach commit c752089f7cf5b5800c6ace4cdd1a8351ee78a598 upstream. The TongFang PF5PU1G, PF4NU1F, PF5NU1G, and PF5LUXG/TUXEDO BA15 Gen10, Pulse 14/15 Gen1, and Pulse 15 Gen2 have the same problem as the Clevo NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2: They have a working native and video interface. However the default detection mechanism first registers the video interface before unregistering it again and switching to the native interface during boot. This results in a dangling SBIOS request for backlight change for some reason, causing the backlight to switch to ~2% once per boot on the first power cord connect or disconnect event. Setting the native interface explicitly circumvents this buggy behaviour by avoiding the unregistering process. Signed-off-by: Werner Sembach Cc: All applicable Reviewed-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/acpi/video_detect.c | 51 +++++++++++++++++++++++++++++++++++++++= ++++- 1 file changed, 50 insertions(+), 1 deletion(-) --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -447,7 +447,56 @@ static const struct dmi_system_id video_ DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"), }, }, - + /* + * The TongFang PF5PU1G, PF4NU1F, PF5NU1G, and PF5LUXG/TUXEDO BA15 Gen10, + * Pulse 14/15 Gen1, and Pulse 15 Gen2 have the same problem as the Clevo + * NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2. See the description + * above. + */ + { + .callback =3D video_detect_force_native, + .ident =3D "TongFang PF5PU1G", + .matches =3D { + DMI_MATCH(DMI_BOARD_NAME, "PF5PU1G"), + }, + }, + { + .callback =3D video_detect_force_native, + .ident =3D "TongFang PF4NU1F", + .matches =3D { + DMI_MATCH(DMI_BOARD_NAME, "PF4NU1F"), + }, + }, + { + .callback =3D video_detect_force_native, + .ident =3D "TongFang PF4NU1F", + .matches =3D { + DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"), + DMI_MATCH(DMI_BOARD_NAME, "PULSE1401"), + }, + }, + { + .callback =3D video_detect_force_native, + .ident =3D "TongFang PF5NU1G", + .matches =3D { + DMI_MATCH(DMI_BOARD_NAME, "PF5NU1G"), + }, + }, + { + .callback =3D video_detect_force_native, + .ident =3D "TongFang PF5NU1G", + .matches =3D { + DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"), + DMI_MATCH(DMI_BOARD_NAME, "PULSE1501"), + }, + }, + { + .callback =3D video_detect_force_native, + .ident =3D "TongFang PF5LUXG", + .matches =3D { + DMI_MATCH(DMI_BOARD_NAME, "PF5LUXG"), + }, + }, /* * Desktops which falsely report a backlight and which our heuristics * for this do not catch. From nobody Sat Apr 11 15:26:33 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 27244C19F2D for ; Tue, 9 Aug 2022 18:08:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344142AbiHISH5 (ORCPT ); Tue, 9 Aug 2022 14:07:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44122 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343758AbiHISHH (ORCPT ); Tue, 9 Aug 2022 14:07:07 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3C9C9A46D; Tue, 9 Aug 2022 11:03:10 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id ECD1161012; Tue, 9 Aug 2022 18:03:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 64F64C433D7; Tue, 9 Aug 2022 18:03:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068189; bh=dGnVn5Z9grRssWnblV0hmoYJQANPk3JcoW+xhK13lyo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fiMOiOQLaWrcOXeHbg8zKxiK4BmLh7xlX0P6Jd+OIZmj8GLPiP5MFrQTOEdZXvJZa Im6KjGl2A7eoiiajleW00Er2E5cq0EcWXgPiLI8+2U4CpzO99mbmSwvEmGqipQuhxl BPCGXrA7gdghqK1kISxRZJLgPS4t+M0SOM091d4U= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Werner Sembach , Hans de Goede , "Rafael J. Wysocki" Subject: [PATCH 5.4 03/15] ACPI: video: Shortening quirk list by identifying Clevo by board_name only Date: Tue, 9 Aug 2022 20:00:21 +0200 Message-Id: <20220809175510.421778760@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175510.312431319@linuxfoundation.org> References: <20220809175510.312431319@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Werner Sembach commit f0341e67b3782603737f7788e71bd3530012a4f4 upstream. Taking a recent change in the i8042 quirklist to this one: Clevo board_names are somewhat unique, and if not: The generic Board_-/Sys_Vendor string "Notebook" doesn't help much anyway. So identifying the devices just by the board_name helps keeping the list significantly shorter and might even hit more devices requiring the fix. Signed-off-by: Werner Sembach Fixes: c844d22fe0c0 ("ACPI: video: Force backlight native for Clevo NL5xRU = and NL5xNU") Cc: All applicable Reviewed-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/acpi/video_detect.c | 34 ---------------------------------- 1 file changed, 34 deletions(-) --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -387,23 +387,6 @@ static const struct dmi_system_id video_ .callback =3D video_detect_force_native, .ident =3D "Clevo NL5xRU", .matches =3D { - DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"), - DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"), - }, - }, - { - .callback =3D video_detect_force_native, - .ident =3D "Clevo NL5xRU", - .matches =3D { - DMI_MATCH(DMI_SYS_VENDOR, "SchenkerTechnologiesGmbH"), - DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"), - }, - }, - { - .callback =3D video_detect_force_native, - .ident =3D "Clevo NL5xRU", - .matches =3D { - DMI_MATCH(DMI_SYS_VENDOR, "Notebook"), DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"), }, }, @@ -427,23 +410,6 @@ static const struct dmi_system_id video_ .callback =3D video_detect_force_native, .ident =3D "Clevo NL5xNU", .matches =3D { - DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"), - DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"), - }, - }, - { - .callback =3D video_detect_force_native, - .ident =3D "Clevo NL5xNU", - .matches =3D { - DMI_MATCH(DMI_SYS_VENDOR, "SchenkerTechnologiesGmbH"), - DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"), - }, - }, - { - .callback =3D video_detect_force_native, - .ident =3D "Clevo NL5xNU", - .matches =3D { - DMI_MATCH(DMI_SYS_VENDOR, "Notebook"), DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"), }, }, From nobody Sat Apr 11 15:26:33 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 86819C25B07 for ; Tue, 9 Aug 2022 18:08:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343572AbiHISIS (ORCPT ); Tue, 9 Aug 2022 14:08:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43738 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344847AbiHISHd (ORCPT ); Tue, 9 Aug 2022 14:07:33 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BD9EF286FD; Tue, 9 Aug 2022 11:03:15 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id D4240B8171C; Tue, 9 Aug 2022 18:03:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 22CC6C433B5; Tue, 9 Aug 2022 18:03:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068192; bh=aS6kC7/UR/+s4cEQ6IbqOtahiGkvu5P7CX0AzJ/IWIM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=z1rJ4JUnnQU/tn7l9itxmDDqum3h0gn8/ZUB/ARX/biXW9W18qJeniXuKMTilLr7w BpXlk6r3xQD5tBu7hZmE5D5NXkxcKUSRKModiam+Xuvfrb9lznl9VGRveJiRAE3bdh wzz7eZkp7qOMHJB3MhuouNZ54ItfdHMjA4/wuqNw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Tony Luck , "Rafael J. Wysocki" Subject: [PATCH 5.4 04/15] ACPI: APEI: Better fix to avoid spamming the console with old error logs Date: Tue, 9 Aug 2022 20:00:22 +0200 Message-Id: <20220809175510.451207033@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175510.312431319@linuxfoundation.org> References: <20220809175510.312431319@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Tony Luck commit c3481b6b75b4797657838f44028fd28226ab48e0 upstream. The fix in commit 3f8dec116210 ("ACPI/APEI: Limit printable size of BERT table data") does not work as intended on systems where the BIOS has a fixed size block of memory for the BERT table, relying on s/w to quit when it finds a record with estatus->block_status =3D=3D 0. On these systems all errors are suppressed because the check: if (region_len < ACPI_BERT_PRINT_MAX_LEN) always fails. New scheme skips individual CPER records that are too large, and also limits the total number of records that will be printed to 5. Fixes: 3f8dec116210 ("ACPI/APEI: Limit printable size of BERT table data") Cc: All applicable Signed-off-by: Tony Luck Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/acpi/apei/bert.c | 31 +++++++++++++++++++++++-------- 1 file changed, 23 insertions(+), 8 deletions(-) --- a/drivers/acpi/apei/bert.c +++ b/drivers/acpi/apei/bert.c @@ -29,16 +29,26 @@ =20 #undef pr_fmt #define pr_fmt(fmt) "BERT: " fmt + +#define ACPI_BERT_PRINT_MAX_RECORDS 5 #define ACPI_BERT_PRINT_MAX_LEN 1024 =20 static int bert_disable; =20 +/* + * Print "all" the error records in the BERT table, but avoid huge spam to + * the console if the BIOS included oversize records, or too many records. + * Skipping some records here does not lose anything because the full + * data is available to user tools in: + * /sys/firmware/acpi/tables/data/BERT + */ static void __init bert_print_all(struct acpi_bert_region *region, unsigned int region_len) { struct acpi_hest_generic_status *estatus =3D (struct acpi_hest_generic_status *)region; int remain =3D region_len; + int printed =3D 0, skipped =3D 0; u32 estatus_len; =20 while (remain >=3D sizeof(struct acpi_bert_region)) { @@ -46,24 +56,26 @@ static void __init bert_print_all(struct if (remain < estatus_len) { pr_err(FW_BUG "Truncated status block (length: %u).\n", estatus_len); - return; + break; } =20 /* No more error records. */ if (!estatus->block_status) - return; + break; =20 if (cper_estatus_check(estatus)) { pr_err(FW_BUG "Invalid error record.\n"); - return; + break; } =20 - pr_info_once("Error records from previous boot:\n"); - if (region_len < ACPI_BERT_PRINT_MAX_LEN) + if (estatus_len < ACPI_BERT_PRINT_MAX_LEN && + printed < ACPI_BERT_PRINT_MAX_RECORDS) { + pr_info_once("Error records from previous boot:\n"); cper_estatus_print(KERN_INFO HW_ERR, estatus); - else - pr_info_once("Max print length exceeded, table data is available at:\n" - "/sys/firmware/acpi/tables/data/BERT"); + printed++; + } else { + skipped++; + } =20 /* * Because the boot error source is "one-time polled" type, @@ -75,6 +87,9 @@ static void __init bert_print_all(struct estatus =3D (void *)estatus + estatus_len; remain -=3D estatus_len; } + + if (skipped) + pr_info(HW_ERR "Skipped %d error records\n", skipped); } =20 static int __init setup_bert_disable(char *str) From nobody Sat Apr 11 15:26:33 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 01282C19F2D for ; Tue, 9 Aug 2022 18:08:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344345AbiHISIL (ORCPT ); Tue, 9 Aug 2022 14:08:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41450 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344918AbiHISHd (ORCPT ); Tue, 9 Aug 2022 14:07:33 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BDC1E286FE; Tue, 9 Aug 2022 11:03:15 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 805846109E; Tue, 9 Aug 2022 18:03:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EBE51C43470; Tue, 9 Aug 2022 18:03:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068195; bh=kstU9LTQm5O5mokQH2ycrKzFS0gB6EdhvNLItgTGQ0Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Pt+jwiebCZIpKQxiW72MtuKf/x72CKsb6NGffiuxPECGxuKxteXOkzPK79flBBkk4 QrG7GH4ynNrSGn75kvIzHaeUtQ/sO2v6wq3n2yv7Rz+CP7gchPLu67ELf7Gnf6g6jQ 0V1yCspXsdlb6rC4Vsbvot9AW4zzo3nLB0qcZ5s8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Greg Kroah-Hartman , John Fastabend , Alexei Starovoitov , Ovidiu Panait Subject: [PATCH 5.4 05/15] bpf: Verifer, adjust_scalar_min_max_vals to always call update_reg_bounds() Date: Tue, 9 Aug 2022 20:00:23 +0200 Message-Id: <20220809175510.492285257@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175510.312431319@linuxfoundation.org> References: <20220809175510.312431319@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: John Fastabend commit 294f2fc6da27620a506e6c050241655459ccd6bd upstream. Currently, for all op verification we call __red_deduce_bounds() and __red_bound_offset() but we only call __update_reg_bounds() in bitwise ops. However, we could benefit from calling __update_reg_bounds() in BPF_ADD, BPF_SUB, and BPF_MUL cases as well. For example, a register with state 'R1_w=3DinvP0' when we subtract from it, w1 -=3D 2 Before coerce we will now have an smin_value=3DS64_MIN, smax_value=3DU64_MAX and unsigned bounds umin_value=3D0, umax_value=3DU64_MAX. These will then be clamped to S32_MIN, U32_MAX values by coerce in the case of alu32 op as done in above example. However tnum will be a constant because the ALU op is done on a constant. Without update_reg_bounds() we have a scenario where tnum is a const but our unsigned bounds do not reflect this. By calling update_reg_bounds after coerce to 32bit we further refine the umin_value to U64_MAX in the alu64 case or U32_MAX in the alu32 case above. Signed-off-by: John Fastabend Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/158507151689.15666.566796274289413203.stg= it@john-Precision-5820-Tower Signed-off-by: Ovidiu Panait Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- kernel/bpf/verifier.c | 1 + 1 file changed, 1 insertion(+) --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -5083,6 +5083,7 @@ static int adjust_scalar_min_max_vals(st coerce_reg_to_size(dst_reg, 4); } =20 + __update_reg_bounds(dst_reg); __reg_deduce_bounds(dst_reg); __reg_bound_offset(dst_reg); return 0; From nobody Sat Apr 11 15:26:33 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EA07DC19F2D for ; Tue, 9 Aug 2022 18:08:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345028AbiHISIX (ORCPT ); Tue, 9 Aug 2022 14:08:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53394 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344950AbiHISHh (ORCPT ); Tue, 9 Aug 2022 14:07:37 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0C84126127; Tue, 9 Aug 2022 11:03:18 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 9B09A6109E; Tue, 9 Aug 2022 18:03:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AA6C6C43141; Tue, 9 Aug 2022 18:03:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068198; bh=qZI/HCcpqu709ggT6c59DUUyye8IfMFVlk3MUijuPCw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kk3Wztv/qItESayAuQi2o+6wBdSV7dV2c4hW3ndnL7S3ZnHKbvoGvOA4ISaRLEUIl vAhcWLQojDHR3ytJT7X7oAqv7d1CJQKzs8NeZ0o+byvyKdY12P3WklfJPEOOS8nmba teT6FTfARZ8zwIionmI/HwVrqEz86r0kukV7Er4Q= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Greg Kroah-Hartman , Jakub Sitnicki , Alexei Starovoitov , Ovidiu Panait Subject: [PATCH 5.4 06/15] selftests/bpf: Extend verifier and bpf_sock tests for dst_port loads Date: Tue, 9 Aug 2022 20:00:24 +0200 Message-Id: <20220809175510.524294688@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175510.312431319@linuxfoundation.org> References: <20220809175510.312431319@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Jakub Sitnicki commit 8f50f16ff39dd4e2d43d1548ca66925652f8aff7 upstream. Add coverage to the verifier tests and tests for reading bpf_sock fields to ensure that 32-bit, 16-bit, and 8-bit loads from dst_port field are allowed only at intended offsets and produce expected values. While 16-bit and 8-bit access to dst_port field is straight-forward, 32-bit wide loads need be allowed and produce a zero-padded 16-bit value for backward compatibility. Signed-off-by: Jakub Sitnicki Link: https://lore.kernel.org/r/20220130115518.213259-3-jakub@cloudflare.com Signed-off-by: Alexei Starovoitov [OP: backport to 5.4: cherry-pick verifier changes only] Signed-off-by: Ovidiu Panait Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- tools/include/uapi/linux/bpf.h | 3 - tools/testing/selftests/bpf/verifier/sock.c | 81 +++++++++++++++++++++++= +++-- 2 files changed, 80 insertions(+), 4 deletions(-) --- a/tools/include/uapi/linux/bpf.h +++ b/tools/include/uapi/linux/bpf.h @@ -3068,7 +3068,8 @@ struct bpf_sock { __u32 src_ip4; __u32 src_ip6[4]; __u32 src_port; /* host byte order */ - __u32 dst_port; /* network byte order */ + __be16 dst_port; /* network byte order */ + __u16 :16; /* zero padding */ __u32 dst_ip4; __u32 dst_ip6[4]; __u32 state; --- a/tools/testing/selftests/bpf/verifier/sock.c +++ b/tools/testing/selftests/bpf/verifier/sock.c @@ -121,7 +121,25 @@ .result =3D ACCEPT, }, { - "sk_fullsock(skb->sk): sk->dst_port [narrow load]", + "sk_fullsock(skb->sk): sk->dst_port [word load] (backward compatibility)", + .insns =3D { + BPF_LDX_MEM(BPF_DW, BPF_REG_1, BPF_REG_1, offsetof(struct __sk_buff, sk)), + BPF_JMP_IMM(BPF_JNE, BPF_REG_1, 0, 2), + BPF_MOV64_IMM(BPF_REG_0, 0), + BPF_EXIT_INSN(), + BPF_EMIT_CALL(BPF_FUNC_sk_fullsock), + BPF_JMP_IMM(BPF_JNE, BPF_REG_0, 0, 2), + BPF_MOV64_IMM(BPF_REG_0, 0), + BPF_EXIT_INSN(), + BPF_LDX_MEM(BPF_W, BPF_REG_0, BPF_REG_0, offsetof(struct bpf_sock, dst_po= rt)), + BPF_MOV64_IMM(BPF_REG_0, 0), + BPF_EXIT_INSN(), + }, + .prog_type =3D BPF_PROG_TYPE_CGROUP_SKB, + .result =3D ACCEPT, +}, +{ + "sk_fullsock(skb->sk): sk->dst_port [half load]", .insns =3D { BPF_LDX_MEM(BPF_DW, BPF_REG_1, BPF_REG_1, offsetof(struct __sk_buff, sk)), BPF_JMP_IMM(BPF_JNE, BPF_REG_1, 0, 2), @@ -139,7 +157,64 @@ .result =3D ACCEPT, }, { - "sk_fullsock(skb->sk): sk->dst_port [load 2nd byte]", + "sk_fullsock(skb->sk): sk->dst_port [half load] (invalid)", + .insns =3D { + BPF_LDX_MEM(BPF_DW, BPF_REG_1, BPF_REG_1, offsetof(struct __sk_buff, sk)), + BPF_JMP_IMM(BPF_JNE, BPF_REG_1, 0, 2), + BPF_MOV64_IMM(BPF_REG_0, 0), + BPF_EXIT_INSN(), + BPF_EMIT_CALL(BPF_FUNC_sk_fullsock), + BPF_JMP_IMM(BPF_JNE, BPF_REG_0, 0, 2), + BPF_MOV64_IMM(BPF_REG_0, 0), + BPF_EXIT_INSN(), + BPF_LDX_MEM(BPF_H, BPF_REG_0, BPF_REG_0, offsetof(struct bpf_sock, dst_po= rt) + 2), + BPF_MOV64_IMM(BPF_REG_0, 0), + BPF_EXIT_INSN(), + }, + .prog_type =3D BPF_PROG_TYPE_CGROUP_SKB, + .result =3D REJECT, + .errstr =3D "invalid sock access", +}, +{ + "sk_fullsock(skb->sk): sk->dst_port [byte load]", + .insns =3D { + BPF_LDX_MEM(BPF_DW, BPF_REG_1, BPF_REG_1, offsetof(struct __sk_buff, sk)), + BPF_JMP_IMM(BPF_JNE, BPF_REG_1, 0, 2), + BPF_MOV64_IMM(BPF_REG_0, 0), + BPF_EXIT_INSN(), + BPF_EMIT_CALL(BPF_FUNC_sk_fullsock), + BPF_JMP_IMM(BPF_JNE, BPF_REG_0, 0, 2), + BPF_MOV64_IMM(BPF_REG_0, 0), + BPF_EXIT_INSN(), + BPF_LDX_MEM(BPF_B, BPF_REG_2, BPF_REG_0, offsetof(struct bpf_sock, dst_po= rt)), + BPF_LDX_MEM(BPF_B, BPF_REG_2, BPF_REG_0, offsetof(struct bpf_sock, dst_po= rt) + 1), + BPF_MOV64_IMM(BPF_REG_0, 0), + BPF_EXIT_INSN(), + }, + .prog_type =3D BPF_PROG_TYPE_CGROUP_SKB, + .result =3D ACCEPT, +}, +{ + "sk_fullsock(skb->sk): sk->dst_port [byte load] (invalid)", + .insns =3D { + BPF_LDX_MEM(BPF_DW, BPF_REG_1, BPF_REG_1, offsetof(struct __sk_buff, sk)), + BPF_JMP_IMM(BPF_JNE, BPF_REG_1, 0, 2), + BPF_MOV64_IMM(BPF_REG_0, 0), + BPF_EXIT_INSN(), + BPF_EMIT_CALL(BPF_FUNC_sk_fullsock), + BPF_JMP_IMM(BPF_JNE, BPF_REG_0, 0, 2), + BPF_MOV64_IMM(BPF_REG_0, 0), + BPF_EXIT_INSN(), + BPF_LDX_MEM(BPF_B, BPF_REG_0, BPF_REG_0, offsetof(struct bpf_sock, dst_po= rt) + 2), + BPF_MOV64_IMM(BPF_REG_0, 0), + BPF_EXIT_INSN(), + }, + .prog_type =3D BPF_PROG_TYPE_CGROUP_SKB, + .result =3D REJECT, + .errstr =3D "invalid sock access", +}, +{ + "sk_fullsock(skb->sk): past sk->dst_port [half load] (invalid)", .insns =3D { BPF_LDX_MEM(BPF_DW, BPF_REG_1, BPF_REG_1, offsetof(struct __sk_buff, sk)), BPF_JMP_IMM(BPF_JNE, BPF_REG_1, 0, 2), @@ -149,7 +224,7 @@ BPF_JMP_IMM(BPF_JNE, BPF_REG_0, 0, 2), BPF_MOV64_IMM(BPF_REG_0, 0), BPF_EXIT_INSN(), - BPF_LDX_MEM(BPF_B, BPF_REG_0, BPF_REG_0, offsetof(struct bpf_sock, dst_po= rt) + 1), + BPF_LDX_MEM(BPF_H, BPF_REG_0, BPF_REG_0, offsetofend(struct bpf_sock, dst= _port)), BPF_MOV64_IMM(BPF_REG_0, 0), BPF_EXIT_INSN(), }, From nobody Sat Apr 11 15:26:33 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7C498C19F2D for ; Tue, 9 Aug 2022 18:08:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232983AbiHISI3 (ORCPT ); Tue, 9 Aug 2022 14:08:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43230 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344977AbiHISHs (ORCPT ); Tue, 9 Aug 2022 14:07:48 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CCCA02873B; Tue, 9 Aug 2022 11:03:21 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 7A99061083; Tue, 9 Aug 2022 18:03:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 87563C43470; Tue, 9 Aug 2022 18:03:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068200; bh=VD83UgiWufcDQMx6LODuf28lgLU0KcghxVGdBDnS4P0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fn5lRlwgI721pFN6J3ICkXDbZXwJu4GZViHqU0avlcxDprjZouMu2uZ7ib+A9wJZj 4I/sX5EU47iSRBot+hv4lhMguoHrHNE6OAY5Dy2ug2UnKKeP+qJF16nA67lpzsn1xu w1c3QxGsgit+VnudGG8j9+iVrjzxE+uf4PKWu2Ko= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Greg Kroah-Hartman , John Fastabend , Alexei Starovoitov , Ovidiu Panait Subject: [PATCH 5.4 07/15] bpf: Test_verifier, #70 error message updates for 32-bit right shift Date: Tue, 9 Aug 2022 20:00:25 +0200 Message-Id: <20220809175510.564956957@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175510.312431319@linuxfoundation.org> References: <20220809175510.312431319@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: John Fastabend commit aa131ed44ae1d76637f0dbec33cfcf9115af9bc3 upstream. After changes to add update_reg_bounds after ALU ops and adding ALU32 bounds tracking the error message is changed in the 32-bit right shift tests. Test "#70/u bounds check after 32-bit right shift with 64-bit input FAIL" now fails with, Unexpected error message! EXP: R0 invalid mem access RES: func#0 @0 7: (b7) r1 =3D 2 8: R0_w=3Dmap_value(id=3D0,off=3D0,ks=3D8,vs=3D8,imm=3D0) R1_w=3DinvP2 R10= =3Dfp0 fp-8_w=3Dmmmmmmmm 8: (67) r1 <<=3D 31 9: R0_w=3Dmap_value(id=3D0,off=3D0,ks=3D8,vs=3D8,imm=3D0) R1_w=3DinvP429496= 7296 R10=3Dfp0 fp-8_w=3Dmmmmmmmm 9: (74) w1 >>=3D 31 10: R0_w=3Dmap_value(id=3D0,off=3D0,ks=3D8,vs=3D8,imm=3D0) R1_w=3DinvP0 R10= =3Dfp0 fp-8_w=3Dmmmmmmmm 10: (14) w1 -=3D 2 11: R0_w=3Dmap_value(id=3D0,off=3D0,ks=3D8,vs=3D8,imm=3D0) R1_w=3DinvP42949= 67294 R10=3Dfp0 fp-8_w=3Dmmmmmmmm 11: (0f) r0 +=3D r1 math between map_value pointer and 4294967294 is not allowed And test "#70/p bounds check after 32-bit right shift with 64-bit input FAIL" now fails with, Unexpected error message! EXP: R0 invalid mem access RES: func#0 @0 7: (b7) r1 =3D 2 8: R0_w=3Dmap_value(id=3D0,off=3D0,ks=3D8,vs=3D8,imm=3D0) R1_w=3Dinv2 R10= =3Dfp0 fp-8_w=3Dmmmmmmmm 8: (67) r1 <<=3D 31 9: R0_w=3Dmap_value(id=3D0,off=3D0,ks=3D8,vs=3D8,imm=3D0) R1_w=3Dinv4294967= 296 R10=3Dfp0 fp-8_w=3Dmmmmmmmm 9: (74) w1 >>=3D 31 10: R0_w=3Dmap_value(id=3D0,off=3D0,ks=3D8,vs=3D8,imm=3D0) R1_w=3Dinv0 R10= =3Dfp0 fp-8_w=3Dmmmmmmmm 10: (14) w1 -=3D 2 11: R0_w=3Dmap_value(id=3D0,off=3D0,ks=3D8,vs=3D8,imm=3D0) R1_w=3Dinv429496= 7294 R10=3Dfp0 fp-8_w=3Dmmmmmmmm 11: (0f) r0 +=3D r1 last_idx 11 first_idx 0 regs=3D2 stack=3D0 before 10: (14) w1 -=3D 2 regs=3D2 stack=3D0 before 9: (74) w1 >>=3D 31 regs=3D2 stack=3D0 before 8: (67) r1 <<=3D 31 regs=3D2 stack=3D0 before 7: (b7) r1 =3D 2 math between map_value pointer and 4294967294 is not allowed Before this series we did not trip the "math between map_value pointer..." error because check_reg_sane_offset is never called in adjust_ptr_min_max_vals(). Instead we have a register state that looks like this at line 11*, 11: R0_w=3Dmap_value(id=3D0,off=3D0,ks=3D8,vs=3D8, smin_value=3D0,smax_value=3D0, umin_value=3D0,umax_value=3D0, var_off=3D(0x0; 0x0)) R1_w=3DinvP(id=3D0, smin_value=3D0,smax_value=3D4294967295, umin_value=3D0,umax_value=3D4294967295, var_off=3D(0xfffffffe; 0x0)) R10=3Dfp(id=3D0,off=3D0, smin_value=3D0,smax_value=3D0, umin_value=3D0,umax_value=3D0, var_off=3D(0x0; 0x0)) fp-8_w=3Dmmmmmmmm 11: (0f) r0 +=3D r1 In R1 'smin_val !=3D smax_val' yet we have a tnum_const as seen by 'var_off(0xfffffffe; 0x0))' with a 0x0 mask. So we hit this check in adjust_ptr_min_max_vals() if ((known && (smin_val !=3D smax_val || umin_val !=3D umax_val)) || smin_val > smax_val || umin_val > umax_val) { /* Taint dst register if offset had invalid bounds derived from * e.g. dead branches. */ __mark_reg_unknown(env, dst_reg); return 0; } So we don't throw an error here and instead only throw an error later in the verification when the memory access is made. The root cause in verifier without alu32 bounds tracking is having 'umin_value =3D 0' and 'umax_value =3D U64_MAX' from BPF_SUB which we set when 'umin_value < umax_val' here, if (dst_reg->umin_value < umax_val) { /* Overflow possible, we know nothing */ dst_reg->umin_value =3D 0; dst_reg->umax_value =3D U64_MAX; } else { ...} Later in adjust_calar_min_max_vals we previously did a coerce_reg_to_size() which will clamp the U64_MAX to U32_MAX by truncating to 32bits. But either way without a call to update_reg_bounds the less precise bounds tracking will fall out of the alu op verification. After latest changes we now exit adjust_scalar_min_max_vals with the more precise umin value, due to zero extension propogating bounds from alu32 bounds into alu64 bounds and then calling update_reg_bounds. This then causes the verifier to trigger an earlier error and we get the error in the output above. This patch updates tests to reflect new error message. * I have a local patch to print entire verifier state regardless if we believe it is a constant so we can get a full picture of the state. Usually if tnum_is_const() then bounds are also smin=3Dsmax, etc. but this is not always true and is a bit subtle. Being able to see these states helps understand dataflow imo. Let me know if we want something similar upstream. Signed-off-by: John Fastabend Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/158507161475.15666.3061518385241144063.st= git@john-Precision-5820-Tower Signed-off-by: Ovidiu Panait Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- tools/testing/selftests/bpf/verifier/bounds.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) --- a/tools/testing/selftests/bpf/verifier/bounds.c +++ b/tools/testing/selftests/bpf/verifier/bounds.c @@ -411,16 +411,14 @@ BPF_ALU32_IMM(BPF_RSH, BPF_REG_1, 31), /* r1 =3D 0xffff'fffe (NOT 0!) */ BPF_ALU32_IMM(BPF_SUB, BPF_REG_1, 2), - /* computes OOB pointer */ + /* error on computing OOB pointer */ BPF_ALU64_REG(BPF_ADD, BPF_REG_0, BPF_REG_1), - /* OOB access */ - BPF_LDX_MEM(BPF_B, BPF_REG_0, BPF_REG_0, 0), /* exit */ BPF_MOV64_IMM(BPF_REG_0, 0), BPF_EXIT_INSN(), }, .fixup_map_hash_8b =3D { 3 }, - .errstr =3D "R0 invalid mem access", + .errstr =3D "math between map_value pointer and 4294967294 is not allowed= ", .result =3D REJECT, }, { From nobody Sat Apr 11 15:26:33 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8EE75C19F2D for ; Tue, 9 Aug 2022 18:08:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345057AbiHISIk (ORCPT ); Tue, 9 Aug 2022 14:08:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43638 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344751AbiHISIH (ORCPT ); Tue, 9 Aug 2022 14:08:07 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 350C328E19; Tue, 9 Aug 2022 11:03:23 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id BCC01610A1; Tue, 9 Aug 2022 18:03:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 38DCEC433D6; Tue, 9 Aug 2022 18:03:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068203; bh=D72SDJymXEr5HiwtViNEKBFav7YyUbHL7TahIGNr7qQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gtNrUOv3+2xRbQmp3vIVSJbyVEltirl9gc4kD7f2JT3w43QpApwShPOTRFHeKlyDi u1SzUkt+DA/YRF+6spgZh6iEepeQJJPjWk7lbLI0KlarD+7NccDh8gKCna7le/FEyt ChEl/mjZdY9eQMH7YDD/knKRqsDAt0Q185l9ufsM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Greg Kroah-Hartman , Stanislav Fomichev , Daniel Borkmann , Ovidiu Panait Subject: [PATCH 5.4 08/15] selftests/bpf: Fix test_align verifier log patterns Date: Tue, 9 Aug 2022 20:00:26 +0200 Message-Id: <20220809175510.601238672@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175510.312431319@linuxfoundation.org> References: <20220809175510.312431319@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Stanislav Fomichev commit 5366d2269139ba8eb6a906d73a0819947e3e4e0a upstream. Commit 294f2fc6da27 ("bpf: Verifer, adjust_scalar_min_max_vals to always call update_reg_bounds()") changed the way verifier logs some of its state, adjust the test_align accordingly. Where possible, I tried to not copy-paste the entire log line and resorted to dropping the last closing brace instead. Fixes: 294f2fc6da27 ("bpf: Verifer, adjust_scalar_min_max_vals to always ca= ll update_reg_bounds()") Signed-off-by: Stanislav Fomichev Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200515194904.229296-1-sdf@google.com Signed-off-by: Ovidiu Panait Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- tools/testing/selftests/bpf/test_align.c | 41 +++++++++++++++-----------= ----- 1 file changed, 21 insertions(+), 20 deletions(-) --- a/tools/testing/selftests/bpf/test_align.c +++ b/tools/testing/selftests/bpf/test_align.c @@ -359,15 +359,15 @@ static struct bpf_align_test tests[] =3D { * is still (4n), fixed offset is not changed. * Also, we create a new reg->id. */ - {29, "R5_w=3Dpkt(id=3D4,off=3D18,r=3D0,umax_value=3D2040,var_off=3D(0x0= ; 0x7fc))"}, + {29, "R5_w=3Dpkt(id=3D4,off=3D18,r=3D0,umax_value=3D2040,var_off=3D(0x0= ; 0x7fc)"}, /* At the time the word size load is performed from R5, * its total fixed offset is NET_IP_ALIGN + reg->off (18) * which is 20. Then the variable offset is (4n), so * the total offset is 4-byte aligned and meets the * load's requirements. */ - {33, "R4=3Dpkt(id=3D4,off=3D22,r=3D22,umax_value=3D2040,var_off=3D(0x0;= 0x7fc))"}, - {33, "R5=3Dpkt(id=3D4,off=3D18,r=3D22,umax_value=3D2040,var_off=3D(0x0;= 0x7fc))"}, + {33, "R4=3Dpkt(id=3D4,off=3D22,r=3D22,umax_value=3D2040,var_off=3D(0x0;= 0x7fc)"}, + {33, "R5=3Dpkt(id=3D4,off=3D18,r=3D22,umax_value=3D2040,var_off=3D(0x0;= 0x7fc)"}, }, }, { @@ -410,15 +410,15 @@ static struct bpf_align_test tests[] =3D { /* Adding 14 makes R6 be (4n+2) */ {9, "R6_w=3Dinv(id=3D0,umin_value=3D14,umax_value=3D1034,var_off=3D(0x2= ; 0x7fc))"}, /* Packet pointer has (4n+2) offset */ - {11, "R5_w=3Dpkt(id=3D1,off=3D0,r=3D0,umin_value=3D14,umax_value=3D1034= ,var_off=3D(0x2; 0x7fc))"}, - {13, "R4=3Dpkt(id=3D1,off=3D4,r=3D0,umin_value=3D14,umax_value=3D1034,v= ar_off=3D(0x2; 0x7fc))"}, + {11, "R5_w=3Dpkt(id=3D1,off=3D0,r=3D0,umin_value=3D14,umax_value=3D1034= ,var_off=3D(0x2; 0x7fc)"}, + {13, "R4=3Dpkt(id=3D1,off=3D4,r=3D0,umin_value=3D14,umax_value=3D1034,v= ar_off=3D(0x2; 0x7fc)"}, /* At the time the word size load is performed from R5, * its total fixed offset is NET_IP_ALIGN + reg->off (0) * which is 2. Then the variable offset is (4n+2), so * the total offset is 4-byte aligned and meets the * load's requirements. */ - {15, "R5=3Dpkt(id=3D1,off=3D0,r=3D4,umin_value=3D14,umax_value=3D1034,v= ar_off=3D(0x2; 0x7fc))"}, + {15, "R5=3Dpkt(id=3D1,off=3D0,r=3D4,umin_value=3D14,umax_value=3D1034,v= ar_off=3D(0x2; 0x7fc)"}, /* Newly read value in R6 was shifted left by 2, so has * known alignment of 4. */ @@ -426,15 +426,15 @@ static struct bpf_align_test tests[] =3D { /* Added (4n) to packet pointer's (4n+2) var_off, giving * another (4n+2). */ - {19, "R5_w=3Dpkt(id=3D2,off=3D0,r=3D0,umin_value=3D14,umax_value=3D2054= ,var_off=3D(0x2; 0xffc))"}, - {21, "R4=3Dpkt(id=3D2,off=3D4,r=3D0,umin_value=3D14,umax_value=3D2054,v= ar_off=3D(0x2; 0xffc))"}, + {19, "R5_w=3Dpkt(id=3D2,off=3D0,r=3D0,umin_value=3D14,umax_value=3D2054= ,var_off=3D(0x2; 0xffc)"}, + {21, "R4=3Dpkt(id=3D2,off=3D4,r=3D0,umin_value=3D14,umax_value=3D2054,v= ar_off=3D(0x2; 0xffc)"}, /* At the time the word size load is performed from R5, * its total fixed offset is NET_IP_ALIGN + reg->off (0) * which is 2. Then the variable offset is (4n+2), so * the total offset is 4-byte aligned and meets the * load's requirements. */ - {23, "R5=3Dpkt(id=3D2,off=3D0,r=3D4,umin_value=3D14,umax_value=3D2054,v= ar_off=3D(0x2; 0xffc))"}, + {23, "R5=3Dpkt(id=3D2,off=3D0,r=3D4,umin_value=3D14,umax_value=3D2054,v= ar_off=3D(0x2; 0xffc)"}, }, }, { @@ -469,16 +469,16 @@ static struct bpf_align_test tests[] =3D { .matches =3D { {4, "R5_w=3Dpkt_end(id=3D0,off=3D0,imm=3D0)"}, /* (ptr - ptr) << 2 =3D=3D unknown, (4n) */ - {6, "R5_w=3Dinv(id=3D0,smax_value=3D9223372036854775804,umax_value=3D18= 446744073709551612,var_off=3D(0x0; 0xfffffffffffffffc))"}, + {6, "R5_w=3Dinv(id=3D0,smax_value=3D9223372036854775804,umax_value=3D18= 446744073709551612,var_off=3D(0x0; 0xfffffffffffffffc)"}, /* (4n) + 14 =3D=3D (4n+2). We blow our bounds, because * the add could overflow. */ - {7, "R5_w=3Dinv(id=3D0,var_off=3D(0x2; 0xfffffffffffffffc))"}, + {7, "R5_w=3Dinv(id=3D0,smin_value=3D-9223372036854775806,smax_value=3D9= 223372036854775806,umin_value=3D2,umax_value=3D18446744073709551614,var_off= =3D(0x2; 0xfffffffffffffffc)"}, /* Checked s>=3D0 */ - {9, "R5=3Dinv(id=3D0,umin_value=3D2,umax_value=3D9223372036854775806,va= r_off=3D(0x2; 0x7ffffffffffffffc))"}, + {9, "R5=3Dinv(id=3D0,umin_value=3D2,umax_value=3D9223372034707292158,va= r_off=3D(0x2; 0x7fffffff7ffffffc)"}, /* packet pointer + nonnegative (4n+2) */ - {11, "R6_w=3Dpkt(id=3D1,off=3D0,r=3D0,umin_value=3D2,umax_value=3D92233= 72036854775806,var_off=3D(0x2; 0x7ffffffffffffffc))"}, - {13, "R4_w=3Dpkt(id=3D1,off=3D4,r=3D0,umin_value=3D2,umax_value=3D92233= 72036854775806,var_off=3D(0x2; 0x7ffffffffffffffc))"}, + {11, "R6_w=3Dpkt(id=3D1,off=3D0,r=3D0,umin_value=3D2,umax_value=3D92233= 72034707292158,var_off=3D(0x2; 0x7fffffff7ffffffc)"}, + {13, "R4_w=3Dpkt(id=3D1,off=3D4,r=3D0,umin_value=3D2,umax_value=3D92233= 72034707292158,var_off=3D(0x2; 0x7fffffff7ffffffc)"}, /* NET_IP_ALIGN + (4n+2) =3D=3D (4n), alignment is fine. * We checked the bounds, but it might have been able * to overflow if the packet pointer started in the @@ -486,7 +486,7 @@ static struct bpf_align_test tests[] =3D { * So we did not get a 'range' on R6, and the access * attempt will fail. */ - {15, "R6_w=3Dpkt(id=3D1,off=3D0,r=3D0,umin_value=3D2,umax_value=3D92233= 72036854775806,var_off=3D(0x2; 0x7ffffffffffffffc))"}, + {15, "R6_w=3Dpkt(id=3D1,off=3D0,r=3D0,umin_value=3D2,umax_value=3D92233= 72034707292158,var_off=3D(0x2; 0x7fffffff7ffffffc)"}, } }, { @@ -528,7 +528,7 @@ static struct bpf_align_test tests[] =3D { /* New unknown value in R7 is (4n) */ {11, "R7_w=3Dinv(id=3D0,umax_value=3D1020,var_off=3D(0x0; 0x3fc))"}, /* Subtracting it from R6 blows our unsigned bounds */ - {12, "R6=3Dinv(id=3D0,smin_value=3D-1006,smax_value=3D1034,var_off=3D(0= x2; 0xfffffffffffffffc))"}, + {12, "R6=3Dinv(id=3D0,smin_value=3D-1006,smax_value=3D1034,umin_value= =3D2,umax_value=3D18446744073709551614,var_off=3D(0x2; 0xfffffffffffffffc)"= }, /* Checked s>=3D 0 */ {14, "R6=3Dinv(id=3D0,umin_value=3D2,umax_value=3D1034,var_off=3D(0x2; = 0x7fc))"}, /* At the time the word size load is performed from R5, @@ -537,7 +537,8 @@ static struct bpf_align_test tests[] =3D { * the total offset is 4-byte aligned and meets the * load's requirements. */ - {20, "R5=3Dpkt(id=3D1,off=3D0,r=3D4,umin_value=3D2,umax_value=3D1034,va= r_off=3D(0x2; 0x7fc))"}, + {20, "R5=3Dpkt(id=3D1,off=3D0,r=3D4,umin_value=3D2,umax_value=3D1034,va= r_off=3D(0x2; 0x7fc)"}, + }, }, { @@ -579,18 +580,18 @@ static struct bpf_align_test tests[] =3D { /* Adding 14 makes R6 be (4n+2) */ {11, "R6_w=3Dinv(id=3D0,umin_value=3D14,umax_value=3D74,var_off=3D(0x2;= 0x7c))"}, /* Subtracting from packet pointer overflows ubounds */ - {13, "R5_w=3Dpkt(id=3D1,off=3D0,r=3D8,umin_value=3D18446744073709551542= ,umax_value=3D18446744073709551602,var_off=3D(0xffffffffffffff82; 0x7c))"}, + {13, "R5_w=3Dpkt(id=3D1,off=3D0,r=3D8,umin_value=3D18446744073709551542= ,umax_value=3D18446744073709551602,var_off=3D(0xffffffffffffff82; 0x7c)"}, /* New unknown value in R7 is (4n), >=3D 76 */ {15, "R7_w=3Dinv(id=3D0,umin_value=3D76,umax_value=3D1096,var_off=3D(0x= 0; 0x7fc))"}, /* Adding it to packet pointer gives nice bounds again */ - {16, "R5_w=3Dpkt(id=3D2,off=3D0,r=3D0,umin_value=3D2,umax_value=3D1082,= var_off=3D(0x2; 0x7fc))"}, + {16, "R5_w=3Dpkt(id=3D2,off=3D0,r=3D0,umin_value=3D2,umax_value=3D1082,= var_off=3D(0x2; 0xfffffffc)"}, /* At the time the word size load is performed from R5, * its total fixed offset is NET_IP_ALIGN + reg->off (0) * which is 2. Then the variable offset is (4n+2), so * the total offset is 4-byte aligned and meets the * load's requirements. */ - {20, "R5=3Dpkt(id=3D2,off=3D0,r=3D4,umin_value=3D2,umax_value=3D1082,va= r_off=3D(0x2; 0x7fc))"}, + {20, "R5=3Dpkt(id=3D2,off=3D0,r=3D4,umin_value=3D2,umax_value=3D1082,va= r_off=3D(0x2; 0xfffffffc)"}, }, }, }; From nobody Sat Apr 11 15:26:33 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 431D4C19F2D for ; Tue, 9 Aug 2022 18:08:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344997AbiHISIp (ORCPT ); Tue, 9 Aug 2022 14:08:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42664 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344994AbiHISIK (ORCPT ); Tue, 9 Aug 2022 14:08:10 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 590E82613E; Tue, 9 Aug 2022 11:03:27 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id D223F61093; Tue, 9 Aug 2022 18:03:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DEEBFC433D7; Tue, 9 Aug 2022 18:03:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068206; bh=YBvfBbszxwM2YDmgbdZdi1jQjeZ8yxndTPd1WQuhB0o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Xb8zW8XwVo+33TuKiGM5EnaCEojrjDi3AJ1QoUnmYFMy8KM9tc7JpvA8gHAuOdC+J ek6JdUt6ApLvxYY7Ok7j/O3K6gXUQ+rc3J1/k6I9lqhkD5uGYNvJy1+7ssnUCXrwIC pSMk3vL0X0YnLhBraZS9qOA85o6/6/pkC7+MNFQg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Greg Kroah-Hartman , Jean-Philippe Brucker , John Fastabend , Alexei Starovoitov , Ovidiu Panait Subject: [PATCH 5.4 09/15] selftests/bpf: Fix "dubious pointer arithmetic" test Date: Tue, 9 Aug 2022 20:00:27 +0200 Message-Id: <20220809175510.632483620@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175510.312431319@linuxfoundation.org> References: <20220809175510.312431319@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Jean-Philippe Brucker commit 3615bdf6d9b19db12b1589861609b4f1c6a8d303 upstream. The verifier trace changed following a bugfix. After checking the 64-bit sign, only the upper bit mask is known, not bit 31. Update the test accordingly. Signed-off-by: Jean-Philippe Brucker Acked-by: John Fastabend Signed-off-by: Alexei Starovoitov Signed-off-by: Ovidiu Panait Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- tools/testing/selftests/bpf/test_align.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/tools/testing/selftests/bpf/test_align.c +++ b/tools/testing/selftests/bpf/test_align.c @@ -475,10 +475,10 @@ static struct bpf_align_test tests[] =3D { */ {7, "R5_w=3Dinv(id=3D0,smin_value=3D-9223372036854775806,smax_value=3D9= 223372036854775806,umin_value=3D2,umax_value=3D18446744073709551614,var_off= =3D(0x2; 0xfffffffffffffffc)"}, /* Checked s>=3D0 */ - {9, "R5=3Dinv(id=3D0,umin_value=3D2,umax_value=3D9223372034707292158,va= r_off=3D(0x2; 0x7fffffff7ffffffc)"}, + {9, "R5=3Dinv(id=3D0,umin_value=3D2,umax_value=3D9223372036854775806,va= r_off=3D(0x2; 0x7ffffffffffffffc)"}, /* packet pointer + nonnegative (4n+2) */ - {11, "R6_w=3Dpkt(id=3D1,off=3D0,r=3D0,umin_value=3D2,umax_value=3D92233= 72034707292158,var_off=3D(0x2; 0x7fffffff7ffffffc)"}, - {13, "R4_w=3Dpkt(id=3D1,off=3D4,r=3D0,umin_value=3D2,umax_value=3D92233= 72034707292158,var_off=3D(0x2; 0x7fffffff7ffffffc)"}, + {11, "R6_w=3Dpkt(id=3D1,off=3D0,r=3D0,umin_value=3D2,umax_value=3D92233= 72036854775806,var_off=3D(0x2; 0x7ffffffffffffffc)"}, + {13, "R4_w=3Dpkt(id=3D1,off=3D4,r=3D0,umin_value=3D2,umax_value=3D92233= 72036854775806,var_off=3D(0x2; 0x7ffffffffffffffc)"}, /* NET_IP_ALIGN + (4n+2) =3D=3D (4n), alignment is fine. * We checked the bounds, but it might have been able * to overflow if the packet pointer started in the @@ -486,7 +486,7 @@ static struct bpf_align_test tests[] =3D { * So we did not get a 'range' on R6, and the access * attempt will fail. */ - {15, "R6_w=3Dpkt(id=3D1,off=3D0,r=3D0,umin_value=3D2,umax_value=3D92233= 72034707292158,var_off=3D(0x2; 0x7fffffff7ffffffc)"}, + {15, "R6_w=3Dpkt(id=3D1,off=3D0,r=3D0,umin_value=3D2,umax_value=3D92233= 72036854775806,var_off=3D(0x2; 0x7ffffffffffffffc)"}, } }, { From nobody Sat Apr 11 15:26:33 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A7FC2C19F2D for ; Tue, 9 Aug 2022 18:09:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345022AbiHISJA (ORCPT ); Tue, 9 Aug 2022 14:09:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50824 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345019AbiHISIT (ORCPT ); Tue, 9 Aug 2022 14:08:19 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 813482654A; Tue, 9 Aug 2022 11:03:29 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3473961117; Tue, 9 Aug 2022 18:03:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9E346C43140; Tue, 9 Aug 2022 18:03:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068209; bh=LijSy99pzpSg1iIzbzqZJpsUfznU587YrJg1vozHGAU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Y2IFXe+wiLiLAG/FQ+SC8OGSHEq48QT5UfD9SjlcUUbdqhLZbb2UkWtLIaXlfXMZ4 7b0VTsWatDSG2/omx7w3qAh82QC5VBn05Pz8tO1frxZE3s37yJMiN4jsylYeriRTV/ X/ekL0ELDwUL6qRL2lwamaDreWOZehO0ei3VkOU8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Paolo Bonzini , Alexey Kardashevskiy , Sasha Levin Subject: [PATCH 5.4 10/15] KVM: Dont null dereference ops->destroy Date: Tue, 9 Aug 2022 20:00:28 +0200 Message-Id: <20220809175510.664673759@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175510.312431319@linuxfoundation.org> References: <20220809175510.312431319@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Alexey Kardashevskiy [ Upstream commit e8bc2427018826e02add7b0ed0fc625a60390ae5 ] A KVM device cleanup happens in either of two callbacks: 1) destroy() which is called when the VM is being destroyed; 2) release() which is called when a device fd is closed. Most KVM devices use 1) but Book3s's interrupt controller KVM devices (XICS, XIVE, XIVE-native) use 2) as they need to close and reopen during the machine execution. The error handling in kvm_ioctl_create_device() assumes destroy() is always defined which leads to NULL dereference as discovered by Syzkaller. This adds a checks for destroy!=3DNULL and adds a missing release(). This is not changing kvm_destroy_devices() as devices with defined release() should have been removed from the KVM devices list by then. Suggested-by: Paolo Bonzini Signed-off-by: Alexey Kardashevskiy Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- virt/kvm/kvm_main.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 287444e52ccf..4b445dddb798 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -3329,8 +3329,11 @@ static int kvm_ioctl_create_device(struct kvm *kvm, kvm_put_kvm(kvm); mutex_lock(&kvm->lock); list_del(&dev->vm_node); + if (ops->release) + ops->release(dev); mutex_unlock(&kvm->lock); - ops->destroy(dev); + if (ops->destroy) + ops->destroy(dev); return ret; } =20 --=20 2.35.1 From nobody Sat Apr 11 15:26:33 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 87C05C3F6B0 for ; Tue, 9 Aug 2022 18:07:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344973AbiHISHs (ORCPT ); Tue, 9 Aug 2022 14:07:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44020 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245168AbiHISHD (ORCPT ); Tue, 9 Aug 2022 14:07:03 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1B282286C9; Tue, 9 Aug 2022 11:03:06 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 8BBFBB8171A; Tue, 9 Aug 2022 18:03:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AEAE5C433D7; Tue, 9 Aug 2022 18:03:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068184; bh=wRLfI31WrZ59IkEj+z6Z5ZZev9x2pVNmX2cjKkCxs74=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=1iIU4bggJNWtjqOccjNZ01lAY8fJ/etxgtu4quSna9I+rHERwpUXZh0sgG8l9QzGb 3gQKR/U7eMAJYKQXR18luYyevhFg9iQciheAtqpg6Mw4/d513PpF76042Sci793GMa pxXR9jp/fM8LFPg4+5a5HynLBQiewtGT76gB1aPE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Ricardo Koller , Reiji Watanabe , Raghavendra Rao Ananta , Andrew Jones , Paolo Bonzini , Sasha Levin Subject: [PATCH 5.4 11/15] selftests: KVM: Handle compiler optimizations in ucall Date: Tue, 9 Aug 2022 20:00:29 +0200 Message-Id: <20220809175510.695751738@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175510.312431319@linuxfoundation.org> References: <20220809175510.312431319@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Raghavendra Rao Ananta [ Upstream commit 9e2f6498efbbc880d7caa7935839e682b64fe5a6 ] The selftests, when built with newer versions of clang, is found to have over optimized guests' ucall() function, and eliminating the stores for uc.cmd (perhaps due to no immediate readers). This resulted in the userspace side always reading a value of '0', and causing multiple test failures. As a result, prevent the compiler from optimizing the stores in ucall() with WRITE_ONCE(). Suggested-by: Ricardo Koller Suggested-by: Reiji Watanabe Signed-off-by: Raghavendra Rao Ananta Message-Id: <20220615185706.1099208-1-rananta@google.com> Reviewed-by: Andrew Jones Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- tools/testing/selftests/kvm/lib/aarch64/ucall.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/tools/testing/selftests/kvm/lib/aarch64/ucall.c b/tools/testin= g/selftests/kvm/lib/aarch64/ucall.c index 6cd91970fbad..3b2a426070c4 100644 --- a/tools/testing/selftests/kvm/lib/aarch64/ucall.c +++ b/tools/testing/selftests/kvm/lib/aarch64/ucall.c @@ -73,20 +73,19 @@ void ucall_uninit(struct kvm_vm *vm) =20 void ucall(uint64_t cmd, int nargs, ...) { - struct ucall uc =3D { - .cmd =3D cmd, - }; + struct ucall uc =3D {}; va_list va; int i; =20 + WRITE_ONCE(uc.cmd, cmd); nargs =3D nargs <=3D UCALL_MAX_ARGS ? nargs : UCALL_MAX_ARGS; =20 va_start(va, nargs); for (i =3D 0; i < nargs; ++i) - uc.args[i] =3D va_arg(va, uint64_t); + WRITE_ONCE(uc.args[i], va_arg(va, uint64_t)); va_end(va); =20 - *ucall_exit_mmio_addr =3D (vm_vaddr_t)&uc; + WRITE_ONCE(*ucall_exit_mmio_addr, (vm_vaddr_t)&uc); } =20 uint64_t get_ucall(struct kvm_vm *vm, uint32_t vcpu_id, struct ucall *uc) --=20 2.35.1 From nobody Sat Apr 11 15:26:33 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B8A82C19F2D for ; Tue, 9 Aug 2022 18:07:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344962AbiHISHp (ORCPT ); Tue, 9 Aug 2022 14:07:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39942 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344759AbiHISHE (ORCPT ); Tue, 9 Aug 2022 14:07:04 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 10F4326124; Tue, 9 Aug 2022 11:03:07 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 2F53C61072; Tue, 9 Aug 2022 18:03:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9F2EDC433B5; Tue, 9 Aug 2022 18:03:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068187; bh=nI9JPa5iH8NkzmrboqJwuGN+X0z3Ve0gacmQwPzJKYs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oI4RpRROeKm9JONgwueMr6Bf+AV7YwvCJNHJl8w9yXhU2ugS+duDGxTv72JGLJ3Z6 WKnluxUsX7cF5q2JnTeYlM8T6kt5qNGWlvX4Pk6LycID4SaZFo2XaKEL5cs1bsWliV T0egBS8BrQGIT46M5+lg3ERRsxXrnMBgEy3rX82Y= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Chen-Yu Tsai , Hans Verkuil , Mauro Carvalho Chehab , Ovidiu Panait Subject: [PATCH 5.4 12/15] media: v4l2-mem2mem: Apply DST_QUEUE_OFF_BASE on MMAP buffers across ioctls Date: Tue, 9 Aug 2022 20:00:30 +0200 Message-Id: <20220809175510.725441808@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175510.312431319@linuxfoundation.org> References: <20220809175510.312431319@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Chen-Yu Tsai commit 8310ca94075e784bbb06593cd6c068ee6b6e4ca6 upstream. DST_QUEUE_OFF_BASE is applied to offset/mem_offset on MMAP capture buffers only for the VIDIOC_QUERYBUF ioctl, while the userspace fields (including offset/mem_offset) are filled in for VIDIOC_{QUERY,PREPARE,Q,DQ}BUF ioctls. This leads to differences in the values presented to userspace. If userspace attempts to mmap the capture buffer directly using values from DQBUF, it will fail. Move the code that applies the magic offset into a helper, and call that helper from all four ioctl entry points. [hverkuil: drop unnecessary '=3D 0' in v4l2_m2m_querybuf() for ret] Fixes: 7f98639def42 ("V4L/DVB: add memory-to-memory device helper framework= for videobuf") Fixes: 908a0d7c588e ("[media] v4l: mem2mem: port to videobuf2") Signed-off-by: Chen-Yu Tsai Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab [OP: backport to 5.4: adjusted return logic in v4l2_m2m_qbuf() to match the logic in the original commit: call v4l2_m2m_adjust_mem_offset() only if !ret and before the v4l2_m2m_try_schedule() call] Signed-off-by: Ovidiu Panait Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/media/v4l2-core/v4l2-mem2mem.c | 60 +++++++++++++++++++++++++---= ----- 1 file changed, 46 insertions(+), 14 deletions(-) --- a/drivers/media/v4l2-core/v4l2-mem2mem.c +++ b/drivers/media/v4l2-core/v4l2-mem2mem.c @@ -460,19 +460,14 @@ int v4l2_m2m_reqbufs(struct file *file, } EXPORT_SYMBOL_GPL(v4l2_m2m_reqbufs); =20 -int v4l2_m2m_querybuf(struct file *file, struct v4l2_m2m_ctx *m2m_ctx, - struct v4l2_buffer *buf) +static void v4l2_m2m_adjust_mem_offset(struct vb2_queue *vq, + struct v4l2_buffer *buf) { - struct vb2_queue *vq; - int ret =3D 0; - unsigned int i; - - vq =3D v4l2_m2m_get_vq(m2m_ctx, buf->type); - ret =3D vb2_querybuf(vq, buf); - /* Adjust MMAP memory offsets for the CAPTURE queue */ if (buf->memory =3D=3D V4L2_MEMORY_MMAP && !V4L2_TYPE_IS_OUTPUT(vq->type)= ) { if (V4L2_TYPE_IS_MULTIPLANAR(vq->type)) { + unsigned int i; + for (i =3D 0; i < buf->length; ++i) buf->m.planes[i].m.mem_offset +=3D DST_QUEUE_OFF_BASE; @@ -480,8 +475,23 @@ int v4l2_m2m_querybuf(struct file *file, buf->m.offset +=3D DST_QUEUE_OFF_BASE; } } +} + +int v4l2_m2m_querybuf(struct file *file, struct v4l2_m2m_ctx *m2m_ctx, + struct v4l2_buffer *buf) +{ + struct vb2_queue *vq; + int ret; =20 - return ret; + vq =3D v4l2_m2m_get_vq(m2m_ctx, buf->type); + ret =3D vb2_querybuf(vq, buf); + if (ret) + return ret; + + /* Adjust MMAP memory offsets for the CAPTURE queue */ + v4l2_m2m_adjust_mem_offset(vq, buf); + + return 0; } EXPORT_SYMBOL_GPL(v4l2_m2m_querybuf); =20 @@ -500,10 +510,16 @@ int v4l2_m2m_qbuf(struct file *file, str return -EPERM; } ret =3D vb2_qbuf(vq, vdev->v4l2_dev->mdev, buf); - if (!ret && !(buf->flags & V4L2_BUF_FLAG_IN_REQUEST)) + if (ret) + return ret; + + /* Adjust MMAP memory offsets for the CAPTURE queue */ + v4l2_m2m_adjust_mem_offset(vq, buf); + + if (!(buf->flags & V4L2_BUF_FLAG_IN_REQUEST)) v4l2_m2m_try_schedule(m2m_ctx); =20 - return ret; + return 0; } EXPORT_SYMBOL_GPL(v4l2_m2m_qbuf); =20 @@ -511,9 +527,17 @@ int v4l2_m2m_dqbuf(struct file *file, st struct v4l2_buffer *buf) { struct vb2_queue *vq; + int ret; =20 vq =3D v4l2_m2m_get_vq(m2m_ctx, buf->type); - return vb2_dqbuf(vq, buf, file->f_flags & O_NONBLOCK); + ret =3D vb2_dqbuf(vq, buf, file->f_flags & O_NONBLOCK); + if (ret) + return ret; + + /* Adjust MMAP memory offsets for the CAPTURE queue */ + v4l2_m2m_adjust_mem_offset(vq, buf); + + return 0; } EXPORT_SYMBOL_GPL(v4l2_m2m_dqbuf); =20 @@ -522,9 +546,17 @@ int v4l2_m2m_prepare_buf(struct file *fi { struct video_device *vdev =3D video_devdata(file); struct vb2_queue *vq; + int ret; =20 vq =3D v4l2_m2m_get_vq(m2m_ctx, buf->type); - return vb2_prepare_buf(vq, vdev->v4l2_dev->mdev, buf); + ret =3D vb2_prepare_buf(vq, vdev->v4l2_dev->mdev, buf); + if (ret) + return ret; + + /* Adjust MMAP memory offsets for the CAPTURE queue */ + v4l2_m2m_adjust_mem_offset(vq, buf); + + return 0; } EXPORT_SYMBOL_GPL(v4l2_m2m_prepare_buf); From nobody Sat Apr 11 15:26:33 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 50BE9C19F2D for ; Tue, 9 Aug 2022 18:09:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345139AbiHISJ3 (ORCPT ); Tue, 9 Aug 2022 14:09:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44120 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344236AbiHISI5 (ORCPT ); Tue, 9 Aug 2022 14:08:57 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C06CD2980F; Tue, 9 Aug 2022 11:03:41 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 58C31B8171C; Tue, 9 Aug 2022 18:03:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A486EC433D6; Tue, 9 Aug 2022 18:03:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068220; bh=e+Sqdz09GdVHe1dlbhbcgQasCVxSYIYnh6jIqbIAANo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=w1KPWZdJ8g6rFaqjj4X1f0SjMdLwBBDRFuaUxBTiY+5OLRwpSdSdYDKtdiJH+xH0V K0xcohnokrs+sYEmlFAqqWXNTMyOlZqFbi27D+YQ+EDzOXRGP4J1nrG66bT5ZX1z/w BBVLm8z6X9HUmyjLTzMdJqKzlW9rglT2HQCDtlaI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, stable , Ning Qiang , Kees Cook , Benjamin Herrenschmidt , Michael Ellerman Subject: [PATCH 5.4 13/15] macintosh/adb: fix oob read in do_adb_query() function Date: Tue, 9 Aug 2022 20:00:31 +0200 Message-Id: <20220809175510.763868106@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175510.312431319@linuxfoundation.org> References: <20220809175510.312431319@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Ning Qiang commit fd97e4ad6d3b0c9fce3bca8ea8e6969d9ce7423b upstream. In do_adb_query() function of drivers/macintosh/adb.c, req->data is copied form userland. The parameter "req->data[2]" is missing check, the array size of adb_handler[] is 16, so adb_handler[req->data[2]].original_address = and adb_handler[req->data[2]].handler_id will lead to oob read. Cc: stable Signed-off-by: Ning Qiang Reviewed-by: Kees Cook Reviewed-by: Greg Kroah-Hartman Acked-by: Benjamin Herrenschmidt Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220713153734.2248-1-sohu0106@126.com Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/macintosh/adb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/macintosh/adb.c +++ b/drivers/macintosh/adb.c @@ -647,7 +647,7 @@ do_adb_query(struct adb_request *req) =20 switch(req->data[1]) { case ADB_QUERY_GETDEVINFO: - if (req->nbytes < 3) + if (req->nbytes < 3 || req->data[2] >=3D 16) break; mutex_lock(&adb_handler_mutex); req->reply[0] =3D adb_handler[req->data[2]].original_address; From nobody Sat Apr 11 15:26:33 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8D91FC25B0C for ; Tue, 9 Aug 2022 18:09:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343616AbiHISJR (ORCPT ); Tue, 9 Aug 2022 14:09:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43838 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345054AbiHISIj (ORCPT ); Tue, 9 Aug 2022 14:08:39 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 479502655C; Tue, 9 Aug 2022 11:03:35 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 1770F61083; Tue, 9 Aug 2022 18:03:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1F199C4347C; Tue, 9 Aug 2022 18:03:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068214; bh=Sw+5Q8Efmx2omaf97BHZLUKhZQ67UX2gnj5B/GmP73o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qttTj2E3QmL2pJYZhmGT8ThMN42GIaNgcXIvaAkjh8hJVgX6f1jlFgp6n6mV/MCoX MWluknyBk5oZgVxgbLRo+cXj5MXWDV4rjYbUrN2ccUiKFYzEdWUYaxKscZPULj7/NS gGhCvYRNQ5k5+UHXEOxiGsck26nTGkebekODUOfs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Daniel Sneddon , Pawan Gupta , Borislav Petkov Subject: [PATCH 5.4 14/15] x86/speculation: Add RSB VM Exit protections Date: Tue, 9 Aug 2022 20:00:32 +0200 Message-Id: <20220809175510.810876950@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175510.312431319@linuxfoundation.org> References: <20220809175510.312431319@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Daniel Sneddon commit 2b1299322016731d56807aa49254a5ea3080b6b3 upstream. tl;dr: The Enhanced IBRS mitigation for Spectre v2 does not work as documented for RET instructions after VM exits. Mitigate it with a new one-entry RSB stuffing mechanism and a new LFENCE. =3D=3D Background =3D=3D Indirect Branch Restricted Speculation (IBRS) was designed to help mitigate Branch Target Injection and Speculative Store Bypass, i.e. Spectre, attacks. IBRS prevents software run in less privileged modes from affecting branch prediction in more privileged modes. IBRS requires the MSR to be written on every privilege level change. To overcome some of the performance issues of IBRS, Enhanced IBRS was introduced. eIBRS is an "always on" IBRS, in other words, just turn it on once instead of writing the MSR on every privilege level change. When eIBRS is enabled, more privileged modes should be protected from less privileged modes, including protecting VMMs from guests. =3D=3D Problem =3D=3D Here's a simplification of how guests are run on Linux' KVM: void run_kvm_guest(void) { // Prepare to run guest VMRESUME(); // Clean up after guest runs } The execution flow for that would look something like this to the processor: 1. Host-side: call run_kvm_guest() 2. Host-side: VMRESUME 3. Guest runs, does "CALL guest_function" 4. VM exit, host runs again 5. Host might make some "cleanup" function calls 6. Host-side: RET from run_kvm_guest() Now, when back on the host, there are a couple of possible scenarios of post-guest activity the host needs to do before executing host code: * on pre-eIBRS hardware (legacy IBRS, or nothing at all), the RSB is not touched and Linux has to do a 32-entry stuffing. * on eIBRS hardware, VM exit with IBRS enabled, or restoring the host IBRS=3D1 shortly after VM exit, has a documented side effect of flushing the RSB except in this PBRSB situation where the software needs to stuff the last RSB entry "by hand". IOW, with eIBRS supported, host RET instructions should no longer be influenced by guest behavior after the host retires a single CALL instruction. However, if the RET instructions are "unbalanced" with CALLs after a VM exit as is the RET in #6, it might speculatively use the address for the instruction after the CALL in #3 as an RSB prediction. This is a problem since the (untrusted) guest controls this address. Balanced CALL/RET instruction pairs such as in step #5 are not affected. =3D=3D Solution =3D=3D The PBRSB issue affects a wide variety of Intel processors which support eIBRS. But not all of them need mitigation. Today, X86_FEATURE_RETPOLINE triggers an RSB filling sequence that mitigates PBRSB. Systems setting RETPOLINE need no further mitigation - i.e., eIBRS systems which enable retpoline explicitly. However, such systems (X86_FEATURE_IBRS_ENHANCED) do not set RETPOLINE and most of them need a new mitigation. Therefore, introduce a new feature flag X86_FEATURE_RSB_VMEXIT_LITE which triggers a lighter-weight PBRSB mitigation versus RSB Filling at vmexit. The lighter-weight mitigation performs a CALL instruction which is immediately followed by a speculative execution barrier (INT3). This steers speculative execution to the barrier -- just like a retpoline -- which ensures that speculation can never reach an unbalanced RET. Then, ensure this CALL is retired before continuing execution with an LFENCE. In other words, the window of exposure is opened at VM exit where RET behavior is troublesome. While the window is open, force RSB predictions sampling for RET targets to a dead end at the INT3. Close the window with the LFENCE. There is a subset of eIBRS systems which are not vulnerable to PBRSB. Add these systems to the cpu_vuln_whitelist[] as NO_EIBRS_PBRSB. Future systems that aren't vulnerable will set ARCH_CAP_PBRSB_NO. [ bp: Massage, incorporate review comments from Andy Cooper. ] [ Pawan: Update commit message to replace RSB_VMEXIT with RETPOLINE ] Signed-off-by: Daniel Sneddon Co-developed-by: Pawan Gupta Signed-off-by: Pawan Gupta Signed-off-by: Borislav Petkov Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- Documentation/admin-guide/hw-vuln/spectre.rst | 8 +++ arch/x86/include/asm/cpufeatures.h | 2=20 arch/x86/include/asm/msr-index.h | 4 + arch/x86/include/asm/nospec-branch.h | 15 ++++++ arch/x86/kernel/cpu/bugs.c | 61 +++++++++++++++++++++= ++++- arch/x86/kernel/cpu/common.c | 12 ++++- arch/x86/kvm/vmx/vmenter.S | 1=20 tools/arch/x86/include/asm/cpufeatures.h | 1=20 8 files changed, 101 insertions(+), 3 deletions(-) --- a/Documentation/admin-guide/hw-vuln/spectre.rst +++ b/Documentation/admin-guide/hw-vuln/spectre.rst @@ -422,6 +422,14 @@ The possible values in this file are: 'RSB filling' Protection of RSB on context switch enabled =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 =20 + - EIBRS Post-barrier Return Stack Buffer (PBRSB) protection status: + + =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=3D=3D=3D=3D=3D + 'PBRSB-eIBRS: SW sequence' CPU is affected and protection of RSB on VM= EXIT enabled + 'PBRSB-eIBRS: Vulnerable' CPU is vulnerable + 'PBRSB-eIBRS: Not affected' CPU is not affected by PBRSB + =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=3D=3D=3D=3D=3D + Full mitigation might require a microcode update from the CPU vendor. When the necessary microcode is not available, the kernel will report vulnerability. --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -286,6 +286,7 @@ #define X86_FEATURE_CQM_MBM_LOCAL (11*32+ 3) /* LLC Local MBM monitoring */ #define X86_FEATURE_FENCE_SWAPGS_USER (11*32+ 4) /* "" LFENCE in user entr= y SWAPGS path */ #define X86_FEATURE_FENCE_SWAPGS_KERNEL (11*32+ 5) /* "" LFENCE in kernel = entry SWAPGS path */ +#define X86_FEATURE_RSB_VMEXIT_LITE (11*32+ 6) /* "" Fill RSB on VM exit w= hen EIBRS is enabled */ =20 /* Intel-defined CPU features, CPUID level 0x00000007:1 (EAX), word 12 */ #define X86_FEATURE_AVX512_BF16 (12*32+ 5) /* AVX512 BFLOAT16 instruction= s */ @@ -406,5 +407,6 @@ #define X86_BUG_ITLB_MULTIHIT X86_BUG(23) /* CPU may incur MCE during cer= tain page attribute changes */ #define X86_BUG_SRBDS X86_BUG(24) /* CPU may leak RNG bits if not mitiga= ted */ #define X86_BUG_MMIO_STALE_DATA X86_BUG(25) /* CPU is affected by Process= or MMIO Stale Data vulnerabilities */ +#define X86_BUG_EIBRS_PBRSB X86_BUG(26) /* EIBRS is vulnerable to Post Ba= rrier RSB Predictions */ =20 #endif /* _ASM_X86_CPUFEATURES_H */ --- a/arch/x86/include/asm/msr-index.h +++ b/arch/x86/include/asm/msr-index.h @@ -129,6 +129,10 @@ * bit available to control VERW * behavior. */ +#define ARCH_CAP_PBRSB_NO BIT(24) /* + * Not susceptible to Post-Barrier + * Return Stack Buffer Predictions. + */ =20 #define MSR_IA32_FLUSH_CMD 0x0000010b #define L1D_FLUSH BIT(0) /* --- a/arch/x86/include/asm/nospec-branch.h +++ b/arch/x86/include/asm/nospec-branch.h @@ -63,6 +63,13 @@ jnz 771b; \ add $(BITS_PER_LONG/8) * nr, sp; =20 +#define __ISSUE_UNBALANCED_RET_GUARD(sp) \ + call 881f; \ + int3; \ +881: \ + add $(BITS_PER_LONG/8), sp; \ + lfence; + #ifdef __ASSEMBLY__ =20 /* @@ -132,6 +139,14 @@ #endif .endm =20 +.macro ISSUE_UNBALANCED_RET_GUARD ftr:req + ANNOTATE_NOSPEC_ALTERNATIVE + ALTERNATIVE "jmp .Lskip_pbrsb_\@", \ + __stringify(__ISSUE_UNBALANCED_RET_GUARD(%_ASM_SP)) \ + \ftr +.Lskip_pbrsb_\@: +.endm + /* * A simpler FILL_RETURN_BUFFER macro. Don't make people use the CPP * monstrosity above, manually. --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -1043,6 +1043,49 @@ static enum spectre_v2_mitigation __init return SPECTRE_V2_RETPOLINE; } =20 +static void __init spectre_v2_determine_rsb_fill_type_at_vmexit(enum spect= re_v2_mitigation mode) +{ + /* + * Similar to context switches, there are two types of RSB attacks + * after VM exit: + * + * 1) RSB underflow + * + * 2) Poisoned RSB entry + * + * When retpoline is enabled, both are mitigated by filling/clearing + * the RSB. + * + * When IBRS is enabled, while #1 would be mitigated by the IBRS branch + * prediction isolation protections, RSB still needs to be cleared + * because of #2. Note that SMEP provides no protection here, unlike + * user-space-poisoned RSB entries. + * + * eIBRS should protect against RSB poisoning, but if the EIBRS_PBRSB + * bug is present then a LITE version of RSB protection is required, + * just a single call needs to retire before a RET is executed. + */ + switch (mode) { + case SPECTRE_V2_NONE: + /* These modes already fill RSB at vmexit */ + case SPECTRE_V2_LFENCE: + case SPECTRE_V2_RETPOLINE: + case SPECTRE_V2_EIBRS_RETPOLINE: + return; + + case SPECTRE_V2_EIBRS_LFENCE: + case SPECTRE_V2_EIBRS: + if (boot_cpu_has_bug(X86_BUG_EIBRS_PBRSB)) { + setup_force_cpu_cap(X86_FEATURE_RSB_VMEXIT_LITE); + pr_info("Spectre v2 / PBRSB-eIBRS: Retire a single CALL on VMEXIT\n"); + } + return; + } + + pr_warn_once("Unknown Spectre v2 mode, disabling RSB mitigation at VM exi= t"); + dump_stack(); +} + static void __init spectre_v2_select_mitigation(void) { enum spectre_v2_mitigation_cmd cmd =3D spectre_v2_parse_cmdline(); @@ -1135,6 +1178,8 @@ static void __init spectre_v2_select_mit setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW); pr_info("Spectre v2 / SpectreRSB mitigation: Filling RSB on context switc= h\n"); =20 + spectre_v2_determine_rsb_fill_type_at_vmexit(mode); + /* * Retpoline means the kernel is safe because it has no indirect * branches. Enhanced IBRS protects firmware too, so, enable restricted @@ -1879,6 +1924,19 @@ static char *ibpb_state(void) return ""; } =20 +static char *pbrsb_eibrs_state(void) +{ + if (boot_cpu_has_bug(X86_BUG_EIBRS_PBRSB)) { + if (boot_cpu_has(X86_FEATURE_RSB_VMEXIT_LITE) || + boot_cpu_has(X86_FEATURE_RETPOLINE)) + return ", PBRSB-eIBRS: SW sequence"; + else + return ", PBRSB-eIBRS: Vulnerable"; + } else { + return ", PBRSB-eIBRS: Not affected"; + } +} + static ssize_t spectre_v2_show_state(char *buf) { if (spectre_v2_enabled =3D=3D SPECTRE_V2_LFENCE) @@ -1891,12 +1949,13 @@ static ssize_t spectre_v2_show_state(cha spectre_v2_enabled =3D=3D SPECTRE_V2_EIBRS_LFENCE) return sprintf(buf, "Vulnerable: eIBRS+LFENCE with unprivileged eBPF and= SMT\n"); =20 - return sprintf(buf, "%s%s%s%s%s%s\n", + return sprintf(buf, "%s%s%s%s%s%s%s\n", spectre_v2_strings[spectre_v2_enabled], ibpb_state(), boot_cpu_has(X86_FEATURE_USE_IBRS_FW) ? ", IBRS_FW" : "", stibp_state(), boot_cpu_has(X86_FEATURE_RSB_CTXSW) ? ", RSB filling" : "", + pbrsb_eibrs_state(), spectre_v2_module_string()); } =20 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -1025,6 +1025,7 @@ static void identify_cpu_without_cpuid(s #define NO_SWAPGS BIT(6) #define NO_ITLB_MULTIHIT BIT(7) #define NO_SPECTRE_V2 BIT(8) +#define NO_EIBRS_PBRSB BIT(9) =20 #define VULNWL(_vendor, _family, _model, _whitelist) \ { X86_VENDOR_##_vendor, _family, _model, X86_FEATURE_ANY, _whitelist } @@ -1065,7 +1066,7 @@ static const __initconst struct x86_cpu_ =20 VULNWL_INTEL(ATOM_GOLDMONT, NO_MDS | NO_L1TF | NO_SWAPGS | NO_ITLB_MULTI= HIT), VULNWL_INTEL(ATOM_GOLDMONT_D, NO_MDS | NO_L1TF | NO_SWAPGS | NO_ITLB_MUL= TIHIT), - VULNWL_INTEL(ATOM_GOLDMONT_PLUS, NO_MDS | NO_L1TF | NO_SWAPGS | NO_ITLB_M= ULTIHIT), + VULNWL_INTEL(ATOM_GOLDMONT_PLUS, NO_MDS | NO_L1TF | NO_SWAPGS | NO_ITLB_M= ULTIHIT | NO_EIBRS_PBRSB), =20 /* * Technically, swapgs isn't serializing on AMD (despite it previously @@ -1075,7 +1076,9 @@ static const __initconst struct x86_cpu_ * good enough for our purposes. */ =20 - VULNWL_INTEL(ATOM_TREMONT_D, NO_ITLB_MULTIHIT), + VULNWL_INTEL(ATOM_TREMONT, NO_EIBRS_PBRSB), + VULNWL_INTEL(ATOM_TREMONT_L, NO_EIBRS_PBRSB), + VULNWL_INTEL(ATOM_TREMONT_D, NO_ITLB_MULTIHIT | NO_EIBRS_PBRSB), =20 /* AMD Family 0xf - 0x12 */ VULNWL_AMD(0x0f, NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS | NO_SWAPGS | NO= _ITLB_MULTIHIT), @@ -1236,6 +1239,11 @@ static void __init cpu_set_bug_bits(stru !arch_cap_mmio_immune(ia32_cap)) setup_force_cpu_bug(X86_BUG_MMIO_STALE_DATA); =20 + if (cpu_has(c, X86_FEATURE_IBRS_ENHANCED) && + !cpu_matches(cpu_vuln_whitelist, NO_EIBRS_PBRSB) && + !(ia32_cap & ARCH_CAP_PBRSB_NO)) + setup_force_cpu_bug(X86_BUG_EIBRS_PBRSB); + if (cpu_matches(cpu_vuln_whitelist, NO_MELTDOWN)) return; =20 --- a/arch/x86/kvm/vmx/vmenter.S +++ b/arch/x86/kvm/vmx/vmenter.S @@ -92,6 +92,7 @@ ENTRY(vmx_vmexit) pop %_ASM_AX .Lvmexit_skip_rsb: #endif + ISSUE_UNBALANCED_RET_GUARD X86_FEATURE_RSB_VMEXIT_LITE ret ENDPROC(vmx_vmexit) =20 --- a/tools/arch/x86/include/asm/cpufeatures.h +++ b/tools/arch/x86/include/asm/cpufeatures.h @@ -284,6 +284,7 @@ #define X86_FEATURE_CQM_MBM_LOCAL (11*32+ 3) /* LLC Local MBM monitoring */ #define X86_FEATURE_FENCE_SWAPGS_USER (11*32+ 4) /* "" LFENCE in user entr= y SWAPGS path */ #define X86_FEATURE_FENCE_SWAPGS_KERNEL (11*32+ 5) /* "" LFENCE in kernel = entry SWAPGS path */ +#define X86_FEATURE_RSB_VMEXIT_LITE (11*32+ 6) /* "" Fill RSB on VM-Exit w= hen EIBRS is enabled */ =20 /* Intel-defined CPU features, CPUID level 0x00000007:1 (EAX), word 12 */ #define X86_FEATURE_AVX512_BF16 (12*32+ 5) /* AVX512 BFLOAT16 instruction= s */ From nobody Sat Apr 11 15:26:33 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BCDC9C19F2D for ; Tue, 9 Aug 2022 18:09:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345132AbiHISJU (ORCPT ); Tue, 9 Aug 2022 14:09:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51948 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345069AbiHISIn (ORCPT ); Tue, 9 Aug 2022 14:08:43 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DE4792613C; Tue, 9 Aug 2022 11:03:37 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 7DBA761118; Tue, 9 Aug 2022 18:03:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E767AC43470; Tue, 9 Aug 2022 18:03:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1660068217; bh=HZjsLh9G/XseI4c+wAmiE/T9/sW2B0EUIKAtM7s2Wyk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dUiS6DWR8seUhj39Yb3c6FfiGqNBfv4Q96eJMuEoR5mTM6bPhhavNTdNd1Pmy4hCn QldTQ3lE9MYerpZFQNG2ASTHLF2T6W8Cg7aWRs9bgyCR7C4DaOo7wq8cp1zfH/BIbn YFLHsokwItyDqQJrIZlX1qzimqBtAIxY0LSWFRu8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Andrew Cooper , Pawan Gupta , Borislav Petkov Subject: [PATCH 5.4 15/15] x86/speculation: Add LFENCE to RSB fill sequence Date: Tue, 9 Aug 2022 20:00:33 +0200 Message-Id: <20220809175510.849644425@linuxfoundation.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <20220809175510.312431319@linuxfoundation.org> References: <20220809175510.312431319@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Pawan Gupta commit ba6e31af2be96c4d0536f2152ed6f7b6c11bca47 upstream. RSB fill sequence does not have any protection for miss-prediction of conditional branch at the end of the sequence. CPU can speculatively execute code immediately after the sequence, while RSB filling hasn't completed yet. #define __FILL_RETURN_BUFFER(reg, nr, sp) \ mov $(nr/2), reg; \ 771: \ call 772f; \ 773: /* speculation trap */ \ pause; \ lfence; \ jmp 773b; \ 772: \ call 774f; \ 775: /* speculation trap */ \ pause; \ lfence; \ jmp 775b; \ 774: \ dec reg; \ jnz 771b; <----- CPU can miss-predict here. \ add $(BITS_PER_LONG/8) * nr, sp; Before RSB is filled, RETs that come in program order after this macro can be executed speculatively, making them vulnerable to RSB-based attacks. Mitigate it by adding an LFENCE after the conditional branch to prevent speculation while RSB is being filled. Suggested-by: Andrew Cooper Signed-off-by: Pawan Gupta Signed-off-by: Borislav Petkov Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/x86/include/asm/nospec-branch.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/arch/x86/include/asm/nospec-branch.h +++ b/arch/x86/include/asm/nospec-branch.h @@ -61,7 +61,9 @@ 774: \ dec reg; \ jnz 771b; \ - add $(BITS_PER_LONG/8) * nr, sp; + add $(BITS_PER_LONG/8) * nr, sp; \ + /* barrier for jnz misprediction */ \ + lfence; =20 #define __ISSUE_UNBALANCED_RET_GUARD(sp) \ call 881f; \