linux-kernel - Re: [PATCH] cxacru: ADSL state management

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: <200704151208.59719.duncan.sands@math.u-psud.fr>
Date:	Sun, 15 Apr 2007 12:08:59 +0200
From:	Duncan Sands <duncan.sands@...h.u-psud.fr>
To:	Simon Arlott <simon@...e.lp0.eu>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...e.de>
Subject: Re: [PATCH] cxacru: ADSL state management

Hi Simon,

> +static ssize_t cxacru_sysfs_show_adsl_state(struct device *dev,
> +	struct device_attribute *attr, char *buf)
> +{
> +	struct usb_interface *intf = to_usb_interface(dev);
> +	struct usbatm_data *usbatm_instance = usb_get_intfdata(intf);
> +	struct cxacru_data *instance = usbatm_instance->driver_data;

instance could be NULL if cxacru_sysfs_show_adsl_state is called after
the device has been unbound.  What prevents this?

> +static ssize_t cxacru_sysfs_store_adsl_state(struct device *dev,
> +	struct device_attribute *attr, const char *buf, size_t count)

This is not serialized by a lock, so if two or more processes call it
simultaneously then the commands to the modem can be interleaved, which
could (a) leave it in a funky state, and (b) means that the value of poll
could be wrong when you write it to instance->poll_state, eg because the
processes could reach the poll_state writing step in reverse order to the
order in which they reached the sending-commands-to-the-modem step.

> @@ -503,6 +622,7 @@ static int cxacru_atm_start(struct usbatm_data *usbatm_instance,
>  	struct atm_dev *atm_dev = usbatm_instance->atm_dev;
>  	*/
>  	int ret;
> +	int start_polling = 1;
>  
>  	dbg("cxacru_atm_start");
>  
> @@ -522,7 +642,25 @@ static int cxacru_atm_start(struct usbatm_data *usbatm_instance,
>  	}
>  
>  	/* Start status polling */
> -	cxacru_poll_status(&instance->poll_work.work);
> +	mutex_lock(&instance->poll_state_serialize);
> +	switch (instance->poll_state) {

Can poll_state really have anything else than its initial
value here?

> +	mutex_unlock(&instance->poll_state_serialize);
> +
> +	if (start_polling)
> +		cxacru_poll_status(&instance->poll_work.work);

Between releasing the lock and calling cxacru_poll_status, another
process could have called cxacru_sysfs_store_adsl_state and changed
whether you want to poll or not.  I don't know if it matters.

> +	mutex_unlock(&instance->poll_state_serialize);
> +
> +	if (keep_polling)
> +		schedule_delayed_work(&instance->poll_work,
> +				round_jiffies_relative(POLL_INTERVAL*HZ));

Likewise.

> @@ -917,8 +1102,20 @@ static void cxacru_unbind(struct usbatm_data *usbatm_instance,
>  		return;
>  	}
>  
> -	while (!cancel_delayed_work(&instance->poll_work))
> -	       flush_scheduled_work();
> +	mutex_lock(&instance->poll_state_serialize);
> +	BUG_ON(instance->poll_state == CXPOLL_SHUTDOWN);
> +
> +	/* ensure that status polling continues unless
> +	 * it has already stopped */

Your device has been removed.  Why would you want to go on
polling?  Especially as your device structures are about to
be freed...  By the way, where do you remove the sysfs files?

> +	mutex_unlock(&instance->poll_state_serialize);
> +
> +	if (is_polling)
> +		cancel_rearming_delayed_work(&instance->poll_work);

This looks unreliable, again due to race conditions.  Better to always
shoot it down.

Ciao,

Duncan.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/