linux-kernel - Re: [PATCH] Fix proc_file

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: <20090807135806.ffd068e9.akpm@linux-foundation.org>
Date:	Fri, 7 Aug 2009 13:58:06 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Stefani Seibold <stefani@...bold.net>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] Fix proc_file_write missing ppos update

On Fri, 07 Aug 2009 22:27:10 +0200
Stefani Seibold <stefani@...bold.net> wrote:

> The following fix a long standing issue in the proc_file_write function,
> which doesn't update the ppos file position pointer.
> 
> This prevent the usage of multiple sequently writes on an opened proc
> file, because it is impossible to distinguish these due the offset is
> always 0.
> 
> Signed-off-by: Stefani Seibold <stefani@...bold.net>
> 
>  generic.c |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> --- linux-2.6.31-rc4.orig/fs/proc/generic.c	2009-08-07 22:05:57.000000000 +0200
> +++ linux-2.6.30-rc4/fs/proc/generic.c	2009-08-07 22:06:22.000000000 +0200
> @@ -219,9 +219,10 @@
>  		pde->pde_users++;
>  		spin_unlock(&pde->pde_unload_lock);
>  
> -		/* FIXME: does this routine need ppos?  probably... */
>  		rv = pde->write_proc(file, buffer, count, pde->data);
>  		pde_users_dec(pde);
> +		if (rv > 0)
> +			*ppos += rv;
>  	}
>  	return rv;
>  }

Yes, that's odd.

I worry that there might be procfs write handlers which are looking at
*ppos and whose behaviour might be altered by this patch.

<searches a bit>

Look at arch/s390/appldata/appldata_base.c:appldata_timer_handler().

static int
appldata_timer_handler(ctl_table *ctl, int write, struct file *filp,
			   void __user *buffer, size_t *lenp, loff_t *ppos)
{
	int len;
	char buf[2];

	if (!*lenp || *ppos) {
		*lenp = 0;
		return 0;
	}


Prior to your change, an application which opened that proc file and
repeatedly wrote to the fd would repeatedly start and stop the timer.

After your change, the second and successive writes would have no
effect unless the application was changed to lseek back to the start of
the "file".

And that was just the second file I looked at via

	$EDITOR $(grep -l '[*]ppos' $(grep -rl _proc_ .))
--
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/