Re: CVE-2024-38630: watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger

[Jean Delvare]

Hi all,

On Fri, 2024-06-21 at 12:19 +0200, Greg Kroah-Hartman wrote:
> Description
> ===========
> 
> In the Linux kernel, the following vulnerability has been resolved:
> 
> watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger
> 
> When the cpu5wdt module is removing, the origin code uses del_timer() to
> de-activate the timer. If the timer handler is running, del_timer() could
> not stop it and will return directly. If the port region is released by
> release_region() and then the timer handler cpu5wdt_trigger() calls outb()
> to write into the region that is released, the use-after-free bug will
> happen.
> 
> Change del_timer() to timer_shutdown_sync() in order that the timer handler
> could be finished before the port region is released.
> 
> The Linux kernel CVE team has assigned CVE-2024-38630 to this issue.
> 
> 
> Affected and fixed versions
> ===========================
> 
>         Issue introduced in 3.8 with commit e09d9c3e9f85 and fixed in 6.6.33 with commit 9b1c063ffc07
>         Issue introduced in 3.8 with commit e09d9c3e9f85 and fixed in 6.9.4 with commit f19686d61650
>         Issue introduced in 3.8 with commit e09d9c3e9f85 and fixed in 6.10-rc1 with commit 573601521277

For the record, this is incorrect. The Fixes tag is misleading. The
commit being "fixed" was adding a missing del_timer() call, so the
situation was even worst before that, as the race window on module
removal was even larger.

The bug is present since kernel v2.5.61 when the cpu5wdt driver was
added to the kernel tree.

Also note that the bug was fixed using timer_shutdown_sync(), which is
documented as only being needed when the timer can be rearmed by a
workqueue or similar scenario, which is not the case here. So I'm
reasonably certain that using del_timer_sync() would have been
sufficient.

-- 
Jean Delvare
SUSE L3 Support