Re: Dirtiable inode bdi default != sb bdi btrfs
by Jan Kara
[Added CCs for similar ecryptfs warning]
On Thu 23-09-10 12:38:49, Andrew Morton wrote:
> > This started appearing for me on v2.6.36-rc5-49-gc79bd89; it did not
> > happen on v2.6.36-rc5-33-g1ce1e41, probably because it does not have
> > commit 692ebd17c2905313fff3c504c249c6a0faad16ec which introduces the
> > warning.
> > [...]
> > device fsid 44d595920ddedfa-3ece6b56e80f689e devid 1 transid 22342
> > /dev/mapper/vg_cesarbinspiro-lv_home
> > SELinux: initialized (dev dm-3, type btrfs), uses xattr
> > ------------[ cut here ]------------
> > WARNING: at fs/fs-writeback.c:87 inode_to_bdi+0x62/0x6d()
> > Hardware name: Inspiron N4010
> > Dirtiable inode bdi default != sb bdi btrfs
> > Modules linked in: ipv6 kvm_intel kvm uinput arc4 ecb
> > snd_hda_codec_intelhdmi snd_hda_codec_realtek iwlagn snd_hda_intel
> > iwlcore snd_hda_codec uvcvideo snd_hwdep mac80211 videodev snd_seq
> > snd_seq_device v4l1_compat snd_pcm atl1c v4l2_compat_ioctl32 btusb
> > cfg80211 snd_timer i2c_i801 bluetooth iTCO_wdt dell_wmi dell_laptop snd
> > pcspkr wmi dcdbas shpchp iTCO_vendor_support soundcore snd_page_alloc
> > rfkill joydev microcode btrfs zlib_deflate libcrc32c cryptd aes_x86_64
> > aes_generic xts gf128mul dm_crypt usb_storage i915 drm_kms_helper drm
> > i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan]
> > Pid: 1073, comm: find Not tainted 2.6.36-rc5+ #8
> > Call Trace:
> > [<ffffffff8104d0e4>] warn_slowpath_common+0x85/0x9d
> > [<ffffffff8104d19f>] warn_slowpath_fmt+0x46/0x48
> > [<ffffffff811308b7>] inode_to_bdi+0x62/0x6d
> > [<ffffffff81131b48>] __mark_inode_dirty+0xd0/0x177
> > [<ffffffff81127168>] touch_atime+0x107/0x12a
> > [<ffffffff81122384>] ? filldir+0x0/0xd0
> > [<ffffffff8112259b>] vfs_readdir+0x8d/0xb4
> > [<ffffffff8112270b>] sys_getdents+0x81/0xd1
> > [<ffffffff81009c72>] system_call_fastpath+0x16/0x1b
Thanks for the report. These bdi pointers are a mess. As Chris pointed
out, btrfs forgets to properly initialize inode->i_mapping.backing_dev_info
for directories and special inodes and thus these were previously attached
to default_backing_dev_info which probably isn't what Chris would like to
see.
I've also got a similar report for ecryptfs which also does not
initialize inode->i_mapping.backing_dev_info although it sets sb->s_bdi and
thus again its inodes get filed to default_backing_dev_info lists. Quick
search seems to reveal that other filesystems using handcrafted bdi's get
it wrong as well and thus their inodes end up in the default_backing_dev_info
lists which is generally undesirable (this was happening already before my
patch, my code just started complaining about that).
That suggests that we should probably handle such cases in a more generic
way by changing the code in inode_init_always(). The patch below makes at
least btrfs happy for me... Could you maybe test it? Thanks.
Honza
--
Jan Kara <jack(a)suse.cz>
SUSE Labs, CR
---
>From 29f60c2b08ff9637a10439d1513805835ddcc746 Mon Sep 17 00:00:00 2001
From: Jan Kara <jack(a)suse.cz>
Date: Mon, 27 Sep 2010 23:56:48 +0200
Subject: [PATCH] bdi: Initialize inode->i_mapping.backing_dev_info to sb->s_bdi
Currently, we initialize inode->i_mapping.backing_dev_info to the bdi of device
sb->s_bdev points to. However there is quite a big number of filesystems that
do not set sb->s_bdev (because they do not have one) but do set sb->s_bdi.
These filesystems would generally benefit from setting
inode->i_mapping.backing_dev_info to their s_bdi because otherwise their inodes
would point to default_backing_dev_info and thus dirty inode tracking would
happen there. So change inode initialization code to use sb->s_bdi if it
is available.
Signed-off-by: Jan Kara <jack(a)suse.cz>
---
fs/inode.c | 22 ++++++++++++++--------
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/fs/inode.c b/fs/inode.c
index 8646433..e415be4 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -172,15 +172,21 @@ int inode_init_always(struct super_block *sb, struct inode *inode)
mapping->writeback_index = 0;
/*
- * If the block_device provides a backing_dev_info for client
- * inodes then use that. Otherwise the inode share the bdev's
- * backing_dev_info.
+ * If the filesystem provides a backing_dev_info for client inodes
+ * then use that. Otherwise inodes share default_backing_dev_info.
*/
- if (sb->s_bdev) {
- struct backing_dev_info *bdi;
-
- bdi = sb->s_bdev->bd_inode->i_mapping->backing_dev_info;
- mapping->backing_dev_info = bdi;
+ if (sb->s_bdi && sb->s_bdi != &noop_backing_dev_info) {
+ /*
+ * Catch cases where filesystem might be bitten by using s_bdi
+ * instead of sb->s_bdev. Can be removed in 2.6.38.
+ */
+ if (sb->s_bdev) {
+ struct backing_dev_info *bdi =
+ sb->s_bdev->bd_inode->i_mapping->backing_dev_info;
+ WARN(bdi != sb->s_bdi, "s_bdev bdi %s != s_bdi %s\n",
+ bdi->name, sb->s_bdi->name);
+ }
+ mapping->backing_dev_info = sb->s_bdi;
}
inode->i_private = NULL;
inode->i_mapping = mapping;
--
1.6.4.2
12 years, 8 months
bluetooth: add support for btusb devices in recent MacBook Pros
by Will Woods
These two patches add support for the USB bluetooth controllers found
in recent MacBook Pro systems. In both cases the device class is
ff (vend.) rather than the usual e0. The iMac11,1 has the same
problem and is handled with an explicit USB_DEVICE() entry, so
these two devices are handled the same way.
(Apologies for sending the patches again - I forgot the Signed-off-by:
lines the first time.)
-w
12 years, 8 months
FYI: RIP: 0010:[<ffffffff8122f04f>] [<ffffffff8122f04f>] cfq_free_io_context+0x18/0x34
by Michał Piotrowski
Hi,
I noticed this in my dmesg
general protection fault: 0000 [#2] SMP
last sysfs file: /sys/fs/ecryptfs/version
CPU 2
Modules linked in: cbc cryptd aes_x86_64 aes_generic ecb ecryptfs
smsc47m192 hwmon_vid coretemp nf_conntrack_netbios_ns ip6t_REJECT
nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 iTCO_wdt i2c_i801
iTCO_vendor_support serio_raw r8169 mii sata_sil i915 drm_kms_helper
drm i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan]
Pid: 18329, comm: flush-8:16 Tainted: G D
2.6.35.5-29.fc13.x86_64 #1 D945GCLF2/
RIP: 0010:[<ffffffff8122f04f>] [<ffffffff8122f04f>]
cfq_free_io_context+0x18/0x34
RSP: 0018:ffff88000d909d90 EFLAGS: 00010202
RAX: 00000001075550e9 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000
RDX: 00000001075550ec RSI: ffff880005bd0dd0 RDI: 0000000000000282
RBP: ffff88000d909da0 R08: ffff880040225340 R09: 0000000000000000
R10: ffff88000d909d90 R11: dead000000200200 R12: ffff880040225340
R13: ffff8800785a8688 R14: 0000000000000000 R15: ffff88007c800000
FS: 0000000000000000(0000) GS:ffff880005a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00007f96ea945c03 CR3: 0000000077ab7000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process flush-8:16 (pid: 18329, threadinfo ffff88000d908000, task
ffff8800785a8000)
Stack:
ffff880040225340 ffff8800785a8000 ffff88000d909dd0 ffffffff812263db
<0> ffffffff812263a6 ffff8800785a8000 ffff8800785a8688 ffff880040225340
<0> ffff88000d909e10 ffffffff812264e7 ffffffff81226492 ffff8800785a8688
Call Trace:
[<ffffffff812263db>] put_io_context+0x69/0x9c
[<ffffffff812263a6>] ? put_io_context+0x34/0x9c
[<ffffffff812264e7>] exit_io_context+0xa0/0xad
[<ffffffff81226492>] ? exit_io_context+0x4b/0xad
[<ffffffff810555a1>] do_exit+0x786/0x7ba
[<ffffffff810f9965>] ? bdi_start_fn+0x0/0xda
[<ffffffff8106aebc>] kthreadd+0x0/0x13a
[<ffffffff8100aaa4>] kernel_thread_helper+0x4/0x10
[<ffffffff814a1310>] ? restore_args+0x0/0x30
[<ffffffff8106ae1a>] ? kthread+0x0/0xa2
[<ffffffff8100aaa0>] ? kernel_thread_helper+0x0/0x10
Code: 81 e8 48 93 e8 ff 41 5a 5b 41 5c 41 5d 41 5e 41 5f c9 c3 55 48
89 e5 41 54 53 0f 1f 44 00 00 48 8b 5f 78 49 89 fc 48 85 db 74 17 <48>
8b 03 48 8d 73 b0 4c 89 e7 0f 18 08 e8 45 ff ff ff 48 8b 1b
RIP [<ffffffff8122f04f>] cfq_free_io_context+0x18/0x34
RSP <ffff88000d909d90>
---[ end trace f5f95d6a4269a603 ]---
Fixing recursive fault but reboot is needed!
uname -a
Linux ozzy.pl 2.6.35.5-29.fc13.x86_64 #1 SMP Wed Sep 22 00:00:29 CEST
2010 x86_64 x86_64 x86_64 GNU/Linux
It's self compiled 2.6.35.5-29. I had not noticed this in earlier
versions. Full dmesg attached.
Regards,
Michal
12 years, 8 months
performance testing rawhide.
by Dave Jones
There have been a bunch of requests over time to off non-debug builds
of the rawhide kernel for people wanting to do performance regression testing etc
We could do this two ways.
- The notion that was put forward was to keep 'kernel' as being debug mode,
and add a 'kernel-nodebug'. So it's sort of the inverse of the releases.
- Stop making rawhide 'debug by default', and just start shipping kernel-debug
for rawhide as we do for releases.
The latter involves less uglification of the spec, but we're probably going
to lose a lot of testing if people aren't going to be running kernel-debug
by default. (How many reports do we get from kernel-debug users ? Not many).
thoughts?
Dave
12 years, 8 months
[PATCH 1/2] bluetooth: add support for controller in MacBookPro7,1
by Will Woods
As with iMac11,1 the device class is ff(vend.) instead of e0(wlcon).
output from 'usb-devices':
T: Bus=04 Lev=02 Prnt=04 Port=00 Cnt=01 Dev#= 5 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=05ac ProdID=8213 Rev=01.86
S: Manufacturer=Apple Inc.
S: Product=Bluetooth USB Host Controller
S: SerialNumber=58B0359C28ED
C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=00 Driver=(none)
---
drivers/bluetooth/btusb.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index d22ce3c..eac44e4 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -59,6 +59,9 @@ static struct usb_device_id btusb_table[] = {
/* Generic Bluetooth USB device */
{ USB_DEVICE_INFO(0xe0, 0x01, 0x01) },
+ /* Apple MacBookPro7,1 */
+ { USB_DEVICE(0x05ac, 0x8213) },
+
/* Apple iMac11,1 */
{ USB_DEVICE(0x05ac, 0x8215) },
--
1.7.2.3
12 years, 8 months
Fw: [kernel/f13/master] Fix CVE-2010-3080: /dev/sequencer open failure is not handled correctly
by Chuck Ebbert
Begin forwarded message:
Date: Wed, 15 Sep 2010 02:18:35 +0000 (UTC)
From: Chuck Ebbert <cebbert(a)fedoraproject.org>
To: kernel-owner(a)fedoraproject.org, scm-commits(a)lists.fedoraproject.org
Subject: [kernel/f13/master] Fix CVE-2010-3080: /dev/sequencer open failure is not handled correctly
commit 5bfd09461d7205c2b9fb83f97b00ae3e1ed19058
Author: Chuck Ebbert <cebbert(a)redhat.com>
Date: Tue Sep 14 22:17:35 2010 -0400
Fix CVE-2010-3080: /dev/sequencer open failure is not handled correctly
...le-free-at-error-path-of-snd_seq_oss_open.patch | 53 ++++++++++++++++++++
kernel.spec | 9 +++
2 files changed, 62 insertions(+), 0 deletions(-)
---
diff --git a/alsa-seq-oss-fix-double-free-at-error-path-of-snd_seq_oss_open.patch b/alsa-seq-oss-fix-double-free-at-error-path-of-snd_seq_oss_open.patch
new file mode 100644
index 0000000..73e65ec
--- /dev/null
+++ b/alsa-seq-oss-fix-double-free-at-error-path-of-snd_seq_oss_open.patch
@@ -0,0 +1,53 @@
+From: Takashi Iwai <tiwai(a)suse.de>
+Date: Mon, 6 Sep 2010 07:13:45 +0000 (+0200)
+Subject: ALSA: seq/oss - Fix double-free at error path of snd_seq_oss_open()
+X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;...
+
+ALSA: seq/oss - Fix double-free at error path of snd_seq_oss_open()
+
+The error handling in snd_seq_oss_open() has several bad codes that
+do dereferecing released pointers and double-free of kmalloc'ed data.
+The object dp is release in free_devinfo() that is called via
+private_free callback. The rest shouldn't touch this object any more.
+
+The patch changes delete_port() to call kfree() in any case, and gets
+rid of unnecessary calls of destructors in snd_seq_oss_open().
+
+Fixes CVE-2010-3080.
+
+Reported-and-tested-by: Tavis Ormandy <taviso(a)cmpxchg8b.com>
+Cc: <stable(a)kernel.org>
+Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
+---
+
+diff --git a/sound/core/seq/oss/seq_oss_init.c b/sound/core/seq/oss/seq_oss_init.c
+index 6857122..69cd7b3 100644
+--- a/sound/core/seq/oss/seq_oss_init.c
++++ b/sound/core/seq/oss/seq_oss_init.c
+@@ -281,13 +281,10 @@ snd_seq_oss_open(struct file *file, int level)
+ return 0;
+
+ _error:
+- snd_seq_oss_writeq_delete(dp->writeq);
+- snd_seq_oss_readq_delete(dp->readq);
+ snd_seq_oss_synth_cleanup(dp);
+ snd_seq_oss_midi_cleanup(dp);
+- delete_port(dp);
+ delete_seq_queue(dp->queue);
+- kfree(dp);
++ delete_port(dp);
+
+ return rc;
+ }
+@@ -350,8 +347,10 @@ create_port(struct seq_oss_devinfo *dp)
+ static int
+ delete_port(struct seq_oss_devinfo *dp)
+ {
+- if (dp->port < 0)
++ if (dp->port < 0) {
++ kfree(dp);
+ return 0;
++ }
+
+ debug_printk(("delete_port %i\n", dp->port));
+ return snd_seq_event_port_detach(dp->cseq, dp->port);
diff --git a/kernel.spec b/kernel.spec
index 90e84f7..15b40a2 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -802,6 +802,9 @@ Patch12540: execve-improve-interactivity-with-large-arguments.patch
Patch12541: execve-make-responsive-to-sigkill-with-large-arguments.patch
Patch12542: setup_arg_pages-diagnose-excessive-argument-size.patch
+# CVE-2010-3080
+Patch12550: alsa-seq-oss-fix-double-free-at-error-path-of-snd_seq_oss_open.patch
+
%endif
BuildRoot: %{_tmppath}/kernel-%{KVERREL}-root
@@ -1513,6 +1516,9 @@ ApplyPatch execve-improve-interactivity-with-large-arguments.patch
ApplyPatch execve-make-responsive-to-sigkill-with-large-arguments.patch
ApplyPatch setup_arg_pages-diagnose-excessive-argument-size.patch
+# CVE-2010-3080
+ApplyPatch alsa-seq-oss-fix-double-free-at-error-path-of-snd_seq_oss_open.patch
+
# END OF PATCH APPLICATIONS
%endif
@@ -2135,6 +2141,9 @@ fi
%changelog
* Tue Sep 14 2010 Chuck Ebbert <cebbert(a)redhat.com> 2.6.34.7-57
+- Fix CVE-2010-3080: /dev/sequencer open failure is not handled correctly
+
+* Tue Sep 14 2010 Chuck Ebbert <cebbert(a)redhat.com>
- Fix bug added in 2.6.34.6-53
* Tue Sep 14 2010 Chuck Ebbert <cebbert(a)redhat.com>
12 years, 8 months
Fw: [kernel/f14/master] Fix DOS with large argument lists.
by Chuck Ebbert
Begin forwarded message:
Date: Wed, 15 Sep 2010 01:06:16 +0000 (UTC)
From: Chuck Ebbert <cebbert(a)fedoraproject.org>
To: kernel-owner(a)fedoraproject.org, scm-commits(a)lists.fedoraproject.org
Subject: [kernel/f14/master] Fix DOS with large argument lists.
commit 14525abb6daa564fd076a6a111e05dada9bc442b
Author: Chuck Ebbert <cebbert(a)redhat.com>
Date: Tue Sep 14 21:05:09 2010 -0400
Fix DOS with large argument lists.
...mprove-interactivity-with-large-arguments.patch | 36 ++++++++++++++
...esponsive-to-sigkill-with-large-arguments.patch | 51 ++++++++++++++++++++
kernel.spec | 18 ++++++-
...rg_pages-diagnose-excessive-argument-size.patch | 42 ++++++++++++++++
4 files changed, 145 insertions(+), 2 deletions(-)
---
diff --git a/execve-improve-interactivity-with-large-arguments.patch b/execve-improve-interactivity-with-large-arguments.patch
new file mode 100644
index 0000000..7908e6c
--- /dev/null
+++ b/execve-improve-interactivity-with-large-arguments.patch
@@ -0,0 +1,36 @@
+From: Roland McGrath <roland(a)redhat.com>
+Date: Wed, 8 Sep 2010 02:36:28 +0000 (-0700)
+Subject: execve: improve interactivity with large arguments
+X-Git-Tag: v2.6.36-rc4~13
+X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;...
+
+execve: improve interactivity with large arguments
+
+This adds a preemption point during the copying of the argument and
+environment strings for execve, in copy_strings(). There is already
+a preemption point in the count() loop, so this doesn't add any new
+points in the abstract sense.
+
+When the total argument+environment strings are very large, the time
+spent copying them can be much more than a normal user time slice.
+So this change improves the interactivity of the rest of the system
+when one process is doing an execve with very large arguments.
+
+Signed-off-by: Roland McGrath <roland(a)redhat.com>
+Reviewed-by: KOSAKI Motohiro <kosaki.motohiro(a)jp.fujitsu.com>
+Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
+---
+
+diff --git a/fs/exec.c b/fs/exec.c
+index 1b63237..6f2d777 100644
+--- a/fs/exec.c
++++ b/fs/exec.c
+@@ -419,6 +419,8 @@ static int copy_strings(int argc, const char __user *const __user *argv,
+ while (len > 0) {
+ int offset, bytes_to_copy;
+
++ cond_resched();
++
+ offset = pos % PAGE_SIZE;
+ if (offset == 0)
+ offset = PAGE_SIZE;
diff --git a/execve-make-responsive-to-sigkill-with-large-arguments.patch b/execve-make-responsive-to-sigkill-with-large-arguments.patch
new file mode 100644
index 0000000..a9e531a
--- /dev/null
+++ b/execve-make-responsive-to-sigkill-with-large-arguments.patch
@@ -0,0 +1,51 @@
+From: Roland McGrath <roland(a)redhat.com>
+Date: Wed, 8 Sep 2010 02:37:06 +0000 (-0700)
+Subject: execve: make responsive to SIGKILL with large arguments
+X-Git-Tag: v2.6.36-rc4~12
+X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;...
+
+execve: make responsive to SIGKILL with large arguments
+
+An execve with a very large total of argument/environment strings
+can take a really long time in the execve system call. It runs
+uninterruptibly to count and copy all the strings. This change
+makes it abort the exec quickly if sent a SIGKILL.
+
+Note that this is the conservative change, to interrupt only for
+SIGKILL, by using fatal_signal_pending(). It would be perfectly
+correct semantics to let any signal interrupt the string-copying in
+execve, i.e. use signal_pending() instead of fatal_signal_pending().
+We'll save that change for later, since it could have user-visible
+consequences, such as having a timer set too quickly make it so that
+an execve can never complete, though it always happened to work before.
+
+Signed-off-by: Roland McGrath <roland(a)redhat.com>
+Reviewed-by: KOSAKI Motohiro <kosaki.motohiro(a)jp.fujitsu.com>
+Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
+---
+
+diff --git a/fs/exec.c b/fs/exec.c
+index 6f2d777..828dd24 100644
+--- a/fs/exec.c
++++ b/fs/exec.c
+@@ -376,6 +376,9 @@ static int count(const char __user * const __user * argv, int max)
+ argv++;
+ if (i++ >= max)
+ return -E2BIG;
++
++ if (fatal_signal_pending(current))
++ return -ERESTARTNOHAND;
+ cond_resched();
+ }
+ }
+@@ -419,6 +422,10 @@ static int copy_strings(int argc, const char __user *const __user *argv,
+ while (len > 0) {
+ int offset, bytes_to_copy;
+
++ if (fatal_signal_pending(current)) {
++ ret = -ERESTARTNOHAND;
++ goto out;
++ }
+ cond_resched();
+
+ offset = pos % PAGE_SIZE;
diff --git a/kernel.spec b/kernel.spec
index 1c0201b..b93fcf1 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -734,6 +734,11 @@ Patch12090: dell-wmi-add-support-for-eject-key-studio-1555.patch
Patch12517: flexcop-fix-xlate_proc_name-warning.patch
+# mitigate DOS attack with large argument lists
+Patch12520: execve-improve-interactivity-with-large-arguments.patch
+Patch12521: execve-make-responsive-to-sigkill-with-large-arguments.patch
+Patch12522: setup_arg_pages-diagnose-excessive-argument-size.patch
+
%endif
BuildRoot: %{_tmppath}/kernel-%{KVERREL}-root
@@ -1357,6 +1362,12 @@ ApplyPatch dell-wmi-add-support-for-eject-key-studio-1555.patch
# bz #575873
ApplyPatch flexcop-fix-xlate_proc_name-warning.patch
+
+# mitigate DOS attack with large argument lists
+ApplyPatch execve-improve-interactivity-with-large-arguments.patch
+ApplyPatch execve-make-responsive-to-sigkill-with-large-arguments.patch
+ApplyPatch setup_arg_pages-diagnose-excessive-argument-size.patch
+
# END OF PATCH APPLICATIONS
%endif
@@ -1943,10 +1954,13 @@ fi
# and build.
%changelog
-* Tue Sep 14 2010 Kyle McMartin <kyle(a)redhat.com> 2.6.35.4-28
+* Tue Sep 14 2010 Chuck Ebbert <cebbert(a)redhat.com> 2.6.35.4-28
+- Fix DOS with large argument lists.
+
+* Tue Sep 14 2010 Kyle McMartin <kyle(a)redhat.com>
- x86_64: plug compat syscalls holes. (CVE-2010-3081, CVE-2010-3301)
upgrading is highly recommended.
-- aio: check for multiplication overflow in do_io_submit.
+- aio: check for multiplication overflow in do_io_submit. (CVE-2010-3067)
* Mon Sep 13 2010 Chuck Ebbert <cebbert(a)redhat.com>
- Add support for perl and python scripting to perf (#632942)
diff --git a/setup_arg_pages-diagnose-excessive-argument-size.patch b/setup_arg_pages-diagnose-excessive-argument-size.patch
new file mode 100644
index 0000000..ead972a
--- /dev/null
+++ b/setup_arg_pages-diagnose-excessive-argument-size.patch
@@ -0,0 +1,42 @@
+From: Roland McGrath <roland(a)redhat.com>
+Date: Wed, 8 Sep 2010 02:35:49 +0000 (-0700)
+Subject: setup_arg_pages: diagnose excessive argument size
+X-Git-Tag: v2.6.36-rc4~14
+X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;...
+
+setup_arg_pages: diagnose excessive argument size
+
+The CONFIG_STACK_GROWSDOWN variant of setup_arg_pages() does not
+check the size of the argument/environment area on the stack.
+When it is unworkably large, shift_arg_pages() hits its BUG_ON.
+This is exploitable with a very large RLIMIT_STACK limit, to
+create a crash pretty easily.
+
+Check that the initial stack is not too large to make it possible
+to map in any executable. We're not checking that the actual
+executable (or intepreter, for binfmt_elf) will fit. So those
+mappings might clobber part of the initial stack mapping. But
+that is just userland lossage that userland made happen, not a
+kernel problem.
+
+Signed-off-by: Roland McGrath <roland(a)redhat.com>
+Reviewed-by: KOSAKI Motohiro <kosaki.motohiro(a)jp.fujitsu.com>
+Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
+---
+
+diff --git a/fs/exec.c b/fs/exec.c
+index 2d94552..1b63237 100644
+--- a/fs/exec.c
++++ b/fs/exec.c
+@@ -594,6 +594,11 @@ int setup_arg_pages(struct linux_binprm *bprm,
+ #else
+ stack_top = arch_align_stack(stack_top);
+ stack_top = PAGE_ALIGN(stack_top);
++
++ if (unlikely(stack_top < mmap_min_addr) ||
++ unlikely(vma->vm_end - vma->vm_start >= stack_top - mmap_min_addr))
++ return -ENOMEM;
++
+ stack_shift = vma->vm_end - stack_top;
+
+ bprm->p -= stack_shift;
12 years, 8 months
