diff mbox series

thermal: core: Move initial num_trips assignment before memcpy()

Message ID 20240226-thermal-fix-fortify-panic-num_trips-v1-1-accc12a341d7@kernel.org
State Accepted
Commit da1983355ccefcfb3f8eb410fff82e250fa87e39
Headers show
Series thermal: core: Move initial num_trips assignment before memcpy() | expand

Commit Message

Nathan Chancellor Feb. 27, 2024, 12:54 a.m. UTC
When booting a CONFIG_FORTIFY_SOURCE=y kernel compiled with a toolchain
that supports __counted_by() (such as clang-18 and newer), there is a
panic on boot:

  [    2.913770] memcpy: detected buffer overflow: 72 byte write of buffer size 0
  [    2.920834] WARNING: CPU: 2 PID: 1 at lib/string_helpers.c:1027 __fortify_report+0x5c/0x74
  ...
  [    3.039208] Call trace:
  [    3.041643]  __fortify_report+0x5c/0x74
  [    3.045469]  __fortify_panic+0x18/0x20
  [    3.049209]  thermal_zone_device_register_with_trips+0x4c8/0x4f8

This panic occurs because trips is counted by num_trips but num_trips is
assigned after the call to memcpy(), so the fortify checks think the
buffer size is zero because tz was allocated with kzalloc().

Move the num_trips assignment before the memcpy() to resolve the panic
and ensure that the fortify checks work properly.

Fixes: 9b0a62758665 ("thermal: core: Store zone trips table in struct thermal_zone_device")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 drivers/thermal/thermal_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


---
base-commit: a85739c8c6894c3b9ff860e79e91db44cb59bd63
change-id: 20240226-thermal-fix-fortify-panic-num_trips-5f94094fb963

Best regards,

Comments

Kees Cook Feb. 28, 2024, 5:48 p.m. UTC | #1
On Wed, Feb 28, 2024 at 09:56:51AM -0700, Nathan Chancellor wrote:
> On Wed, Feb 28, 2024 at 08:41:07AM +0000, Lukasz Luba wrote:
> > Hi Nathan and Kees,
> > 
> > On 2/27/24 17:00, Kees Cook wrote:
> > > On Tue, Feb 27, 2024 at 05:47:44PM +0100, Daniel Lezcano wrote:
> > > > Ok my misunderstanding was I thought sizeof() was calling _bdos under the
> > > > hood, so when calling sizeof(flex_array), it was returning the computed size
> > > > inferring from the __counted_by field.
> > > 
> > > Yeah, sizeof() has a very limited scope. __builtin_object_size() has
> > > more flexibility (via the 2nd argument, "type"), but it was still
> > > compile-time only. __builtin_dynamic_object_size() was added to bring
> > > runtime evaluations into the mix (initially to support the alloc_size
> > > attribute, and now includes the counted_by attribute too).
> > > 
> > 
> > Thanks for your earlier emails explaining these stuff.
> > Do you have maybe some presentation about those features
> > for the kernel (ideally w/ a video from some conference)?
> 
> I think Kees's 2022 and 2023 talks at LPC are a good place to start:
> 
> https://youtu.be/tQwv79i02ks?si=Nj9hpvmQwPB4K3Y4&t=452
> https://youtu.be/OEFFqhP5sts?si=u6RnOP641S8FkouD&t=614
> 
> https://outflux.net/slides/2022/lpc/features.pdf
> https://outflux.net/slides/2023/lpc/features.pdf

I've also got a write-up on the entire topic of array bounds, which ends
with some discussion of "the future" (which is now) involving the use of
the "counted_by" attribute:
https://people.kernel.org/kees/bounded-flexible-arrays-in-c#coming-soon-annotate-bounds-of-flexible-arrays
Lukasz Luba Feb. 29, 2024, 7:42 a.m. UTC | #2
On 2/28/24 17:48, Kees Cook wrote:
> On Wed, Feb 28, 2024 at 09:56:51AM -0700, Nathan Chancellor wrote:
>> On Wed, Feb 28, 2024 at 08:41:07AM +0000, Lukasz Luba wrote:
>>> Hi Nathan and Kees,
>>>
>>> On 2/27/24 17:00, Kees Cook wrote:
>>>> On Tue, Feb 27, 2024 at 05:47:44PM +0100, Daniel Lezcano wrote:
>>>>> Ok my misunderstanding was I thought sizeof() was calling _bdos under the
>>>>> hood, so when calling sizeof(flex_array), it was returning the computed size
>>>>> inferring from the __counted_by field.
>>>>
>>>> Yeah, sizeof() has a very limited scope. __builtin_object_size() has
>>>> more flexibility (via the 2nd argument, "type"), but it was still
>>>> compile-time only. __builtin_dynamic_object_size() was added to bring
>>>> runtime evaluations into the mix (initially to support the alloc_size
>>>> attribute, and now includes the counted_by attribute too).
>>>>
>>>
>>> Thanks for your earlier emails explaining these stuff.
>>> Do you have maybe some presentation about those features
>>> for the kernel (ideally w/ a video from some conference)?
>>
>> I think Kees's 2022 and 2023 talks at LPC are a good place to start:
>>
>> https://youtu.be/tQwv79i02ks?si=Nj9hpvmQwPB4K3Y4&t=452
>> https://youtu.be/OEFFqhP5sts?si=u6RnOP641S8FkouD&t=614
>>
>> https://outflux.net/slides/2022/lpc/features.pdf
>> https://outflux.net/slides/2023/lpc/features.pdf
> 
> I've also got a write-up on the entire topic of array bounds, which ends
> with some discussion of "the future" (which is now) involving the use of
> the "counted_by" attribute:
> https://people.kernel.org/kees/bounded-flexible-arrays-in-c#coming-soon-annotate-bounds-of-flexible-arrays
> 

Thank you guys!
diff mbox series

Patch

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index bb21f78b4bfa..1eabc8ebe27d 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -1354,8 +1354,8 @@  thermal_zone_device_register_with_trips(const char *type,
 
 	tz->device.class = thermal_class;
 	tz->devdata = devdata;
-	memcpy(tz->trips, trips, num_trips * sizeof(*trips));
 	tz->num_trips = num_trips;
+	memcpy(tz->trips, trips, num_trips * sizeof(*trips));
 
 	thermal_set_delay_jiffies(&tz->passive_delay_jiffies, passive_delay);
 	thermal_set_delay_jiffies(&tz->polling_delay_jiffies, polling_delay);