linux-kernel - Re: Error returns not handled correctly by sysfs.c:subsys_attr

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]

Date:	Thu, 03 Jan 2008 16:51:13 -0700
From:	Andrew Patterson <andrew.patterson@...com>
To:	Tejun Heo <teheo@...e.de>
Cc:	Greg KH <greg@...ah.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-hotplug@...r.kernel.org,
	bjorn.helgaas@...com
Subject: Re: Error returns not handled
	correctly	by	sysfs.c:subsys_attr_store()

On Mon, 2007-12-03 at 14:15 -0700, Andrew Patterson wrote:
> On Thu, 2007-11-29 at 10:07 +0900, Tejun Heo wrote:
> > Andrew Patterson wrote:
> > > I tried with clean 2.6.24-rc3 and get the same bad behavior.  This is on
> > > an ia64 box, so maybe that is an issue. I can try on an x86 box as well.
> > > Oh, one other thing.  I tried a "uname -r" to make sure I had the
> > > correct kernel booted and got:
> > > 
> > > # uname -r
> > > 2.6.24-rc3
> > > x
> > > y
> > > z
> > > #
> > 
> > Yeah, please try it on another machine from clean tree.  sysfs code is
> > definitely not endian dependent and is 64 bit clean.  Heck, all my test
> > machines run 64 bit these days.  I would be surprised if it's something
> > architecture dependent but please try on a different machine with
> > different userland with kernel built from fresh source tree.
> > 
> > Thanks.
> 
> I tried this on a AMD system running an i386 kernel. I get the same bad
> behavior.  This is from a 2.6.24-rc3 kernel downloaded from kernel.org.
> I ran "make mrproper" followed by "make oldconfig" and accepted all the
> defaults for the config.
> 
> There is one slight change with this experiment.  Other nodes are not
> getting corrupted, i.e., uname -r is getting the correct value.

It looks like this is a shell issue.  After looking through the sysfs
code, I realized that this problem seems to be driven from user-land.
So I performed some experiments:

     1. Wrote a simple program that just used write(2) to write to the
        sysfs entry. This works fine.
     2. Used /bin/echo instead of the built-in echo command.  This too
        works fine.
     3. Tried several shells.  Zsh and Bash both fail.  Csh works fine.

I then ran strace on the following shell-script:

#!/bin/bash

echo x > allow_restart
echo y > allow_restart
echo z > allow_restart

and got:

# strace -e trace=write ~/tmp/tester.sh 
write(1, "x\n", 2)                      = -1 EINVAL (Invalid argument)
write(1, "x\n", 2)                      = -1 EINVAL (Invalid argument)
write(2, "/home/andrew/tmp/tester.sh: line"..., 72/home/andrew/tmp/tester.sh: line 4: echo: write error: Invalid argument
) = 72
write(1, "x\ny\n", 4)                   = -1 EINVAL (Invalid argument)
write(1, "x\ny\n", 4)                   = -1 EINVAL (Invalid argument)
write(2, "/home/andrew/tmp/tester.sh: line"..., 72/home/andrew/tmp/tester.sh: line 5: echo: write error: Invalid argument
) = 72
write(1, "x\ny\nz\n", 6)                = -1 EINVAL (Invalid argument)
write(1, "x\ny\nz\n", 6)                = -1 EINVAL (Invalid argument)
write(2, "/home/andrew/tmp/tester.sh: line"..., 72/home/andrew/tmp/tester.sh: line 6: echo: write error: Invalid argument
) = 72
write(1, "x\ny\nz\n", 6x
y
z
)                = 6
Process 3800 detached

As you can see, subsequent echo commands have their arguments appended
to the previous command. So it seems that the shell is not resetting the
buffer between failed echo commands.  

-- 
Andrew Patterson
Hewlett-Packard Company

--
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/