From: Marc-Christian Petersen <m.c.p@kernel.linux-systeme.com>

Solar Designer discovered an information leak in the ext3 code of Linux.
In a worst case an attacker could read sensitive data such as cryptographic
keys which would otherwise never hit disk media.  Theodore Ts'o developed a
correction for this.

From: Andy Lutomirski <luto@myrealbox.com>

Fixes from me, Olaf Dietsche <olaf+list.linux-kernel@olafdietsche.de>

In fs/exec.c, compute_creds does:

	task_lock(current);
	if (bprm->e_uid != current->uid || bprm->e_gid != current->gid) {
                 current->mm->dumpable = 0;

		if (must_not_trace_exec(current)
		    || atomic_read(&current->fs->count) > 1
		    || atomic_read(&current->files->count) > 1
		    || atomic_read(&current->sighand->count) > 1) {
			if(!capable(CAP_SETUID)) {
				bprm->e_uid = current->uid;
				bprm->e_gid = current->gid;
			}
		}
	}

         current->suid = current->euid = current->fsuid = bprm->e_uid;
         current->sgid = current->egid = current->fsgid = bprm->e_gid;

	task_unlock(current);

	security_bprm_compute_creds(bprm);

I assume the task_lock is to prevent another process (on SMP or preempt)
from ptracing the execing process between the check and the assignment.  If
that's the concern then the fact that the lock is dropped before the call
to security_brpm_compute_creds means that, if security_bprm_compute_creds
does anything interesting, there's a race.

For my (nearly complete) caps patch, I obviously need to fix this.  But I
think it may be exploitable now.  Suppose there are two processes, A (the
malicious code) and B (which uses exec).  B starts out unprivileged (A and
B have, e.g., uid and euid = 500).

1. A ptraces B.

2. B calls exec on some setuid-root program.

3. in cap_bprm_set_security, B sets bprm->cap_permitted to the full
   set.

4. B gets to compute_creds in exec.c, calls task_lock, and does not
   change its uid.

5. B calls task_unlock.

6. A detaches from B (on preempt or SMP).

7. B gets to task_lock in cap_bprm_compute_creds, changes its
   capabilities, and returns from compute_creds into load_elf_binary.

8. load_elf_binary calls create_elf_tables (line 852 in 2.6.5-mm1),
   which calls cap_bprm_secureexec (through LSM), which returns false (!).

9. exec finishes.

The setuid program is now running with uid=euid=500 but full permitted
capabilities.  There are two (or three) ways to effectively get local root
now:

1.  IIRC, linux 2.4 doesn't check capabilities in ptrace, so A could
   just ptrace B again.

2. LD_PRELOAD.

3.  There are probably programs that will misbehave on their own under
   these circumstances.

Is there some reason why this is not doable?

The patch renames bprm_compute_creds to bprm_apply_creds and moves all uid
logic into the hook, where the test and the resulting modification can both
happen under task_lock().

This way, out-of-tree LSMs will fail to compile instead of malfunctioning. 
It should also make life easier for LSMs and will certainly make it easier
for me to finish the cap patch.

From: Trond Myklebust <trond.myklebust@fys.uio.no>

The following patch fixes up a number of bugs in the NFSroot parser
rewrite from patchset
trond.myklebust@fys.uio.no|ChangeSet|20040411182341|00938

It also ensures that NFSroot mount options are consistent with the userland
"mount" program.

One of the stack size optimizations introduced a new static variable in
a function marked with __init.  But the variable is not marked
appropriately and so 1k of data is never freed.

into ppc970.osdl.org:/home/torvalds/v2.6/linux

Remove bogus assert in CFQ and remove merge hints.

From: Ralf Baechle <ralf@linux-mips.org>

- more work on resurrecting AMD Alchemy platforms
- cleanup of unnecessary <asm/pgalloc.h> inclusions
- update default config files
- cleanup 32-bit compat ioctl code
- support for Montum Jaguar ATX
- workarounds for early revs of the RM9000
- fixes for RM5000 and RM7000 cache handling
- add support for PMC-Sierra Yosemite eval board
- further cleanup and bugfixes for SGI IP27
- make LASAT and VR41xx build and work in 2.6
- improved SGI IP32 support
- plenty of small fixes

From: Ralf Baechle <ralf@linux-mips.org>

The pending changes to the MIPS doc files, more changes needed...

From: Ralf Baechle <ralf@linux-mips.org>

Limit the DZ driver to MIPS32 as the supported hardware is only present in
R2k/R3k-based systems (unless someone sends Maciej a PMAC-A board for driver
development).

From: Christoph Hellwig <hch@lst.de>

We don't need a copy of COPYING down in fs/hfs.  Roman said he didn't mind,
so..

From: "Pedro Emanuel M. D. Pinto" <pepinto@student.dei.uc.pt>

This currently-unused function is incorrectly implemented.  Fix.

Remove a duplicated case which recently snuck in there.

From: Hugh Dickins <hugh@veritas.com>

Jamie points out that madvise(MADV_DONTNEED) should unmap pages from a
nonlinear area in such a way that the nonlinear offsets are preserved if the
pages do turn out to be needed later after all, instead of reverting them to
linearity: needs to pass down a zap_details block.

(But this still leaves mincore unaware of nonlinear vmas: bigger job.)

From: Chris Mason <mason@suse.com>

reiserfs-delayed-work started using queue_delayed_work, but did not make sure
the timer was finished before it freed the work queue structs during unmount. 
This leads to timer oopsen if you unmount at just the right time.

Ulrich has been working on the glibc code using posix-timers and
stressing it more now than it has before.  He ran into an SMP deadlock
on process exit in the case there are pending queued signals from a
timer.

The deadlock arises because in the path through exit_itimers, the
tasklist_lock is already held (for writing).  When a timer is being
deleted, sigqueue_free will try to take it (for reading) in the case
where that timer has a pending signal queued on somebody's queue.  This
patch avoids the problem by making sure the queues are flushed before
calling exit_itimers, thus ensuring its code path won't try to take
tasklist_lock.

My message queue patch fixes the 64 bits -> 32 bits conversion of
siginfo, but didn't change the 32 -> 64 bits conversion done in
sys32_rt_sigqueueinfo() which was apparently bogus as well.

After much discussion & debate on the right way of converting that
structure, I decided to go the sparc64 / s390 way, and not the x86_64
way, that is to copy the various unions data "as is". This guarantees
that whatever a 32 bist app passes there, another 32 bits app will
understand it. Crossover between 32 and 64 bits apps on such things
as home-made userland siginfo isn't something we can help with anyway.

The x86_64 choice of converting as if it was an RT signal, thus
converting the sigval, cannot easily be applied to big endian archs
since the sigval is a union of a ptr and an int, on BE, the int
happens to be on the wrong half of the 64 bits ptr, thus  we can't
do a simple conversion.

Add generic ide_init_hwif_ports() to <linux/ide.h> and remove arch specific
versions except arm26, arm, h8300, i386-pc9800, m68k and m68knommu ones.

init_ide_data() initializes default IDE interfaces but without default IRQ
(hwif->irq and hwif->hw.irq fields) so introduce ide_init_default_irq() and
remove redundant ide_init_default_hwifs() (except arm26 and arm ones).

As a side-effect it fixes:
- CONFIG_BLK_DEV_HD_IDE if !CONFIG_BLK_DEV_IDEPCI (i386)
- hwif->noprobe shouldn't be 0 if !hwif->io_ports[IDE_DATA_OFFSET]
  (alpha, i386, ia64, mips, sh, x86_64)

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into ppc970.osdl.org:/home/torvalds/v2.6/linux

The following patch allows hw_random.c to build on ia64.  (The problem
was just that the VIA stuff has i386 assembly in it.  The current code
only probes for VIA on i386 anyway, so this patch just adds more ifdefs
so the VIA code is only built for i386.)

into ppc970.osdl.org:/home/torvalds/v2.6/linux

My tulip ethernet card doesn't work on Blue&White G3 PowerMac with Linux
2.6.5-rc2.  The card is shown by lspci as

01:03.0 Ethernet controller: Linksys Network Everywhere Fast Ethernet
10/100 model NC100 (rev 11)

The kernel detects it as "ADMtek Comet rev 17".

The MAC address reported by the kernel looked obviously wrong.  Also, I
could only ping the system successfully if the interface was in promiscuous
mode (running Ethereal).

Those two symptoms indicated two different problems - one for reading the
MAC address from the card on module load (tulip_init_one), and the other
for writing the address to the card when the interface was brought up
(tulip_up).  I have fixed both, and here's the explanation:

tulip_init_one:

When reading the first 4 bytes of the address, inl() returns the same data
to the CPU on all platforms, interpreting the data from the lowest port
address as the least significant byte.  In other words, I/O is little
endian on all platforms; it's the memory that differs across platforms.
We want to write the data to memory preserving little-endianness of the
PCI bus.  To force little endian write to the memory, the data should be
converted to the little endian format.

When reading the remaining 2 bytes, the CPU gets them in 2 least
significant bytes.  To write those 2 bytes to the memory in a 16-bit
operation, they should be byte-swapped for the 16-bit operation.

tulip_up:

The first 4 bytes are processed correctly, but the code is confusing.
Reading from memory needs conversion to CPU format, while writing to I/O
ports doesn't.  So I replaced cpu_to_le32() to le32_to_cpu().

The second 2 bytes are read in a 16-bit memory operation, so they should
be passed to le16_to_cpu() rather than cpu_to_le32() to make them CPU
independent and suitable for outl().


All those conversions do nothing on little-endian machines, so they should
not be affected.

The patch has been tested.  The driver is working fine.  ping is OK, ssh
is OK, X11 over ssh is OK.  Even netconsole is working fine.

On Wednesday 24 March 2004 23:25, Jeff Garzik wrote:
> Daniel Ritz wrote:
> > clean up the last two instances of dev->priv in drivers/net/pcmcia.
> > against 2.6.5-rc2-bk.
> >
> > --- 1.27/drivers/net/pcmcia/3c589_cs.c	Wed Mar  3 01:03:51 2004
> > +++ edited/drivers/net/pcmcia/3c589_cs.c	Wed Mar 24 22:29:35 2004
> > @@ -716,7 +716,7 @@
> >  	  "status %4.4x.\n", dev->name, (long)skb->len,
> >  	  inw(ioaddr + EL3_STATUS));
> >
> > -    ((struct el3_private *)dev->priv)->stats.tx_bytes += skb->len;
> > +    ((struct el3_private *)netdev_priv(dev))->stats.tx_bytes += skb->len;
> >
> >      /* Put out the doubleword header... */
> >      outw(skb->len, ioaddr + TX_FIFO);
> > --- 1.24/drivers/net/pcmcia/ibmtr_cs.c	Wed Mar  3 01:06:03 2004
> > +++ edited/drivers/net/pcmcia/ibmtr_cs.c	Wed Mar 24 22:29:51 2004
> > @@ -444,7 +444,7 @@
> >          link->state &= ~DEV_PRESENT;
> >          if (link->state & DEV_CONFIG) {
> >  	    /* set flag to bypass normal interrupt code */
> > -	    ((struct tok_info *)dev->priv)->sram_virt |= 1;
> > +	    ((struct tok_info *)netdev_priv(dev))->sram_virt |= 1;
> >  	    netif_device_detach(dev);
> >  	    ibmtr_release(link);
>
>
> although the patch is OK, the code itself is a bit yucky.
>
> Can you please create a temporary variable, of struct el3_private or
> tok_info type, and eliminate that cast?
>
> struct el3_private *priv = netdev_priv(dev);
> priv->stats.tx_bytes += skb->len;
>
> Much nicer :)
>

agreed. here we go...

Used for sysfs support.

Please apply the following patch to 2.6.5-rc2-bk9 and 2.4.26-rc1 to
include support for the 79C976. Tested on IA32.

On Wed, 31 Mar 2004 15:05:16 -0500
Jeff Garzik <jgarzik@pobox.com> wrote:

> I really should remove the ability to configure 8139_RXBUF_IDX=3.

On Tue, Apr 13, 2004 at 02:35:40PM -0400, Jeff Garzik wrote:
> Russell,
>
> Would you be willing to provide an updated diff of this?

I didn't particularly like the PRIV() method implemented previously -
gcc appears to want to avoid some optimisations it if its an inline
function rather than a macro.

Also, 'ei_local' may look unused in some functions, but it's your
typical hidden-use-in-a-macro crap which 8390 likes.

In systems with mixed network cards, and all drivers compiled into
the kernel; the PCI device (eth0) will get probed first, before the ISA.

The problem is that the ISA device can mistakenly try to probe
for eth0.  The problem is that the ISA driver will not detect the failure
until it goes to call register_netdevice, and not all drivers have
perfect error unwind code.

This patch short circuits the device probe, so it won't bother
looking for devices that already are registered.

* Ken Ashcraft (ken@coverity.com) wrote:
> [BUG]
> /home/kash/linux/linux-2.6.5/drivers/net/e1000/e1000_ethtool.c:1494:e1000_ethtool_ioctl: ERROR:TAINT: 1487:1494:Passing unbounded user value "(regs).len" as arg 2 to function "copy_to_user", which uses it unsafely in model [SOURCE_MODEL=(lib,copy_from_user,user,taintscalar)] [SINK_MODEL=(lib,copy_to_user,user,trustingsink)]    [PATH=]
> 	}
> 	case ETHTOOL_GREGS: {
> 		struct ethtool_regs regs = {ETHTOOL_GREGS};
> 		uint32_t regs_buff[E1000_REGS_LEN];
>
> Start --->
> 		if(copy_from_user(&regs, addr, sizeof(regs)))
> 			return -EFAULT;
> 		e1000_ethtool_gregs(adapter, &regs, regs_buff);
> 		if(copy_to_user(addr, &regs, sizeof(regs)))
> 			return -EFAULT;
>
> 		addr += offsetof(struct ethtool_regs, data);
> Error --->
> 		if(copy_to_user(addr, regs_buff, regs.len))
> 			return -EFAULT;
>
> 		return 0;

Looks like a bug.  Possible patch below zeros the buffer (since it's not
filled completely by e1000_ethtool_gregs()), and truncates len.

I get the following warning in 2.6.5-mm6 and 2.6.6-rc1:

<--  snip  -->

...
  CC      drivers/net/tulip/timer.o
drivers/net/tulip/timer.c: In function `comet_timer':
drivers/net/tulip/timer.c:156: warning: unused variable `ioaddr'
...

<--  snip  -->


Since the
   [netdrvr tulip] add MII support for Comet chips
patch has removed the only use of this variable, the fix is simple:

They are now upstream, we don't need driver-local ones anymore.

Tangentially noticed by Stanford checker.