rpms
/
kernel
2
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Drop patches merged in 2.6.38.2

This commit is contained in:
Chuck Ebbert 2011-03-27 20:28:12 -04:00
parent 3312da328f
commit 75edc04edd
4 changed files with 4 additions and 179 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
dcdbas-force-smi-to-happen-when-expected.patch
View File

@ -1,34 +0,0 @@
From: Stuart Hayes <stuart_hayes@yahoo.com>
Date: Wed, 2 Mar 2011 12:42:05 +0000 (+0100)
Subject: dcdbas: force SMI to happen when expected
X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=dd65c736d1b5312c80c88a64bf521db4959eded5
dcdbas: force SMI to happen when expected
The dcdbas driver can do an I/O write to cause a SMI to occur. The SMI handler
looks at certain registers and memory locations, so the SMI needs to happen
immediately. On some systems I/O writes are posted, though, causing the SMI to
happen well after the "outb" occurred, which causes random failures. Following
the "outb" with an "inb" forces the write to go through even if it is posted.
Signed-off-by: Stuart Hayes <stuart_hayes@yahoo.com>
Acked-by: Doug Warzecha <douglas_warzecha@dell.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
diff --git a/drivers/firmware/dcdbas.c b/drivers/firmware/dcdbas.c
index 69ad529..ea5ac2d 100644
--- a/drivers/firmware/dcdbas.c
+++ b/drivers/firmware/dcdbas.c
@@ -268,8 +268,10 @@ int dcdbas_smi_request(struct smi_cmd *smi_cmd)
}
/* generate SMI */
+ /* inb to force posted write through and make SMI happen now */
asm volatile (
- "outb %b0,%w1"
+ "outb %b0,%w1\n"
+ "inb %w1"
: /* no output args */
: "a" (smi_cmd->command_code),
"d" (smi_cmd->command_address),

64
fs-call-security_d_instantiate-in-d_obtain_alias.patch
View File

@ -1,64 +0,0 @@
From linux-fsdevel-owner@vger.kernel.org Thu Nov 18 21:03:11 2010
From: Josef Bacik <josef@redhat.com>
To: linux-fsdevel@vger.kernel.org, eparis@redhat.com,
linux-kernel@vger.kernel.org, sds@tycho.nsa.gov,
selinux@tycho.nsa.gov, bfields@fieldses.org
Subject: [PATCH] fs: call security_d_instantiate in d_obtain_alias V2
Date: Thu, 18 Nov 2010 20:52:55 -0500
Message-Id: <1290131575-2489-1-git-send-email-josef@redhat.com>
X-Mailing-List: linux-fsdevel@vger.kernel.org
While trying to track down some NFS problems with BTRFS, I kept noticing I was
getting -EACCESS for no apparent reason. Eric Paris and printk() helped me
figure out that it was SELinux that was giving me grief, with the following
denial
type=AVC msg=audit(1290013638.413:95): avc: denied { 0x800000 } for pid=1772
comm="nfsd" name="" dev=sda1 ino=256 scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
Turns out this is because in d_obtain_alias if we can't find an alias we create
one and do all the normal instantiation stuff, but we don't do the
security_d_instantiate.
Usually we are protected from getting a hashed dentry that hasn't yet run
security_d_instantiate() by the parent's i_mutex, but obviously this isn't an
option there, so in order to deal with the case that a second thread comes in
and finds our new dentry before we get to run security_d_instantiate(), we go
ahead and call it if we find a dentry already. Eric assures me that this is ok
as the code checks to see if the dentry has been initialized already so calling
security_d_instantiate() against the same dentry multiple times is ok. With
this patch I'm no longer getting errant -EACCESS values.
Signed-off-by: Josef Bacik <josef@redhat.com>
---
V1->V2:
-added second security_d_instantiate() call
fs/dcache.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/fs/dcache.c b/fs/dcache.c
index 5699d4c..85388fc 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1577,9 +1577,13 @@ struct dentry *d_obtain_alias(struct inode *inode)
spin_unlock(&tmp->d_lock);
spin_unlock(&inode->i_lock);
+ security_d_instantiate(tmp, inode);
+
return tmp;
out_iput:
+ if (res && !IS_ERR(res))
+ security_d_instantiate(res, inode);
iput(inode);
return res;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

21
kernel.spec
View File

@ -732,14 +732,6 @@ Patch12207: pci-pcie-links-may-not-get-configured-for-aspm-under-powersave-mode.
Patch12303: dmar-disable-when-ricoh-multifunction.patch
Patch12421: fs-call-security_d_instantiate-in-d_obtain_alias.patch
# Fix possible memory corruption on Dell HW
Patch12430: dcdbas-force-smi-to-happen-when-expected.patch
# CVE-2011-1182
Patch12431: prevent-rt_sigqueueinfo-and-rt_tgsigqueueinfo-from-spoofing-the-signal-code.patch
%endif
BuildRoot: %{_tmppath}/kernel-%{KVERREL}-root
@ -1366,15 +1358,6 @@ ApplyPatch acpi_reboot.patch
# rhbz#605888
ApplyPatch dmar-disable-when-ricoh-multifunction.patch
# rhbz#662344,600690
#ApplyPatch fs-call-security_d_instantiate-in-d_obtain_alias.patch
# Fix possible memory corruption on Dell HW
#ApplyPatch dcdbas-force-smi-to-happen-when-expected.patch
# CVE-2011-1182
#ApplyPatch prevent-rt_sigqueueinfo-and-rt_tgsigqueueinfo-from-spoofing-the-signal-code.patch
# END OF PATCH APPLICATIONS
%endif
@ -1985,6 +1968,10 @@ fi
%changelog
* Sun Mar 27 2011 Chuck Ebbert <cebbert@redhat.com> 2.6.38.2-8
- Linux 2.6.38.2
- Drop patches merged in 2.6.38.2:
dcdbas-force-smi-to-happen-when-expected.patch
fs-call-security_d_instantiate-in-d_obtain_alias.patch
prevent-rt_sigqueueinfo-and-rt_tgsigqueueinfo-from-spoofing-the-signal-code.patch
- Fix more PCIe ASPM bugs:
kworker task over 65% after resume (#683156)
ASPM powersave mode does not get enabled

64
prevent-rt_sigqueueinfo-and-rt_tgsigqueueinfo-from-spoofing-the-signal-code.patch
View File

@ -1,64 +0,0 @@
From: Julien Tinnes <jln@google.com>
Date: Fri, 18 Mar 2011 22:05:21 +0000 (-0700)
Subject: Prevent rt_sigqueueinfo and rt_tgsigqueueinfo from spoofing the signal code
X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=da48524eb20662618854bb3df2db01fc65f3070c
Prevent rt_sigqueueinfo and rt_tgsigqueueinfo from spoofing the signal code
Userland should be able to trust the pid and uid of the sender of a
signal if the si_code is SI_TKILL.
Unfortunately, the kernel has historically allowed sigqueueinfo() to
send any si_code at all (as long as it was negative - to distinguish it
from kernel-generated signals like SIGILL etc), so it could spoof a
SI_TKILL with incorrect siginfo values.
Happily, it looks like glibc has always set si_code to the appropriate
SI_QUEUE, so there are probably no actual user code that ever uses
anything but the appropriate SI_QUEUE flag.
So just tighten the check for si_code (we used to allow any negative
value), and add a (one-time) warning in case there are binaries out
there that might depend on using other si_code values.
Signed-off-by: Julien Tinnes <jln@google.com>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
diff --git a/kernel/signal.c b/kernel/signal.c
index 4e3cff1..3175186 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2421,9 +2421,13 @@ SYSCALL_DEFINE3(rt_sigqueueinfo, pid_t, pid, int, sig,
return -EFAULT;
/* Not even root can pretend to send signals from the kernel.
- Nor can they impersonate a kill(), which adds source info. */
- if (info.si_code >= 0)
+ * Nor can they impersonate a kill()/tgkill(), which adds source info.
+ */
+ if (info.si_code != SI_QUEUE) {
+ /* We used to allow any < 0 si_code */
+ WARN_ON_ONCE(info.si_code < 0);
return -EPERM;
+ }
info.si_signo = sig;
/* POSIX.1b doesn't mention process groups. */
@@ -2437,9 +2441,13 @@ long do_rt_tgsigqueueinfo(pid_t tgid, pid_t pid, int sig, siginfo_t *info)
return -EINVAL;
/* Not even root can pretend to send signals from the kernel.
- Nor can they impersonate a kill(), which adds source info. */
- if (info->si_code >= 0)
+ * Nor can they impersonate a kill()/tgkill(), which adds source info.
+ */
+ if (info->si_code != SI_QUEUE) {
+ /* We used to allow any < 0 si_code */
+ WARN_ON_ONCE(info->si_code < 0);
return -EPERM;
+ }
info->si_signo = sig;
return do_send_specific(tgid, pid, sig, info);