kernel September 2010

kernel@lists.fedoraproject.org

21 participants
10 discussions

Re: Dirtiable inode bdi default != sb bdi btrfs
by Jan Kara 29 Sep '10

29 Sep '10

[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

5 11

bluetooth: add support for btusb devices in recent MacBook Pros
by Will Woods 28 Sep '10

28 Sep '10

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

2 3

FYI: RIP: 0010:[<ffffffff8122f04f>] [<ffffffff8122f04f>] cfq_free_io_context+0x18/0x34
by Michał Piotrowski 26 Sep '10

26 Sep '10

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

5 15

performance testing rawhide.
by Dave Jones 26 Sep '10

26 Sep '10

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

8 10

[PATCH 1/2] bluetooth: add support for controller in MacBookPro7,1
by Will Woods 17 Sep '10

17 Sep '10

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

1 1

Fw: [kernel/f13/master] Fix CVE-2010-3080: /dev/sequencer open failure is not handled correctly
by Chuck Ebbert 15 Sep '10

15 Sep '10

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;a=… + +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>

1 0

Fw: [kernel/f14/master] Fix DOS with large argument lists.
by Chuck Ebbert 15 Sep '10

15 Sep '10

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;a=… + +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;a=… + +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;a=… + +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;

1 0

[PATCH 0/3] F-14 (2.6.35): add Ricoh e822 support
by Stanislaw Gruszka 09 Sep '10

09 Sep '10

We applied similar mmc patches to RHEL6, let's apply them also to Fedora. All patches are included now in upstream 2.6.36 kernel. Resolves RHBZ 596475.

1 3

[PATCH 0/4] F-13 (2.6.34): add Ricoh e822 support
by Stanislaw Gruszka 09 Sep '10

09 Sep '10

We applied similar mmc patches to RHEL6, let's apply them also to Fedora. All patches are included now in upstream 2.6.36 kernel. Resolves RHBZ 596475.

1 4

Assessing the Tux Strength - A security comparison bet
by David Sommerseth 03 Sep '10

03 Sep '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Interesting reading, comparing the security bits between Debian, Fedora, Gentoo Hardened, openSuSE and Ubuntu. <http://labs.mwrinfosecurity.com/notices/security_mechanisms_in_linux_enviro…> <http://labs.mwrinfosecurity.com/notices/assessing_the_tux_strength_part_2_i…> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkyAvwYACgkQIIWEatLf4Hc3PQCgr0Oz7PnN4JNozJ/B0jPyz01W /NMAnjHsqnfu6OB8rmrgqo7i8JsE53pj =SuGU -----END PGP SIGNATURE-----

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel September 2010