linux-kernel - Re: [PATCH] clk: samsung: Fix out-of-bound access of of_match

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3fd98d2a-2891-4579-bbdb-52c48c7b50ab@kernel.org>
Date: Mon, 30 Sep 2024 12:33:42 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Jinjie Ruan <ruanjinjie@...wei.com>, s.nawrocki@...sung.com,
 cw00.choi@...sung.com, alim.akhtar@...sung.com, mturquette@...libre.com,
 sboyd@...nel.org, sunyeal.hong@...sung.com,
 linux-samsung-soc@...r.kernel.org, linux-clk@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] clk: samsung: Fix out-of-bound access of of_match_node()

On 27/09/2024 12:21, Jinjie Ruan wrote:
> Currently, there is no terminator entry for exynosautov920_cmu_of_match,
> hence facing below KASAN warning,
> 
> 	==================================================================
> 	BUG: KASAN: global-out-of-bounds in of_match_node+0x120/0x13c
> 	Read of size 1 at addr ffffffe31cc9e628 by task swapper/0/1
> 
> 	CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0+ #334
> 	Hardware name: linux,dummy-virt (DT)
> 	Call trace:
> 	 dump_backtrace+0x94/0xec
> 	 show_stack+0x18/0x24
> 	 dump_stack_lvl+0x90/0xd0
> 	 print_report+0x1f4/0x5b4
> 	 kasan_report+0xc8/0x110
> 	 __asan_report_load1_noabort+0x20/0x2c
> 	 of_match_node+0x120/0x13c
> 	 of_match_device+0x70/0xb4
> 	 platform_match+0xa0/0x25c
> 	 __device_attach_driver+0x7c/0x2d4
> 	 bus_for_each_drv+0x100/0x188
> 	 __device_attach+0x174/0x364
> 	 device_initial_probe+0x14/0x20
> 	 bus_probe_device+0x128/0x158
> 	 device_add+0xb3c/0x10fc
> 	 of_device_add+0xdc/0x150
> 	 of_platform_device_create_pdata+0x120/0x20c
> 	 of_platform_bus_create+0x2bc/0x620
> 	 of_platform_populate+0x58/0x108
> 	 of_platform_default_populate_init+0x100/0x120
> 	 do_one_initcall+0x110/0x788
> 	 kernel_init_freeable+0x44c/0x61c
> 	 kernel_init+0x24/0x1e4
> 	 ret_from_fork+0x10/0x20
> 
> 	The buggy address belongs to the variable:
> 	 exynosautov920_cmu_of_match+0xc8/0x2c80
> 
> 	The buggy address belongs to the virtual mapping at
> 	 [ffffffe31c7d0000, ffffffe31d700000) created by:
> 	 paging_init+0x424/0x60c
> 
> 	The buggy address belongs to the physical page:
> 	page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4349e
> 	flags: 0x3fffe0000002000(reserved|node=0|zone=0|lastcpupid=0x1ffff)
> 	raw: 03fffe0000002000 fffffffec00d2788 fffffffec00d2788 0000000000000000
> 	raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
> 	page dumped because: kasan: bad access detected
> 
> 	Memory state around the buggy address:
> 	 ffffffe31cc9e500: f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9 00 00 00 00
> 	 ffffffe31cc9e580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 	>ffffffe31cc9e600: 00 00 00 00 00 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9
> 	                                  ^
> 	 ffffffe31cc9e680: f9 f9 f9 f9 00 00 06 f9 f9 f9 f9 f9 00 00 06 f9
> 	 ffffffe31cc9e700: f9 f9 f9 f9 00 00 06 f9 f9 f9 f9 f9 00 00 06 f9
> 	==================================================================

In the future, please the trim logs from entirely unrelated parts, like
addresses.

No need to resend for this.


Best regards,
Krzysztof