Re: [PATCH] ata: pata_parport: Fix use-after-free in new_device_store

Thank you for your contribution! Sashiko AI review found 2 potential issue(=
s) to consider:

Pre-existing issues:
- [High] Out-of-bounds array read due to lack of lower bound checking on us=
er-provided `mode`.
- [High] Kernel soft lockup (infinite busy-wait) due to negative `delay` va=
lues provided via sysfs.
--

--- Patch [1]: [PATCH] ata: pata_parport: Fix use-after-free in new_device_=
store ---
commit 8244d117e0d1faf887a5bd4b26650cebdd4ecedb
Author: Pei Xiao <[email protected]>

ata: pata_parport: Fix use-after-free in new_device_store

This commit fixes a use-after-free vulnerability in new_device_store() by
expanding the critical section protected by pi_mutex. It uses guard(mutex) =
to
ensure the driver pointer remains valid during lookup and subsequent uses,
preventing races with concurrent unregistration.

Closes: https://lore.kernel.org/lkml/20260728024015.2014674-1-shuangpeng.ke=
[email protected]/

> diff --git a/drivers/ata/pata_parport/pata_parport.c b/drivers/ata/pata_p=
arport/pata_parport.c
> index 40baeac594a9f..34f09192a4190 100644
> --- a/drivers/ata/pata_parport/pata_parport.c
> +++ b/drivers/ata/pata_parport/pata_parport.c

[ ... ]

> @@ -646,6 +648,7 @@ static ssize_t new_device_store(const struct bus_type=
 *bus, const char *buf, siz
>  		port_wanted =3D -1;
>  	}
> =20

[Severity: High]
This is a pre-existing issue, but does this sysfs input parsing properly
validate negative values for the mode parameter?

When new_device_store() uses sscanf() to read user input earlier in this
function, mode is parsed as a signed integer. If a user provides a negative
mode (e.g., -2), it bypasses the bounds check in pi_probe_mode(), which
uses a signed comparison:

drivers/ata/pata_parport/pata_parport.c:pi_probe_mode() {
    ...
    if (pi->mode >=3D max)
        return false;
    ...
}

This negative mode can then be passed to protocol drivers and used as an ar=
ray
index, which could result in an out-of-bounds memory read. For example, in
bpck6_open():

drivers/ata/pata_parport/bpck6.c:bpck6_open() {
    ...
    i =3D mode_map[pi->mode] & 0x0C;
    ...
}

Could a lower bound check be added for the mode parameter?

[Severity: High]
This is also a pre-existing issue, but does this function properly handle
negative values for the delay parameter?

Similar to the mode parameter, delay is parsed via sscanf() as a signed
integer without lower bounds checking. The delay is heavily used in the
subsystem via the delay_p macro:

drivers/ata/pata_parport/pata_parport.h:
#define delay_p         (pi->delay ? udelay(pi->delay) : (void)0)

Since udelay() takes an unsigned long, passing a negative delay will
implicitly cast it to a massive positive number (e.g., ULONG_MAX - 1). This
will cause udelay() to busy-wait for an effectively infinite amount of time,
resulting in a CPU soft lockup.

Could the delay parameter be validated to prevent it from being negative?

> +	guard(mutex)(&pi_mutex);
>  	drv =3D driver_find(protocol, &pata_parport_bus_type);
>  	if (!drv) {
>  		if (strcmp(protocol, "auto")) {

[ ... ]

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/7a9734be161cd051063=
[email protected]?part=3D1