Re: [PATCH v2] 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] Iterating over multiple protocols without breaking after a success=
ful probe causes a permanent deadlock on `parport_claim_or_block()`.
- [High] The `new_device` sysfs attribute does not enforce positive bounds =
for `mode`, `unit`, and `delay`, allowing negative values that cause out-of=
-bounds array accesses and CPU stalls.
--

--- Patch [1]: [PATCH v2] ata: pata_parport: Fix use-after-free in new_devi=
ce_store ---
commit 0903251c06a3e624fab8c81fa244b1596978b12b
Author: Pei Xiao <[email protected]>
ata: pata_parport: Fix use-after-free in new_device_store

The function new_device_store() calls driver_find() without protection agai=
nst
concurrent driver unregistration. This commit expands the critical section
protected by pi_mutex to fix a use-after-free.

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

> diff --git a/drivers/ata/pata_parport/pata_parport.c b/drivers/ata/pata_p=
arport/pata_parport.c
> --- a/drivers/ata/pata_parport/pata_parport.c
> +++ b/drivers/ata/pata_parport/pata_parport.c

[ ... ]

> @@ -646,18 +647,18 @@ static ssize_t new_device_store(const struct bus_ty=
pe *bus, const char *buf, siz
>  		port_wanted =3D -1;
>  	}
> =20

[Severity: High]
This is a pre-existing issue, but does this function properly validate the
bounds of user input for mode, unit, and delay?

If negative integers are provided in the sysfs write to new_device, they are
parsed as signed integers:

	if (sscanf(buf, "%11s %7s %d %d %d",
			port, protocol, &mode, &unit, &delay) < 1)

These negative values can bypass upper-bound checks and be used as array
indices:

drivers/ata/pata_parport/bpck6.c:bpck6_send_cmd() {
    ...
	switch (mode_map[pi->mode]) {
    ...
}

A negative delay can also be cast to a large unsigned value in udelay(),
potentially causing a permanent CPU stall:

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

Could we enforce positive bounds for these parameters?

> +	mutex_lock(&pi_mutex);
>  	drv =3D driver_find(protocol, &pata_parport_bus_type);
>  	if (!drv) {
>  		if (strcmp(protocol, "auto")) {
>  			pr_err("protocol %s not found\n", protocol);
> +			mutex_unlock(&pi_mutex);
>  			return -EINVAL;
>  		}
>  		pr_wanted =3D NULL;
>  	} else {
>  		pr_wanted =3D container_of(drv, struct pi_protocol, driver);
>  	}
> -
> -	mutex_lock(&pi_mutex);
>  	/* walk all parports */
>  	idr_for_each_entry(&parport_list, parport, port_num) {
>  		if (port_num =3D=3D port_wanted || port_wanted =3D=3D -1) {

[Severity: High]
This isn't a bug introduced by this patch, but does the protocol iteration
loop handle successful probes safely?

In the subsequent code in new_device_store():

			/* walk all protocols */
			idr_for_each_entry(&protocols, pr, pr_num) {
				if (pr =3D=3D pr_wanted || !pr_wanted)
					if (pi_init_one(parport, pr, mode, unit,
							delay))
						ok =3D true;
			}

And similarly in pata_parport_attach():

		/* probe this port using all protocols */
		idr_for_each_entry(&protocols, pr, pr_num)
			pi_init_one(port, pr, -1, -1, -1);

If a protocol successfully initializes, it claims the parport exclusively.
However, the loop doesn't break upon success and continues trying the next
protocol.

When the next protocol calls pi_init_one() and attempts to claim the exact
same port, it will block indefinitely in parport_claim_or_block() because
the port is already locked by the first protocol.

Could this result in a permanent deadlock during sysfs-driven instantiation
or module loading?

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