Description of problem: When transmitting L2TP frames, we derive the outgoing interface's UDP checksum hardware assist capabilities from the tunnel dst dev. This can sometimes be NULL, especially when routing protocols are used and routing changes occur. This patch just checks for NULL dst or dev pointers when checking for netdev hardware assist features. BUG: unable to handle kernel NULL pointer dereference at 0000000c IP: [<f89d074c>] pppol2tpxmit+0x341/0x4da [pppol2tp] pde = 00000000 Oops: 0000 [#1] SMP last sysfs file: /sys/class/net/lo/operstate Modules linked in: pppol2tp pppox pppgeneric slhc ipv6 dummy loop sndhdacodecatihdmi sndhdaintel sndhdacodec snd [...] Code: 8d 45 08 f0 ff 45 08 89 6b 08 c7 43 68 7e fb 9c f8 8a 45 24 83 e0 0c 3c 04 75 09 80 63 64 f3 e9 b4 00 00 00 8b 43 1 EIP: [<f89d074c>] pppol2tpxmit+0x341/0x4da [pppol2tp] SS:ESP 0068:f70a9cac CR2: 000000000000000c

Introduced in ffcebb16 (v2.6.29-rc1~581), fixed in 3feec909 (fixed in v2.6.34-rc2).

Upstream commit: http://git.kernel.org/linus/ffcebb16 http://git.kernel.org/linus/3feec909

Description of problem: The problem was in the way the gfs2 directory code was trying to re-use sentinel directory entries.

In the failing case, gfs2's rename function was renaming a file to another name that had the same non-trivial length. The file being renamed happened to be the first directory entry on the leaf block.

First, the rename code (gfs2rename in opsinode.c) found the original directory entry and decided it could do its job by simply replacing the directory entry with another. Therefore it determined correctly that no block allocations were needed.

Next, the rename code deleted the old directory entry prior to replacing it with the new name. Therefore, the soon-to-be replaced directory entry was temporarily made into a directory entry "sentinel" or a place holder at the start of a leaf block.

Lastly, it went to re-add the replacement directory entry in that leaf block. However, when gfs2direntfindspace was looking for space in the leaf block, it used the wrong value for the sentinel. That threw off its calculations so later it decides it can't really re-use the sentinel and therefore must allocate a new leaf block. But because it previously decided to re-use the directory entry, it didn't waste the time to grab a new block allocation for the inode. Therefore, the inode's ialloc pointer was still NULL and it crashes trying to reference it.

In the case of sentinel directory entries, the entire dirent is reused, not just the "free space" portion of it, and therefore the function gfs2direntfindspace should use the value 0 rather than GFS2DIRENTSIZE(0) for the actual dirent size.

Fixing this calculation enables the reproducer programs to work properly.

Last updated 24 July 2024

Description of problem: Discovered by Ben Hawkes, this patch adds a limit for nframes as the number of frames in TXSETUP and RXSETUP are derived from a single byte multiplex value by default. Use-cases that would require to send/filter more than 256 CAN frames should be implemented in userspace for complexity reasons anyway. Additionally the assignments of unsigned values from userspace to signed values in kernelspace and vice versa are fixed by using unsigned values in kernelspace consistently.

Upstream commit: http://git.kernel.org/linus/5b75c4973ce779520b9d1e392483207d6f842cde

Description of problem: It requires debugfs to be mounted on a local system

$ mount | grep debugfs none on /sys/kernel/debug type debugfs (rw) none on /var/lib/ureadahead/debugfs type debugfs (rw,relatime)

Tested with Ubuntu Maverick 10.04.1 with kernel 2.6.32-24-generic-pae. It's probably not exploitable in any meaningful way, although it produces page fault in kernel mode, and makes subsequent processes opening /sys/kernel/debug/tracing/setftracefilter (or setftracenotrace) unkillable, so it's a little bit of a DoS (or at least, annoyance).

Found via one of Tavis Ormandy's tools, I just quickly analyzed it and provided a testcase.

Acknowledgements:

Red Hat would like to thank Robert Swiecki of Google Security Team for reporting this issue.

Last updated 24 July 2024

arch/x86/kvm/x86.c in the Linux kernel before 2.6.36.2 does not initialize certain structure members, which allows local users to obtain potentially sensitive information from kernel stack memory via read operations on the /dev/kvm device.

Description of problem: There is a problem with the ioctl subsystem for drm, though it is most explicitly exposed by the intel GEM driver. Under driver-defined ioctls, drm does not sanitize the ioctl command, allowing the caller to specify how much memory should be kmalloc'd and copied back to the caller, regardless of what the driver ioctl actually does (it doesn't even need to succeed).

drivers/gpu/drm/drmdrv.c

long drmioctl(struct file filp, unsigned int cmd, unsigned long arg) ... unsigned int nr = DRMIOCTLNR(cmd); ... if ((nr >= DRMCOMMANDBASE) && (nr < DRMCOMMANDEND) && (nr < DRMCOMMANDBASE + dev->driver->numioctls)) ioctl = &dev->driver->ioctls[nr - DRMCOMMANDBASE]; ... if (cmd & (IOCIN | IOCOUT)) { if (IOCSIZE(cmd) <= sizeof(stackkdata)) { kdata = stackkdata; } else { kdata = kmalloc(IOCSIZE(cmd), GFPKERNEL); ... } } ... retcode = func(dev, kdata, filepriv); ... if (cmd & IOCOUT) { if (copytouser((void user )arg, kdata, IOCSIZE(cmd)) != 0) retcode = -EFAULT; }

"cmd" is caller-controlled, and can do whatever it likes for IOCSIZE(cmd), IOCIN and IOCOUT, resulting in leakage of previously freed kernel heap memory contents up to 16K in size.