diotest4 from LTP will crash client on NFS mount. Not a regression, 5.7 GA kernel has the same issue.

Unable to handle kernel NULL pointer dereference at 0000000000000038 RIP: [<ffffffff887aed65>] :nfs:putnfsopencontext+0x7/0x93 PGD 16bba2067 PUD 14bcd1067 PMD 0 Oops: 0000 [1] SMP last sysfs file: /devices/pci0000:00/0000:00:00.0/localcpus CPU 2 Modules linked in: nfs nfsd exportfs nfsacl authrpcgss autofs4 hidp rfcomm l2cap bluetooth lockd sunrpc cpufreqondemand acpicpufreq freqtable mperf iptREJECT ip6tREJECT xttcpudp ip6tablefilter ip6tables xtables be2iscsi ibiser rdmacm ibcm iwcm ibsa ibmad ibcore ibaddr iscsitcp bnx2i cnic ipv6 xfrmnalgo cryptoapi uio cxgb3i libcxgbi cxgb3 8021q libiscsitcp libiscsi2 scsitransportiscsi2 scsitransportiscsi dmmirror dmmultipath scsidh video backlight sbs powermeter hwmon i2cec dellwmi wmi button battery asusacpi acpimemhotplug ac parportpc lp parport joydev i2ci801 i2ccore idecd cdcether i7coreedac cdrom usbnet edacmc tpmtis tpm tpmbios bnx2 sg pcspkr dmraid45 dmmessage dmregionhash dmlog dmmod dmmemcache atapiix libata shpchp megaraidsas sdmod scsimod ext3 jbd uhcihcd ohcihcd ehcihcd Pid: 4577, comm: diotest4 Not tainted 2.6.18-296.el5 #1 RIP: 0010:[<ffffffff887aed65>] [<ffffffff887aed65>] :nfs:putnfsopencontext+0x7/0x93 RSP: 0018:ffff810153cc1d28 EFLAGS: 00010246 RAX: ffff81014df95b10 RBX: ffff81014df95840 RCX: ffff81017fe5e608 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff81014df95840 R08: ffff81014df95840 R09: 0000000000000000 R10: ffff81014df95840 R11: 0000000000000310 R12: 0000000000000000 R13: 0000000000001000 R14: ffff81014aff9218 R15: ffff81014ced68c0 FS: 00002b51e08b3af0(0000) GS:ffff810105524ec0(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000038 CR3: 000000014a8fb000 CR4: 00000000000006a0 Process diotest4 (pid: 4577, threadinfo ffff810153cc0000, task ffff81017fc877a0) Stack: ffff81014df95840 ffff81014df95840 ffff81014ced6898 ffffffff887b4459 fffffffffffffff4 ffffffff887ccca6 ffff810153cc1e68 0000000000001000 ffff810153cc1e08 ffff81014a335a00 0000000000001000 0000000000008000 Call Trace: [<ffffffff887b4459>] :nfs:nfsreaddatarelease+0x10/0x16 [<ffffffff887ccca6>] :nfs:nfsfiledirectread+0x1b8/0x52f [<ffffffff8000cf47>] dosyncread+0xc7/0x104 [<ffffffff887aef81>] :nfs:nfsopen+0x10b/0x125 [<ffffffff800a3346>] autoremovewakefunction+0x0/0x2e [<ffffffff8000b72f>] vfsread+0xcb/0x171 [<ffffffff80011d15>] sysread+0x45/0x6e [<ffffffff8005d28d>] tracesys+0xd5/0xe0

Code: 48 8b 47 38 48 89 fb 48 8b 68 10 48 8d b5 b4 00 00 00 e8 c9 RIP [<ffffffff887aed65>] :nfs:putnfsopencontext+0x7/0x93 RSP <ffff810153cc1d28> CR2: 0000000000000038 <0>Kernel panic - not syncing: Fatal exception

The ext4decodeerror function in fs/ext4/super.c in the ext4 filesystem in the Linux kernel before 2.6.32 allows user-assisted remote attackers to cause a denial of service (NULL pointer dereference), and possibly have unspecified other impact, via a crafted read-only filesystem that lacks a journal.

Description of problem: Name: CVE-2009-4306 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4306 Final-Decision: Interim-Decision: Modified: Proposed: Assigned: 20091212 Category: Reference: MISC:http://grsecurity.org/test/grsecurity-2.1.14-2.6.32-200912112157.patch Reference: MISC:http://twitter.com/fotisl/statuses/6568947714 Reference: MISC:http://twitter.com/spendergrsec/statuses/6551797457 Reference: MISC:http://twitter.com/spendergrsec/statuses/6567167692 Reference: MISC:http://twitter.com/spendergrsec/statuses/6569596339 Reference: MISC:http://twitter.com/spendergrsec/statuses/6572069107 Reference: MISC:http://twitter.com/spendergrsec/statuses/6583954567 Reference: MISC:http://twitter.com/tytso/statuses/6571730411

Unspecified vulnerability in the EXT4IOCMOVEEXT (aka move extents) ioctl implementation in the ext4 filesystem in the Linux kernel 2.6.32-git6 and earlier allows local users to cause a denial of service (filesystem corruption) via unknown vectors, a different vulnerability than CVE-2009-4131.

Description of problem: Jay Fenlason reported that anyone who can open any of the /dev/fw files on recent version of the new firewire stack can crash machines with ohci 1.0 controllers (or ohci 1.1 controllers that are being used in ohci 1.0 mode because of hardware bugs) by issuing certain ioctls. This causes a null pointer reference in {fw-,}ohci.c.

On machines with non-blacklisted ohci1.1 controllers, the call does nothing, which is a bug, but doesn't crash.

On Red Hat Enterprise Linux 5, the firewire modules are blacklisted by default, and if they are enabled, the default ownership of the /dev/fw nodes is root:root.

https://patchwork.kernel.org/patch/66747/

Description of problem: From 910123ba363623f15ffb5d05dd87bdf06d08c609 Mon Sep 17 00:00:00 2001 From: Akira Fujita <a-fujita.nec.com> Date: Sun, 6 Dec 2009 23:38:31 -0500 Subject: [PATCH] ext4: Fix insufficient checks in EXT4IOCMOVEEXT

This patch fixes three problems in the handling of the EXT4IOCMOVEEXT ioctl:

1. In current EXT4IOCMOVEEXT, there are read access mode checks for original and donor files, but they allow the illegal write access to donor file, since donor file is overwritten by original file data. To fix this problem, change access mode checks of original (r->r/w) and donor (r->w) files.

2. Disallow the use of donor files that have a setuid or setgid bits.

3. Call mntwantwrite() and mntdropwrite() before and after ext4moveextents() calling to get write access to a mount.

Signed-off-by: Akira Fujita <a-fujita.nec.com> Signed-off-by: "Theodore Ts'o" <tytso> --- fs/ext4/ioctl.c | 30 ++++++++++++++++++------------ fs/ext4/moveextent.c | 7 +++++++ 2 files changed, 25 insertions(+), 12 deletions(-)

diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c index 31e5ee0..b63d193 100644 --- a/fs/ext4/ioctl.c +++ b/fs/ext4/ioctl.c @@ -221,32 +221,38 @@ setversionout: struct file donorfilp; int err; + if (!(filp->fmode & FMODEREAD) || + !(filp->fmode & FMODEWRITE)) + return -EBADF; + if (copyfromuser(&me, (struct moveextent user )arg, sizeof(me))) return -EFAULT; + me.movedlen = 0; donorfilp = fget(me.donorfd); if (!donorfilp) return -EBADF; - if (!capable(CAPDACOVERRIDE)) { - if ((current->realcred->fsuid != inode->iuid) || - !(inode->imode & SIRUSR) || - !(donorfilp->fdentry->dinode->imode & - SIRUSR)) { - fput(donorfilp); - return -EACCES; - } + if (!(donorfilp->fmode & FMODEWRITE)) { + err = -EBADF; + goto mextout; } - me.movedlen = 0; + err = mntwantwrite(filp->fpath.mnt); + if (err) + goto mextout; + err = ext4moveextents(filp, donorfilp, me.origstart, me.donorstart, me.len, &me.movedlen); - fput(donorfilp); + mntdropwrite(filp->fpath.mnt); + if (me.movedlen > 0) + fileremovesuid(donorfilp); if (copytouser((struct moveextent )arg, &me, sizeof(me))) - return -EFAULT; - + err = -EFAULT; +mextout: + fput(donorfilp); return err; } diff --git a/fs/ext4/moveextent.c b/fs/ext4/moveextent.c index cad1e2e..82c415b 100644 --- a/fs/ext4/moveextent.c +++ b/fs/ext4/moveextent.c @@ -957,6 +957,13 @@ mextcheckarguments(struct inode originode, return -EINVAL; } + if (donorinode->imode & (SISUID|SISGID)) { + ext4debug("ext4 move extent: suid or sgid is set" + " to donor file [ino:orig %lu, donor %lu]\n", + originode->iino, donorinode->iino); + return -EINVAL; + } + / Ext4 move extent does not support swapfile / if (ISSWAPFILE(originode) || ISSWAPFILE(donorinode)) { ext4debug("ext4 move extent: The argument files should " -- 1.6.5.216.g5288a.dirty

Race condition in the mac80211 subsystem in the Linux kernel before 2.6.32-rc8-next-20091201 allows remote attackers to cause a denial of service (system crash) via a Delete Block ACK (aka DELBA) packet that triggers a certain state change in the absence of an aggregation session.

Lennert Buytenhek noticed that delBA handling in mac80211 was broken and has remotely triggerable problems, some of which are due to some code shuffling I did that ended up changing the order in which things were done -- this was

commit d75636ef9c1af224f1097941879d5a8db7cd04e5 Author: Johannes Berg <johannes> Date: Tue Feb 10 21:25:53 2009 +0100

mac80211: RX aggregation: clean up stop session

and other parts were already present in the original

commit d92684e66091c0f0101819619b315b4bb8b5bcc5 Author: Ron Rindjunsky <ron.rindjunsky> Date: Mon Jan 28 14:07:22 2008 +0200

mac80211: A-MPDU Tx add delBA from recipient support

The first problem is that I moved a BUGON before various checks -- thereby making it possible to hit. As the comment indicates, the BUGON can be removed since the ampduaction callback must already exist when the state is != IDLE.

The second problem isn't easily exploitable but there's a race condition due to unconditionally setting the state to OPERATIONAL when a delBA frame is received, even when no aggregation session was ever initiated. All the drivers accept stopping the session even then, but that opens a race window where crashes could happen before the driver accepts it. Right now, a WARNON may happen with non-HT drivers, while the race opens only for HT drivers.

For this case, there are two things necessary to fix it: 1) don't process spurious delBA frames, and be more careful about the session state; don't drop the lock

2) HT drivers need to be prepared to handle a session stop even before the session was really started -- this is true for all drivers (that support aggregation) but iwlwifi which can be fixed easily. The other HT drivers (ath9k and ar9170) are behaving properly already.

Description of problem: ext4: avoid divide by zero when trying to mount a corrupted file system If sloggroupsperflex is greater than 31, then groupsperflex will overflow and cause a divide by zero error. This can cause kernel BUG if such a file system is mounted. Upstream commit: http://git.kernel.org/linus/503358ae01b70ce6909d19dd01287093f6b6271c

References: http://bugzilla.kernel.org/showbug.cgi?id=14287 http://secunia.com/advisories/37658

The collectrxframe function in drivers/isdn/hisax/hfcusb.c in the Linux kernel before 2.6.32-rc7 allows attackers to have an unspecified impact via a crafted HDLC packet that arrives over ISDN and triggers a buffer under-read.

The dommappgoff function in mm/nommu.c in the Linux kernel before 2.6.31.6, when the CPU lacks a memory management unit, allows local users to cause a denial of service (OOPS) via an application that attempts to allocate a large amount of memory.

The getinstantiationkeyring function in security/keys/keyctl.c in the KEYS subsystem in the Linux kernel before 2.6.32-rc5 does not properly maintain the reference count of a keyring, which allows local users to gain privileges or cause a denial of service (OOPS) via vectors involving calls to this function without specifying a keyring by ID, as demonstrated by a series of keyctl request2 and keyctl list commands.

The updatecr8intercept function in arch/x86/kvm/x86.c in the KVM subsystem in the Linux kernel before 2.6.32-rc1 does not properly handle the absence of an Advanced Programmable Interrupt Controller (APIC), which allows local users to cause a denial of service (NULL pointer dereference and system crash) or possibly gain privileges via a call to the kvmvcpuioctl function.

Quote from the upstream commit: Debug registers may only be accessed from cpl 0. Unfortunately, vmx will code to emulate the instruction even though it was issued from guest userspace, possibly leading to an unexpected trap later.

Introduced in v2.6.30-rc1; Fixed in v2.6.32-rc1.

http://git.kernel.org/linus/0a79b009525b160081d75cef5dbf45817956acf2

Integer overflow in the kvmdevioctlgetsupportedcpuid function in arch/x86/kvm/x86.c in the KVM subsystem in the Linux kernel before 2.6.31.4 allows local users to have an unspecified impact via a KVMGETSUPPORTEDCPUID request to the kvmarchdevioctl function.

Quoting from upstream patch: On setting up the callback to the client, we attempt to use the same authentication flavor the client did. We find an rpc cred to use by calling rpcauthlookupcredcache(), which assumes that the given authentication flavor has a credentials cache. However, this is not required to be true--in particular, authnull does not use one. Instead, we should call the auth's lookupcred() method.

Without this, a client attempting to mount using nfsv4 and authnull triggers a null dereference.

The code was introduced in upstream commit 3cef9ab2 (v2.6.31-rc1), fixed in 886e3b7f (v2.6.32-rc1), and was later replaced by 80fc015b.

Description of problem: fusedirectio() has a loop where requests are allocated in each iteration. if allocation fails, the loop is broken out and follows into an unconditional fuseputrequest() on that invalid pointer."

Upstream commit: http://git.kernel.org/linus/f60311d5f7670d9539b424e4ed8b5c0872fc9e83

This can be triggered when the system is low on memory, and when the fuserequestalloc() function called from fusegetreq() fails. The fuseputrequest() function will then dereference the invalid pointer returned, resulting in a kernel oops.

This was introduced in 413ef8cb (v2.6.14-rc1) and fixed in v2.6.32-rc7.

Quoting from the upstream commit: Almost all r128's private ioctls require that the CCE state has already been initialised. However, most do not test that this has been done, and will proceed to dereference a null pointer. This may result in a security vulnerability, since some ioctls are unprivileged.

This adds a macro for the common initialisation test and changes all ioctl implementations that require prior initialisation to use that macro.

Also, r128doinitcce() does not test that the CCE state has not been initialised already. Repeated initialisation may lead to a crash or resource leak. This adds that test.

http://git.kernel.org/linus/7dc482dfeeeefcfd000d4271c4626937406756d7

Other references: http://secunia.com/advisories/36707/

Hi,

Description of problem:

execution of a particular program from the Arachne suite reliably causes a kernel panic due to a NULL-pointer dereference in nfs4proclock().

Version-Release number of selected component (if applicable):

2.6.18-164.2.1.el5

How reproducible:

always on NFSv4 mounted directories

Steps to Reproduce: 1. wget http://www.genoscope.cns.fr/externe/redhat/XMLMissingField 2. Save a copy on an NFSv4-mounted directory 3. Execute it Actual results:

Kernel panic

Expected results:

No panic

Additional info:

Console output:

Unable to handle kernel NULL pointer dereference at 0000000000000030 RIP: [<ffffffff8837b210>] :nfs:nfs4proclock+0x21f/0x3ad PGD 1026eec067 PUD 1026f2f067 PMD 0 Oops: 0000 [1] SMP last sysfs file: /block/dm-1/range CPU 0 Modules linked in: ipmidevintf ipmisi ipmimsghandler nfs lockd fscache nfsacl sunrpc bonding ipv6 xfrmnalgo cryptoapi video hwmon backlight sbs i2cec button battery asusacpi acpimemhotplug ac joydev sg shpchp i2cnforce2 i2ccore forcedeth dmsnapshot dmzero dmmod satanv libata mptsas mptscsih mptbase scsitransportsas sdmod scsimod ext3 jbd uhcihcd ohcihcd ehcihcd Pid: 4070, comm: XMLMissingField Not tainted 2.6.18-164.2.1.el5 #1 RIP: 0010:[<ffffffff8837b210>] [<ffffffff8837b210>] :nfs:nfs4proclock+0x21f/0x3ad RSP: 0018:ffff810819bdbdd8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff810827c52088 RSI: 0000000000000006 RDI: ffff810819bdbe38 RBP: ffff81081a6dfdc0 R08: 0000000000000001 R09: ffff810819bdbd68 R10: ffff810819bdbd68 R11: 00000000000000d0 R12: ffff810827c52088 R13: 0000000000000000 R14: ffff810819a9b930 R15: 0000000000000006 FS: 00002b97d31fc7b0(0000) GS:ffffffff803c1000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000030 CR3: 00000010268cb000 CR4: 00000000000006e0 Process XMLMissingField (pid: 4070, threadinfo ffff810819bda000, task ffff810827d6a7e0) Stack: 00000000000003e8 0000000000000000 ffff810819a9b930 ffffffff88373e4f 0000000000000000 0000000000000000 0000000000000000 0000000019a9ba40 ffff810819bdbe18 ffff810819bdbe18 0000000000000000 0000000000000000 Call Trace: [<ffffffff88373e4f>] :nfs:nfssyncinodewait+0x116/0x1db [<ffffffff8836a226>] :nfs:dosetlk+0x55/0x8c [<ffffffff80039e72>] fcntlsetlk+0x11e/0x273 [<ffffffff800b66fa>] auditsyscallentry+0x180/0x1b3 [<ffffffff8002e5bb>] sysfcntl+0x269/0x2dc [<ffffffff8005d28d>] tracesys+0xd5/0xe0

Code: 49 8b 45 30 4c 89 e6 4c 89 ef 45 8a 74 24 58 48 8b 40 18 48 RIP [<ffffffff8837b210>] :nfs:nfs4proclock+0x21f/0x3ad RSP <ffff810819bdbdd8> CR2: 0000000000000030 <0>Kernel panic - not syncing: Fatal exception

Also see http://www.spinics.net/linux/lists/linux-nfs/msg03357.html

Description of problem: Quote from this email: http://article.gmane.org/gmane.linux.kernel/896907

fixed upstream in commit b7058842c940ad2c08dd829b21e5c92ebe3b8758 in a different way

The ax25 code tried to use if (optlen < sizeof(int)) return -EINVAL;

as a security check against optlen being negative (or zero) in the set socket option.

Unfortunately, "sizeof(int)" is an unsigned property, with the result that the whole comparison is done in unsigned, letting negative values slip through.

This patch changes this to if (optlen < (int)sizeof(int)) return -EINVAL;

so that the comparison is done as signed, and negative values get properly caught.

References: http://git.kernel.org/linus/b7058842c940ad2c08dd829b21e5c92ebe3b8758 http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=b7058842c940ad2c08dd829b21e5c92ebe3b8758

The pollmodeio file for the megaraidsas driver in the Linux kernel 2.6.31.6 and earlier has world-writable permissions, which allows local users to change the I/O mode of the driver by modifying this file.

Description of problem: The megaraidsas driver exposes a number of driver attributes in sysfs. Many of these are read-only, just export information from the driver and are world-readable.

A couple of attributes are writable and may be used to change the behaviour of the driver (e.g. setting debug logging levels, selecting poll vs. interrupt I/O mode etc).

Some of these writable attributes are mistakenly created with world-writable permissions, e.g. dbglvl and pollmodeio:

rw-rw-rw- root root /sys/bus/pci/drivers/megaraidsas/dbglvl rw-rw-rw- root root /sys/bus/pci/drivers/megaraidsas/pollmodeio

$ grep 'DRIVERATTR.SIWUGO' drivers/scsi/megaraid/megaraidsas.c static DRIVERATTR(dbglvl, SIRUGO|SIWUGO, megasassysfsshowdbglvl, static DRIVERATTR(pollmodeio, SIRUGO|SIWUGO,

This would allow an unprivileged user to affect kernel driver behaviour and logging level.

Version-Release number of selected component (if applicable): 2.6.18-.el5

How reproducible: 100%

Steps to Reproduce: (On a system with megaraidsas loaded) 1. ls -l /sys/bus/pci/drivers/megaraidsas/dbglvl 2. ls -l /sys/bus/pci/drivers/megaraidsas/pollmodeio

Actual results: rw-rw-rw- root root /sys/bus/pci/drivers/megaraidsas/dbglvl rw-rw-rw- root root /sys/bus/pci/drivers/megaraidsas/pollmodeio

Expected results: rw------- root root /sys/bus/pci/drivers/megaraidsas/dbglvl rw------- root root /sys/bus/pci/drivers/megaraidsas/pollmodeio

Additional info:

Upstream made the dbdlvl permissions more restrictive:

commit 66dca9b8c50b5e59d3bea8b21cee5c6dae6c9c46 Author: Joe Malicki <jmalicki> Date: Thu Aug 14 17:14:48 2008 -0400

[SCSI] megaraidsas: remove sysfs dbglvl world writeable permissions /sys/bus/pci/drivers/megaraidsas/dbglvl defaults to being world-writable, which seems bad (letting any user affect kernel driver behavior and logging level). This turns off group and user write permissions, so that on typical production systems only root can write to it. [jejb: fix up rejections] Signed-off-by: Joseph Malicki <jmalicki> Acked-by: "Yang, Bo" <Bo.Yang> Signed-off-by: James Bottomley <James.Bottomley>

The pollmodeio pseudofile still has world-writable permissions upstream.

The getrandomint function in drivers/char/random.c in the Linux kernel before 2.6.30 produces insufficiently random numbers, which allows attackers to predict the return value, and possibly defeat protection mechanisms based on randomization, via vectors that leverage the function's tendency to "return the same value over and over again for long stretches of time."

The ttyldischangup function in drivers/char/ttyldisc.c in the Linux kernel 2.6.31-rc before 2.6.31-rc8 allows local users to cause a denial of service (system crash, sometimes preceded by a NULL pointer dereference) or possibly gain privileges via certain pseudo-terminal I/O activity, as demonstrated by KernelTtyTest.c.

The md driver (drivers/md/md.c) in the Linux kernel before 2.6.30.2 might allow local users to cause a denial of service (NULL pointer dereference) via vectors related to "suspend sysfs attributes" and the (1) suspendlostore or (2) suspendhistore functions. NOTE: this is only a vulnerability when sysfs is writable by an attacker.

The eisaeepromread function in the parisc isa-eeprom component (drivers/parisc/eisaeeprom.c) in the Linux kernel before 2.6.31-rc6 allows local users to access restricted memory via a negative ppos argument, which bypasses a check that assumes that ppos is positive and causes an out-of-bounds read in the readb function.

Description of problem: Dan Walsh's blog post mentioned in the previous comment details selinux-policy part of the issue tracked via bug #512284. As noted in the the blog, selinux-policy provides a boolean - allowunconfinedmmaplow - which controls whether mmapminaddr restriction is applied to the process. This boolean, however, did not work as expected, as unconfinedt domain (default domain for logged-in unprivileged users) was always permitted to map low memory pages regardless of the boolean setting. This problem with the boolean is being fixed and the fix will be included in future selinux-policy updates in RHEL5 and Fedora (see Dan's blog for NVRs).

Few notes specific to Red Hat Enterprise Linux 5: Support for mmapminaddr sysctl was not included in the GA version of RHEL5. It was only added in kernel update in 5.2 (it first appeared upstream in 2.6.24). selinux-policy was, to avoid breaking applications needing low memory pages mapping on upgrade from 5.1 to 5.2, configured to allow mmapzero in unconfined domains and only disallow it in confined domains (e.g. various network facing services). In 5.3, allowunconfinedmmaplow boolean was added, but it's default value for targeted policy was changed to on, i.e. allowing mmapzero in all unconfined domains by default. This default boolean value is planned to remain unchanged in 5.4.

It should also be noted, that even with allowunconfinedmmaplow boolean set to off, it is still possible for unconfinedt user to transition to other domain that is permitted to mmapzero, as details in the Dan's blog post. Upstream discussion on how to best address this issue is still ongoing.

Eric's proposed patches moving mmapminaddr check out of security were submitted. If they are accepted upstream, mmapminaddr will be checked before LSM hooks are called. Security modules will only be consulted if mmapminaddr check has passed (e.g. when mmapminaddr is 0), so SELinux may still be able to restrict mapping of the low pages / zero page for confined domains and permit mapping in unconfined, even when mmapminaddr is 0.

Eric's patches with further discussion: http://patchwork.kernel.org/patch/36540/ http://patchwork.kernel.org/patch/36539/

Updated version: http://patchwork.kernel.org/patch/36650/ http://patchwork.kernel.org/patch/36649/

Further discussion of the proposed change: http://thread.gmane.org/gmane.linux.kernel.lsm/9075

mmapminaddr on SELinux and non-SELinux systems http://eparis.livejournal.com/606.html

Confining the unconfined. Oxymoron? http://danwalsh.livejournal.com/30084.html

Kbase: http://kbase.redhat.com/faq/docs/DOC-18042

Heap-based buffer overflow in the parsetag3packet function in fs/ecryptfs/keystore.c in the eCryptfs subsystem in the Linux kernel before 2.6.30.4 allows local users to cause a denial of service (system crash) or possibly gain privileges via vectors involving a crafted eCryptfs file, related to a large encrypted key size in a Tag 3 packet.

Stack-based buffer overflow in the parsetag11packet function in fs/ecryptfs/keystore.c in the eCryptfs subsystem in the Linux kernel before 2.6.30.4 allows local users to cause a denial of service (system crash) or possibly gain privileges via vectors involving a crafted eCryptfs file, related to not ensuring that the key signature length in a Tag 11 packet is compatible with the key signature buffer size.

The inet6checkestablished function in net/ipv6/inet6hashtables.c in the Linux kernel before 2.6.29, when Network Namespace Support (aka NETNS) is enabled, allows remote attackers to cause a denial of service (NULL pointer dereference and system crash) via vectors involving IPv6 packets.

Description of problem: AGP pages might be mapped into userspace finally, so the pages should be set to zero before userspace can use it. Otherwise there is potential information leakage.

Upstream patch: http://git.kernel.org/linus/59de2bebabc5027f93df999d59cc65df591c3e6e