linux-toradex.git, branch v2.6.27.5 Linux kernel for Apalis and Colibri modules Linux 2.6.27.5 2008-11-07T17:55:34+00:00 Greg Kroah-Hartman gregkh@suse.de 2008-11-07T17:55:34+00:00 788a5f3f70e2a9c46020bdd3a195f2a866441c5d 






net: Fix recursive descent in __scm_destroy().
2008-11-07T17:55:19+00:00

David Miller
davem@davemloft.net

2008-11-06T08:37:40+00:00

1dbbd0bf5d15397a4e4a1ae3e3e82e0fe4f83c3a

commit f8d570a4745835f2238a33b537218a1bb03fc671 and
3b53fbf4314594fa04544b02b2fc6e607912da18 upstream (because once wasn't
good enough...)

__scm_destroy() walks the list of file descriptors in the scm_fp_list
pointed to by the scm_cookie argument.

Those, in turn, can close sockets and invoke __scm_destroy() again.

There is nothing which limits how deeply this can occur.

The idea for how to fix this is from Linus.  Basically, we do all of
the fput()s at the top level by collecting all of the scm_fp_list
objects hit by an fput().  Inside of the initial __scm_destroy() we
keep running the list until it is empty.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>





commit f8d570a4745835f2238a33b537218a1bb03fc671 and
3b53fbf4314594fa04544b02b2fc6e607912da18 upstream (because once wasn't
good enough...)

__scm_destroy() walks the list of file descriptors in the scm_fp_list
pointed to by the scm_cookie argument.

Those, in turn, can close sockets and invoke __scm_destroy() again.

There is nothing which limits how deeply this can occur.

The idea for how to fix this is from Linus.  Basically, we do all of
the fput()s at the top level by collecting all of the scm_fp_list
objects hit by an fput().  Inside of the initial __scm_destroy() we
keep running the list until it is empty.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>







file caps: always start with clear bprm->caps_*
2008-11-07T03:05:55+00:00

Serge Hallyn
serue@us.ibm.com

2008-10-30T16:52:23+00:00

dcc5bc3d9f306cbb5e2f55d65bce1c8372b25fde

commit 3318a386e4ca68c76e0294363d29bdc46fcad670 upstream

While Linux doesn't honor setuid on scripts.  However, it mistakenly
behaves differently for file capabilities.

This patch fixes that behavior by making sure that get_file_caps()
begins with empty bprm->caps_*.  That way when a script is loaded,
its bprm->caps_* may be filled when binfmt_misc calls prepare_binprm(),
but they will be cleared again when binfmt_elf calls prepare_binprm()
next to read the interpreter's file capabilities.

Signed-off-by: Serge Hallyn <serue@us.ibm.com>
Acked-by: David Howells <dhowells@redhat.com>
Acked-by: Andrew G. Morgan <morgan@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>






commit 3318a386e4ca68c76e0294363d29bdc46fcad670 upstream

While Linux doesn't honor setuid on scripts.  However, it mistakenly
behaves differently for file capabilities.

This patch fixes that behavior by making sure that get_file_caps()
begins with empty bprm->caps_*.  That way when a script is loaded,
its bprm->caps_* may be filled when binfmt_misc calls prepare_binprm(),
but they will be cleared again when binfmt_elf calls prepare_binprm()
next to read the interpreter's file capabilities.

Signed-off-by: Serge Hallyn <serue@us.ibm.com>
Acked-by: David Howells <dhowells@redhat.com>
Acked-by: Andrew G. Morgan <morgan@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>








bonding: fix panic when taking bond interface down before removing module
2008-11-07T03:05:55+00:00

Andy Gospodarek
andy@greyhouse.net

2008-10-31T00:41:16+00:00

c17c98e2755a57e09f16432654f40027780cbacd

commit ce39a800ea87c655de49af021c8b20ee323cb40d upstream.

A panic was discovered with bonding when using mode 5 or 6 and trying to
remove the slaves from the bond after the interface was taken down.
When calling 'ifconfig bond0 down' the following happens:

    bond_close()
        bond_alb_deinitialize()
            tlb_deinitialize()
		kfree(bond_info->tx_hashtbl)
                bond_info->tx_hashtbl = NULL

Unfortunately if there are still slaves in the bond, when removing the
module the following happens:

    bonding_exit()
        bond_free_all()
            bond_release_all()
                bond_alb_deinit_slave()
                    tlb_clear_slave()
                        tx_hash_table = BOND_ALB_INFO(bond).tx_hashtbl
			u32 next_index = tx_hash_table[index].next

As you might guess we panic when trying to access a few entries into the
table that no longer exists.

I experimented with several options (like moving the calls to
tlb_deinitialize somewhere else), but it really makes the most sense to
be part of the bond_close routine.  It also didn't seem logical move
tlb_clear_slave around too much, so the simplest option seems to add a
check in tlb_clear_slave to make sure we haven't already wiped the
tx_hashtbl away before searching for all the non-existent hash-table
entries that used to point to the slave as the output interface.

Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>






commit ce39a800ea87c655de49af021c8b20ee323cb40d upstream.

A panic was discovered with bonding when using mode 5 or 6 and trying to
remove the slaves from the bond after the interface was taken down.
When calling 'ifconfig bond0 down' the following happens:

    bond_close()
        bond_alb_deinitialize()
            tlb_deinitialize()
		kfree(bond_info->tx_hashtbl)
                bond_info->tx_hashtbl = NULL

Unfortunately if there are still slaves in the bond, when removing the
module the following happens:

    bonding_exit()
        bond_free_all()
            bond_release_all()
                bond_alb_deinit_slave()
                    tlb_clear_slave()
                        tx_hash_table = BOND_ALB_INFO(bond).tx_hashtbl
			u32 next_index = tx_hash_table[index].next

As you might guess we panic when trying to access a few entries into the
table that no longer exists.

I experimented with several options (like moving the calls to
tlb_deinitialize somewhere else), but it really makes the most sense to
be part of the bond_close routine.  It also didn't seem logical move
tlb_clear_slave around too much, so the simplest option seems to add a
check in tlb_clear_slave to make sure we haven't already wiped the
tx_hashtbl away before searching for all the non-existent hash-table
entries that used to point to the slave as the output interface.

Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>








hfsplus: check read_mapping_page() return value
2008-11-07T03:05:55+00:00

Eric Sesterhenn
snakebyte@gmx.de

2008-10-16T05:04:10+00:00

c4305ddcd753bd84a465a2a319e7846f7783b439

While testing more corrupted images with hfsplus, i came across
one which triggered the following bug:

[15840.675016] BUG: unable to handle kernel paging request at fffffffb
[15840.675016] IP: [<c0116a4f>] kmap+0x15/0x56
[15840.675016] *pde = 00008067 *pte = 00000000
[15840.675016] Oops: 0000 [#1] PREEMPT DEBUG_PAGEALLOC
[15840.675016] Modules linked in:
[15840.675016]
[15840.675016] Pid: 11575, comm: ln Not tainted (2.6.27-rc4-00123-gd3ee1b4-dirty #29)
[15840.675016] EIP: 0060:[<c0116a4f>] EFLAGS: 00010202 CPU: 0
[15840.675016] EIP is at kmap+0x15/0x56
[15840.675016] EAX: 00000246 EBX: fffffffb ECX: 00000000 EDX: cab919c0
[15840.675016] ESI: 000007dd EDI: cab0bcf4 EBP: cab0bc98 ESP: cab0bc94
[15840.675016]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
[15840.675016] Process ln (pid: 11575, ti=cab0b000 task=cab919c0 task.ti=cab0b000)
[15840.675016] Stack: 00000000 cab0bcdc c0231cfb 00000000 cab0bce0 00000800 ca9290c0 fffffffb
[15840.675016]        cab145d0 cab919c0 cab15998 22222222 22222222 22222222 00000001 cab15960
[15840.675016]        000007dd cab0bcf4 cab0bd04 c022cb3a cab0bcf4 cab15a6c ca9290c0 00000000
[15840.675016] Call Trace:
[15840.675016]  [<c0231cfb>] ? hfsplus_block_allocate+0x6f/0x2d3
[15840.675016]  [<c022cb3a>] ? hfsplus_file_extend+0xc4/0x1db
[15840.675016]  [<c022ce41>] ? hfsplus_get_block+0x8c/0x19d
[15840.675016]  [<c06adde4>] ? sub_preempt_count+0x9d/0xab
[15840.675016]  [<c019ece6>] ? __block_prepare_write+0x147/0x311
[15840.675016]  [<c0161934>] ? __grab_cache_page+0x52/0x73
[15840.675016]  [<c019ef4f>] ? block_write_begin+0x79/0xd5
[15840.675016]  [<c022cdb5>] ? hfsplus_get_block+0x0/0x19d
[15840.675016]  [<c019f22a>] ? cont_write_begin+0x27f/0x2af
[15840.675016]  [<c022cdb5>] ? hfsplus_get_block+0x0/0x19d
[15840.675016]  [<c0139ebe>] ? tick_program_event+0x28/0x4c
[15840.675016]  [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
[15840.675016]  [<c022b723>] ? hfsplus_write_begin+0x2d/0x32
[15840.675016]  [<c022cdb5>] ? hfsplus_get_block+0x0/0x19d
[15840.675016]  [<c0161988>] ? pagecache_write_begin+0x33/0x107
[15840.675016]  [<c01879e5>] ? __page_symlink+0x3c/0xae
[15840.675016]  [<c019ad34>] ? __mark_inode_dirty+0x12f/0x137
[15840.675016]  [<c0187a70>] ? page_symlink+0x19/0x1e
[15840.675016]  [<c022e6eb>] ? hfsplus_symlink+0x41/0xa6
[15840.675016]  [<c01886a9>] ? vfs_symlink+0x99/0x101
[15840.675016]  [<c018a2f6>] ? sys_symlinkat+0x6b/0xad
[15840.675016]  [<c018a348>] ? sys_symlink+0x10/0x12
[15840.675016]  [<c01038bd>] ? sysenter_do_call+0x12/0x31
[15840.675016]  =======================
[15840.675016] Code: 00 00 75 10 83 3d 88 2f ec c0 02 75 07 89 d0 e8 12 56 05 00 5d c3 55 ba 06 00 00 00 89 e5 53 89 c3 b8 3d eb 7e c0 e8 16 74 00 00 <8b> 03 c1 e8 1e 69 c0 d8 02 00 00 05 b8 69 8e c0 2b 80 c4 02 00
[15840.675016] EIP: [<c0116a4f>] kmap+0x15/0x56 SS:ESP 0068:cab0bc94
[15840.675016] ---[ end trace 4fea40dad6b70e5f ]---

This happens because the return value of read_mapping_page() is passed on
to kmap unchecked.  The bug is triggered after the first
read_mapping_page() in hfsplus_block_allocate(), this patch fixes all
three usages in this functions but leaves the ones further down in the
file unchanged.

Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de>
Cc: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>






While testing more corrupted images with hfsplus, i came across
one which triggered the following bug:

[15840.675016] BUG: unable to handle kernel paging request at fffffffb
[15840.675016] IP: [<c0116a4f>] kmap+0x15/0x56
[15840.675016] *pde = 00008067 *pte = 00000000
[15840.675016] Oops: 0000 [#1] PREEMPT DEBUG_PAGEALLOC
[15840.675016] Modules linked in:
[15840.675016]
[15840.675016] Pid: 11575, comm: ln Not tainted (2.6.27-rc4-00123-gd3ee1b4-dirty #29)
[15840.675016] EIP: 0060:[<c0116a4f>] EFLAGS: 00010202 CPU: 0
[15840.675016] EIP is at kmap+0x15/0x56
[15840.675016] EAX: 00000246 EBX: fffffffb ECX: 00000000 EDX: cab919c0
[15840.675016] ESI: 000007dd EDI: cab0bcf4 EBP: cab0bc98 ESP: cab0bc94
[15840.675016]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
[15840.675016] Process ln (pid: 11575, ti=cab0b000 task=cab919c0 task.ti=cab0b000)
[15840.675016] Stack: 00000000 cab0bcdc c0231cfb 00000000 cab0bce0 00000800 ca9290c0 fffffffb
[15840.675016]        cab145d0 cab919c0 cab15998 22222222 22222222 22222222 00000001 cab15960
[15840.675016]        000007dd cab0bcf4 cab0bd04 c022cb3a cab0bcf4 cab15a6c ca9290c0 00000000
[15840.675016] Call Trace:
[15840.675016]  [<c0231cfb>] ? hfsplus_block_allocate+0x6f/0x2d3
[15840.675016]  [<c022cb3a>] ? hfsplus_file_extend+0xc4/0x1db
[15840.675016]  [<c022ce41>] ? hfsplus_get_block+0x8c/0x19d
[15840.675016]  [<c06adde4>] ? sub_preempt_count+0x9d/0xab
[15840.675016]  [<c019ece6>] ? __block_prepare_write+0x147/0x311
[15840.675016]  [<c0161934>] ? __grab_cache_page+0x52/0x73
[15840.675016]  [<c019ef4f>] ? block_write_begin+0x79/0xd5
[15840.675016]  [<c022cdb5>] ? hfsplus_get_block+0x0/0x19d
[15840.675016]  [<c019f22a>] ? cont_write_begin+0x27f/0x2af
[15840.675016]  [<c022cdb5>] ? hfsplus_get_block+0x0/0x19d
[15840.675016]  [<c0139ebe>] ? tick_program_event+0x28/0x4c
[15840.675016]  [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
[15840.675016]  [<c022b723>] ? hfsplus_write_begin+0x2d/0x32
[15840.675016]  [<c022cdb5>] ? hfsplus_get_block+0x0/0x19d
[15840.675016]  [<c0161988>] ? pagecache_write_begin+0x33/0x107
[15840.675016]  [<c01879e5>] ? __page_symlink+0x3c/0xae
[15840.675016]  [<c019ad34>] ? __mark_inode_dirty+0x12f/0x137
[15840.675016]  [<c0187a70>] ? page_symlink+0x19/0x1e
[15840.675016]  [<c022e6eb>] ? hfsplus_symlink+0x41/0xa6
[15840.675016]  [<c01886a9>] ? vfs_symlink+0x99/0x101
[15840.675016]  [<c018a2f6>] ? sys_symlinkat+0x6b/0xad
[15840.675016]  [<c018a348>] ? sys_symlink+0x10/0x12
[15840.675016]  [<c01038bd>] ? sysenter_do_call+0x12/0x31
[15840.675016]  =======================
[15840.675016] Code: 00 00 75 10 83 3d 88 2f ec c0 02 75 07 89 d0 e8 12 56 05 00 5d c3 55 ba 06 00 00 00 89 e5 53 89 c3 b8 3d eb 7e c0 e8 16 74 00 00 <8b> 03 c1 e8 1e 69 c0 d8 02 00 00 05 b8 69 8e c0 2b 80 c4 02 00
[15840.675016] EIP: [<c0116a4f>] kmap+0x15/0x56 SS:ESP 0068:cab0bc94
[15840.675016] ---[ end trace 4fea40dad6b70e5f ]---

This happens because the return value of read_mapping_page() is passed on
to kmap unchecked.  The bug is triggered after the first
read_mapping_page() in hfsplus_block_allocate(), this patch fixes all
three usages in this functions but leaves the ones further down in the
file unchanged.

Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de>
Cc: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>








hfsplus: fix Buffer overflow with a corrupted image
2008-11-07T03:05:55+00:00

Eric Sesterhenn
snakebyte@gmx.de

2008-10-16T05:04:08+00:00

e04d4d12ec20c70485c3410219704dd1ffb0ec15

commit efc7ffcb4237f8cb9938909041c4ed38f6e1bf40 upstream

When an hfsplus image gets corrupted it might happen that the catalog
namelength field gets b0rked.  If we mount such an image the memcpy() in
hfsplus_cat_build_key_uni() writes more than the 255 that fit in the name
field.  Depending on the size of the overwritten data, we either only get
memory corruption or also trigger an oops like this:

[  221.628020] BUG: unable to handle kernel paging request at c82b0000
[  221.629066] IP: [<c022d4b1>] hfsplus_find_cat+0x10d/0x151
[  221.629066] *pde = 0ea29163 *pte = 082b0160
[  221.629066] Oops: 0002 [#1] PREEMPT DEBUG_PAGEALLOC
[  221.629066] Modules linked in:
[  221.629066]
[  221.629066] Pid: 4845, comm: mount Not tainted (2.6.27-rc4-00123-gd3ee1b4-dirty #28)
[  221.629066] EIP: 0060:[<c022d4b1>] EFLAGS: 00010206 CPU: 0
[  221.629066] EIP is at hfsplus_find_cat+0x10d/0x151
[  221.629066] EAX: 00000029 EBX: 00016210 ECX: 000042c2 EDX: 00000002
[  221.629066] ESI: c82d70ca EDI: c82b0000 EBP: c82d1bcc ESP: c82d199c
[  221.629066]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
[  221.629066] Process mount (pid: 4845, ti=c82d1000 task=c8224060 task.ti=c82d1000)
[  221.629066] Stack: c080b3c4 c82aa8f8 c82d19c2 00016210 c080b3be c82d1bd4 c82aa8f0 00000300
[  221.629066]        01000000 750008b1 74006e00 74006900 65006c00 c82d6400 c013bd35 c8224060
[  221.629066]        00000036 00000046 c82d19f0 00000082 c8224548 c8224060 00000036 c0d653cc
[  221.629066] Call Trace:
[  221.629066]  [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
[  221.629066]  [<c013bca3>] ? trace_hardirqs_off_caller+0x14/0x9b
[  221.629066]  [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
[  221.629066]  [<c013bca3>] ? trace_hardirqs_off_caller+0x14/0x9b
[  221.629066]  [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
[  221.629066]  [<c0107aa3>] ? native_sched_clock+0x82/0x96
[  221.629066]  [<c01302d2>] ? __kernel_text_address+0x1b/0x27
[  221.629066]  [<c010487a>] ? dump_trace+0xca/0xd6
[  221.629066]  [<c0109e32>] ? save_stack_address+0x0/0x2c
[  221.629066]  [<c0109eaf>] ? save_stack_trace+0x1c/0x3a
[  221.629066]  [<c013b571>] ? save_trace+0x37/0x8d
[  221.629066]  [<c013b62e>] ? add_lock_to_list+0x67/0x8d
[  221.629066]  [<c013ea1c>] ? validate_chain+0x8a4/0x9f4
[  221.629066]  [<c013553d>] ? down+0xc/0x2f
[  221.629066]  [<c013f1f6>] ? __lock_acquire+0x68a/0x6e0
[  221.629066]  [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
[  221.629066]  [<c013bca3>] ? trace_hardirqs_off_caller+0x14/0x9b
[  221.629066]  [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
[  221.629066]  [<c0107aa3>] ? native_sched_clock+0x82/0x96
[  221.629066]  [<c013da5d>] ? mark_held_locks+0x43/0x5a
[  221.629066]  [<c013dc3a>] ? trace_hardirqs_on+0xb/0xd
[  221.629066]  [<c013dbf4>] ? trace_hardirqs_on_caller+0xf4/0x12f
[  221.629066]  [<c06abec8>] ? _spin_unlock_irqrestore+0x42/0x58
[  221.629066]  [<c013555c>] ? down+0x2b/0x2f
[  221.629066]  [<c022aa68>] ? hfsplus_iget+0xa0/0x154
[  221.629066]  [<c022b0b9>] ? hfsplus_fill_super+0x280/0x447
[  221.629066]  [<c0107aa3>] ? native_sched_clock+0x82/0x96
[  221.629066]  [<c013bca3>] ? trace_hardirqs_off_caller+0x14/0x9b
[  221.629066]  [<c013bca3>] ? trace_hardirqs_off_caller+0x14/0x9b
[  221.629066]  [<c013f1f6>] ? __lock_acquire+0x68a/0x6e0
[  221.629066]  [<c041c9e4>] ? string+0x2b/0x74
[  221.629066]  [<c041cd16>] ? vsnprintf+0x2e9/0x512
[  221.629066]  [<c010487a>] ? dump_trace+0xca/0xd6
[  221.629066]  [<c0109eaf>] ? save_stack_trace+0x1c/0x3a
[  221.629066]  [<c0109eaf>] ? save_stack_trace+0x1c/0x3a
[  221.629066]  [<c013b571>] ? save_trace+0x37/0x8d
[  221.629066]  [<c013b62e>] ? add_lock_to_list+0x67/0x8d
[  221.629066]  [<c013ea1c>] ? validate_chain+0x8a4/0x9f4
[  221.629066]  [<c01354d3>] ? up+0xc/0x2f
[  221.629066]  [<c013f1f6>] ? __lock_acquire+0x68a/0x6e0
[  221.629066]  [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
[  221.629066]  [<c013bca3>] ? trace_hardirqs_off_caller+0x14/0x9b
[  221.629066]  [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
[  221.629066]  [<c0107aa3>] ? native_sched_clock+0x82/0x96
[  221.629066]  [<c041cfb7>] ? snprintf+0x1b/0x1d
[  221.629066]  [<c01ba466>] ? disk_name+0x25/0x67
[  221.629066]  [<c0183960>] ? get_sb_bdev+0xcd/0x10b
[  221.629066]  [<c016ad92>] ? kstrdup+0x2a/0x4c
[  221.629066]  [<c022a7b3>] ? hfsplus_get_sb+0x13/0x15
[  221.629066]  [<c022ae39>] ? hfsplus_fill_super+0x0/0x447
[  221.629066]  [<c0183583>] ? vfs_kern_mount+0x3b/0x76
[  221.629066]  [<c0183602>] ? do_kern_mount+0x32/0xba
[  221.629066]  [<c01960d4>] ? do_new_mount+0x46/0x74
[  221.629066]  [<c0196277>] ? do_mount+0x175/0x193
[  221.629066]  [<c013dbf4>] ? trace_hardirqs_on_caller+0xf4/0x12f
[  221.629066]  [<c01663b2>] ? __get_free_pages+0x1e/0x24
[  221.629066]  [<c06ac07b>] ? lock_kernel+0x19/0x8c
[  221.629066]  [<c01962e6>] ? sys_mount+0x51/0x9b
[  221.629066]  [<c01962f9>] ? sys_mount+0x64/0x9b
[  221.629066]  [<c01038bd>] ? sysenter_do_call+0x12/0x31
[  221.629066]  =======================
[  221.629066] Code: 89 c2 c1 e2 08 c1 e8 08 09 c2 8b 85 e8 fd ff ff 66 89 50 06 89 c7 53 83 c7 08 56 57 68 c4 b3 80 c0 e8 8c 5c ef ff 89 d9 c1 e9 02 <f3> a5 89 d9 83 e1 03 74 02 f3 a4 83 c3 06 8b 95 e8 fd ff ff 0f
[  221.629066] EIP: [<c022d4b1>] hfsplus_find_cat+0x10d/0x151 SS:ESP 0068:c82d199c
[  221.629066] ---[ end trace e417a1d67f0d0066 ]---

Since hfsplus_cat_build_key_uni() returns void and only has one callsite,
the check is performed at the callsite.

Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de>
Reviewed-by: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>






commit efc7ffcb4237f8cb9938909041c4ed38f6e1bf40 upstream

When an hfsplus image gets corrupted it might happen that the catalog
namelength field gets b0rked.  If we mount such an image the memcpy() in
hfsplus_cat_build_key_uni() writes more than the 255 that fit in the name
field.  Depending on the size of the overwritten data, we either only get
memory corruption or also trigger an oops like this:

[  221.628020] BUG: unable to handle kernel paging request at c82b0000
[  221.629066] IP: [<c022d4b1>] hfsplus_find_cat+0x10d/0x151
[  221.629066] *pde = 0ea29163 *pte = 082b0160
[  221.629066] Oops: 0002 [#1] PREEMPT DEBUG_PAGEALLOC
[  221.629066] Modules linked in:
[  221.629066]
[  221.629066] Pid: 4845, comm: mount Not tainted (2.6.27-rc4-00123-gd3ee1b4-dirty #28)
[  221.629066] EIP: 0060:[<c022d4b1>] EFLAGS: 00010206 CPU: 0
[  221.629066] EIP is at hfsplus_find_cat+0x10d/0x151
[  221.629066] EAX: 00000029 EBX: 00016210 ECX: 000042c2 EDX: 00000002
[  221.629066] ESI: c82d70ca EDI: c82b0000 EBP: c82d1bcc ESP: c82d199c
[  221.629066]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
[  221.629066] Process mount (pid: 4845, ti=c82d1000 task=c8224060 task.ti=c82d1000)
[  221.629066] Stack: c080b3c4 c82aa8f8 c82d19c2 00016210 c080b3be c82d1bd4 c82aa8f0 00000300
[  221.629066]        01000000 750008b1 74006e00 74006900 65006c00 c82d6400 c013bd35 c8224060
[  221.629066]        00000036 00000046 c82d19f0 00000082 c8224548 c8224060 00000036 c0d653cc
[  221.629066] Call Trace:
[  221.629066]  [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
[  221.629066]  [<c013bca3>] ? trace_hardirqs_off_caller+0x14/0x9b
[  221.629066]  [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
[  221.629066]  [<c013bca3>] ? trace_hardirqs_off_caller+0x14/0x9b
[  221.629066]  [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
[  221.629066]  [<c0107aa3>] ? native_sched_clock+0x82/0x96
[  221.629066]  [<c01302d2>] ? __kernel_text_address+0x1b/0x27
[  221.629066]  [<c010487a>] ? dump_trace+0xca/0xd6
[  221.629066]  [<c0109e32>] ? save_stack_address+0x0/0x2c
[  221.629066]  [<c0109eaf>] ? save_stack_trace+0x1c/0x3a
[  221.629066]  [<c013b571>] ? save_trace+0x37/0x8d
[  221.629066]  [<c013b62e>] ? add_lock_to_list+0x67/0x8d
[  221.629066]  [<c013ea1c>] ? validate_chain+0x8a4/0x9f4
[  221.629066]  [<c013553d>] ? down+0xc/0x2f
[  221.629066]  [<c013f1f6>] ? __lock_acquire+0x68a/0x6e0
[  221.629066]  [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
[  221.629066]  [<c013bca3>] ? trace_hardirqs_off_caller+0x14/0x9b
[  221.629066]  [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
[  221.629066]  [<c0107aa3>] ? native_sched_clock+0x82/0x96
[  221.629066]  [<c013da5d>] ? mark_held_locks+0x43/0x5a
[  221.629066]  [<c013dc3a>] ? trace_hardirqs_on+0xb/0xd
[  221.629066]  [<c013dbf4>] ? trace_hardirqs_on_caller+0xf4/0x12f
[  221.629066]  [<c06abec8>] ? _spin_unlock_irqrestore+0x42/0x58
[  221.629066]  [<c013555c>] ? down+0x2b/0x2f
[  221.629066]  [<c022aa68>] ? hfsplus_iget+0xa0/0x154
[  221.629066]  [<c022b0b9>] ? hfsplus_fill_super+0x280/0x447
[  221.629066]  [<c0107aa3>] ? native_sched_clock+0x82/0x96
[  221.629066]  [<c013bca3>] ? trace_hardirqs_off_caller+0x14/0x9b
[  221.629066]  [<c013bca3>] ? trace_hardirqs_off_caller+0x14/0x9b
[  221.629066]  [<c013f1f6>] ? __lock_acquire+0x68a/0x6e0
[  221.629066]  [<c041c9e4>] ? string+0x2b/0x74
[  221.629066]  [<c041cd16>] ? vsnprintf+0x2e9/0x512
[  221.629066]  [<c010487a>] ? dump_trace+0xca/0xd6
[  221.629066]  [<c0109eaf>] ? save_stack_trace+0x1c/0x3a
[  221.629066]  [<c0109eaf>] ? save_stack_trace+0x1c/0x3a
[  221.629066]  [<c013b571>] ? save_trace+0x37/0x8d
[  221.629066]  [<c013b62e>] ? add_lock_to_list+0x67/0x8d
[  221.629066]  [<c013ea1c>] ? validate_chain+0x8a4/0x9f4
[  221.629066]  [<c01354d3>] ? up+0xc/0x2f
[  221.629066]  [<c013f1f6>] ? __lock_acquire+0x68a/0x6e0
[  221.629066]  [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
[  221.629066]  [<c013bca3>] ? trace_hardirqs_off_caller+0x14/0x9b
[  221.629066]  [<c013bd35>] ? trace_hardirqs_off+0xb/0xd
[  221.629066]  [<c0107aa3>] ? native_sched_clock+0x82/0x96
[  221.629066]  [<c041cfb7>] ? snprintf+0x1b/0x1d
[  221.629066]  [<c01ba466>] ? disk_name+0x25/0x67
[  221.629066]  [<c0183960>] ? get_sb_bdev+0xcd/0x10b
[  221.629066]  [<c016ad92>] ? kstrdup+0x2a/0x4c
[  221.629066]  [<c022a7b3>] ? hfsplus_get_sb+0x13/0x15
[  221.629066]  [<c022ae39>] ? hfsplus_fill_super+0x0/0x447
[  221.629066]  [<c0183583>] ? vfs_kern_mount+0x3b/0x76
[  221.629066]  [<c0183602>] ? do_kern_mount+0x32/0xba
[  221.629066]  [<c01960d4>] ? do_new_mount+0x46/0x74
[  221.629066]  [<c0196277>] ? do_mount+0x175/0x193
[  221.629066]  [<c013dbf4>] ? trace_hardirqs_on_caller+0xf4/0x12f
[  221.629066]  [<c01663b2>] ? __get_free_pages+0x1e/0x24
[  221.629066]  [<c06ac07b>] ? lock_kernel+0x19/0x8c
[  221.629066]  [<c01962e6>] ? sys_mount+0x51/0x9b
[  221.629066]  [<c01962f9>] ? sys_mount+0x64/0x9b
[  221.629066]  [<c01038bd>] ? sysenter_do_call+0x12/0x31
[  221.629066]  =======================
[  221.629066] Code: 89 c2 c1 e2 08 c1 e8 08 09 c2 8b 85 e8 fd ff ff 66 89 50 06 89 c7 53 83 c7 08 56 57 68 c4 b3 80 c0 e8 8c 5c ef ff 89 d9 c1 e9 02 <f3> a5 89 d9 83 e1 03 74 02 f3 a4 83 c3 06 8b 95 e8 fd ff ff 0f
[  221.629066] EIP: [<c022d4b1>] hfsplus_find_cat+0x10d/0x151 SS:ESP 0068:c82d199c
[  221.629066] ---[ end trace e417a1d67f0d0066 ]---

Since hfsplus_cat_build_key_uni() returns void and only has one callsite,
the check is performed at the callsite.

Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de>
Reviewed-by: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>








Input: atkbd - expand Latitude's force release quirk to other Dells
2008-11-07T03:05:54+00:00

Matthew Garrett
mjg59@srcf.ucam.org

2008-10-31T21:29:07+00:00

f969963e64dae0d3eb774fe3a1abc15439b34a54

commit 61579ba83934d397a4fa2bb7372de9ae112587d5 upstream.

Input: atkbd - expand Latitude's force release quirk to other Dells

Dell laptops fail to send key up events for several of their special
keys. There's an existing quirk in the kernel to handle this, but it's
limited to the Latitude range. This patch extends it to cover all
portable Dells.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>






commit 61579ba83934d397a4fa2bb7372de9ae112587d5 upstream.

Input: atkbd - expand Latitude's force release quirk to other Dells

Dell laptops fail to send key up events for several of their special
keys. There's an existing quirk in the kernel to handle this, but it's
limited to the Latitude range. This patch extends it to cover all
portable Dells.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>








ACPI: Clear WAK_STS on resume
2008-11-07T03:05:54+00:00

Matthew Garrett
mjg59@srcf.ucam.org

2008-10-31T21:27:16+00:00

2880654941dee9ffdd06abef2dfecef7f0a066ed

commit a68823ee5285e65b51ceb96f8b13a5b4f99a6888 upstream.

ACPI: Clear WAK_STS on resume

The leading other brand OS appears to clear the WAK_STS flag on resume.
When rebooted, certain BIOSes assume that the system is actually
resuming if it's still set and so fail to reboot correctly. Make sure
that it's cleared at resume time.

Comment clarified as suggested by Bob Moore

http://bugzilla.kernel.org/show_bug.cgi?id=11634

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
Tested-by: Romano Giannetti <romano.giannetti@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>






commit a68823ee5285e65b51ceb96f8b13a5b4f99a6888 upstream.

ACPI: Clear WAK_STS on resume

The leading other brand OS appears to clear the WAK_STS flag on resume.
When rebooted, certain BIOSes assume that the system is actually
resuming if it's still set and so fail to reboot correctly. Make sure
that it's cleared at resume time.

Comment clarified as suggested by Bob Moore

http://bugzilla.kernel.org/show_bug.cgi?id=11634

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
Tested-by: Romano Giannetti <romano.giannetti@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>








ACPI: Ingore the RESET_REG_SUP bit when using ACPI reset mechanism
2008-11-07T03:05:54+00:00

Zhao Yakui
yakui.zhao@intel.com

2008-10-31T21:25:45+00:00

1eac89c9bd3a640fb8ddc1d555f25435622f8275

commit 8fd145917fb62368a9b80db59562c20576238f5a upstream

ACPI: Ingore the RESET_REG_SUP bit when using ACPI reset mechanism

According to ACPI 3.0, FADT.flags.RESET_REG_SUP indicates
whether the ACPI reboot mechanism is supported.

However, some boxes have this bit clear, have a valid
ACPI_RESET_REG & RESET_VALUE, and ACPI reboot is the only
mechanism that works for them after S3.

This suggests that other operating systems may not be checking
the RESET_REG_SUP bit, and are using other means to decide
whether to use the ACPI reboot mechanism or not.

Here we stop checking RESET_REG_SUP.
Instead, When acpi reboot is requested,
only the reset_register is checked. If the following
conditions are met, it indicates that the reset register is supported.
	a. reset_register is not zero
	b. the access width is eight
	c. the bit_offset is zero

http://bugzilla.kernel.org/show_bug.cgi?id=7299
http://bugzilla.kernel.org/show_bug.cgi?id=1148

Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>






commit 8fd145917fb62368a9b80db59562c20576238f5a upstream

ACPI: Ingore the RESET_REG_SUP bit when using ACPI reset mechanism

According to ACPI 3.0, FADT.flags.RESET_REG_SUP indicates
whether the ACPI reboot mechanism is supported.

However, some boxes have this bit clear, have a valid
ACPI_RESET_REG & RESET_VALUE, and ACPI reboot is the only
mechanism that works for them after S3.

This suggests that other operating systems may not be checking
the RESET_REG_SUP bit, and are using other means to decide
whether to use the ACPI reboot mechanism or not.

Here we stop checking RESET_REG_SUP.
Instead, When acpi reboot is requested,
only the reset_register is checked. If the following
conditions are met, it indicates that the reset register is supported.
	a. reset_register is not zero
	b. the access width is eight
	c. the bit_offset is zero

http://bugzilla.kernel.org/show_bug.cgi?id=7299
http://bugzilla.kernel.org/show_bug.cgi?id=1148

Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>








libata: Fix LBA48 on pata_it821x RAID volumes.
2008-11-07T03:05:54+00:00

Ondrej Zary
linux@rainbow-software.org

2008-10-31T21:16:43+00:00

2992d0091900fc5d03e23f564f1ccf2edf12e8ba

commit 054e5f616b5becdc096b793407dc33fe379749ac upstream

libata: Fix LBA48 on pata_it821x RAID volumes.

[http://lkml.org/lkml/2008/10/18/82]

Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Acked-by: Alan Cox <alan@redhat.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>






commit 054e5f616b5becdc096b793407dc33fe379749ac upstream

libata: Fix LBA48 on pata_it821x RAID volumes.

[http://lkml.org/lkml/2008/10/18/82]

Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Acked-by: Alan Cox <alan@redhat.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>