linux-toradex.git/fs, branch v2.6.27.5

hfsplus: check read_mapping_page() return value

2008-11-07T03:05:55+00:00

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: [] 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:[] 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]  [] ? hfsplus_block_allocate+0x6f/0x2d3
[15840.675016]  [] ? hfsplus_file_extend+0xc4/0x1db
[15840.675016]  [] ? hfsplus_get_block+0x8c/0x19d
[15840.675016]  [] ? sub_preempt_count+0x9d/0xab
[15840.675016]  [] ? __block_prepare_write+0x147/0x311
[15840.675016]  [] ? __grab_cache_page+0x52/0x73
[15840.675016]  [] ? block_write_begin+0x79/0xd5
[15840.675016]  [] ? hfsplus_get_block+0x0/0x19d
[15840.675016]  [] ? cont_write_begin+0x27f/0x2af
[15840.675016]  [] ? hfsplus_get_block+0x0/0x19d
[15840.675016]  [] ? tick_program_event+0x28/0x4c
[15840.675016]  [] ? trace_hardirqs_off+0xb/0xd
[15840.675016]  [] ? hfsplus_write_begin+0x2d/0x32
[15840.675016]  [] ? hfsplus_get_block+0x0/0x19d
[15840.675016]  [] ? pagecache_write_begin+0x33/0x107
[15840.675016]  [] ? __page_symlink+0x3c/0xae
[15840.675016]  [] ? __mark_inode_dirty+0x12f/0x137
[15840.675016]  [] ? page_symlink+0x19/0x1e
[15840.675016]  [] ? hfsplus_symlink+0x41/0xa6
[15840.675016]  [] ? vfs_symlink+0x99/0x101
[15840.675016]  [] ? sys_symlinkat+0x6b/0xad
[15840.675016]  [] ? sys_symlink+0x10/0x12
[15840.675016]  [] ? 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: [] 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 
Cc: Roman Zippel 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

hfsplus: fix Buffer overflow with a corrupted image

2008-11-07T03:05:55+00:00

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: [] 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:[] 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]  [] ? trace_hardirqs_off+0xb/0xd
[  221.629066]  [] ? trace_hardirqs_off_caller+0x14/0x9b
[  221.629066]  [] ? trace_hardirqs_off+0xb/0xd
[  221.629066]  [] ? trace_hardirqs_off_caller+0x14/0x9b
[  221.629066]  [] ? trace_hardirqs_off+0xb/0xd
[  221.629066]  [] ? native_sched_clock+0x82/0x96
[  221.629066]  [] ? __kernel_text_address+0x1b/0x27
[  221.629066]  [] ? dump_trace+0xca/0xd6
[  221.629066]  [] ? save_stack_address+0x0/0x2c
[  221.629066]  [] ? save_stack_trace+0x1c/0x3a
[  221.629066]  [] ? save_trace+0x37/0x8d
[  221.629066]  [] ? add_lock_to_list+0x67/0x8d
[  221.629066]  [] ? validate_chain+0x8a4/0x9f4
[  221.629066]  [] ? down+0xc/0x2f
[  221.629066]  [] ? __lock_acquire+0x68a/0x6e0
[  221.629066]  [] ? trace_hardirqs_off+0xb/0xd
[  221.629066]  [] ? trace_hardirqs_off_caller+0x14/0x9b
[  221.629066]  [] ? trace_hardirqs_off+0xb/0xd
[  221.629066]  [] ? native_sched_clock+0x82/0x96
[  221.629066]  [] ? mark_held_locks+0x43/0x5a
[  221.629066]  [] ? trace_hardirqs_on+0xb/0xd
[  221.629066]  [] ? trace_hardirqs_on_caller+0xf4/0x12f
[  221.629066]  [] ? _spin_unlock_irqrestore+0x42/0x58
[  221.629066]  [] ? down+0x2b/0x2f
[  221.629066]  [] ? hfsplus_iget+0xa0/0x154
[  221.629066]  [] ? hfsplus_fill_super+0x280/0x447
[  221.629066]  [] ? native_sched_clock+0x82/0x96
[  221.629066]  [] ? trace_hardirqs_off_caller+0x14/0x9b
[  221.629066]  [] ? trace_hardirqs_off_caller+0x14/0x9b
[  221.629066]  [] ? __lock_acquire+0x68a/0x6e0
[  221.629066]  [] ? string+0x2b/0x74
[  221.629066]  [] ? vsnprintf+0x2e9/0x512
[  221.629066]  [] ? dump_trace+0xca/0xd6
[  221.629066]  [] ? save_stack_trace+0x1c/0x3a
[  221.629066]  [] ? save_stack_trace+0x1c/0x3a
[  221.629066]  [] ? save_trace+0x37/0x8d
[  221.629066]  [] ? add_lock_to_list+0x67/0x8d
[  221.629066]  [] ? validate_chain+0x8a4/0x9f4
[  221.629066]  [] ? up+0xc/0x2f
[  221.629066]  [] ? __lock_acquire+0x68a/0x6e0
[  221.629066]  [] ? trace_hardirqs_off+0xb/0xd
[  221.629066]  [] ? trace_hardirqs_off_caller+0x14/0x9b
[  221.629066]  [] ? trace_hardirqs_off+0xb/0xd
[  221.629066]  [] ? native_sched_clock+0x82/0x96
[  221.629066]  [] ? snprintf+0x1b/0x1d
[  221.629066]  [] ? disk_name+0x25/0x67
[  221.629066]  [] ? get_sb_bdev+0xcd/0x10b
[  221.629066]  [] ? kstrdup+0x2a/0x4c
[  221.629066]  [] ? hfsplus_get_sb+0x13/0x15
[  221.629066]  [] ? hfsplus_fill_super+0x0/0x447
[  221.629066]  [] ? vfs_kern_mount+0x3b/0x76
[  221.629066]  [] ? do_kern_mount+0x32/0xba
[  221.629066]  [] ? do_new_mount+0x46/0x74
[  221.629066]  [] ? do_mount+0x175/0x193
[  221.629066]  [] ? trace_hardirqs_on_caller+0xf4/0x12f
[  221.629066]  [] ? __get_free_pages+0x1e/0x24
[  221.629066]  [] ? lock_kernel+0x19/0x8c
[  221.629066]  [] ? sys_mount+0x51/0x9b
[  221.629066]  [] ? sys_mount+0x64/0x9b
[  221.629066]  [] ? 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  a5 89 d9 83 e1 03 74 02 f3 a4 83 c3 06 8b 95 e8 fd ff ff 0f
[  221.629066] EIP: [] 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 
Reviewed-by: Pekka Enberg 
Cc: Roman Zippel 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

proc: fix vma display mismatch between /proc/pid/{maps,smaps}

2008-10-25T21:32:42+00:00

[ backport of 7c88db0cb589df980acfb2f73c3595a0653004ec to 2.7.27.3 by Joe
Korty /tmp/smaps; diff /proc/1/maps /tmp/smaps

    1  25d24
    2  < 7fd7e23aa000-7fd7e23ac000 rw-p 7fd7e23aa000 00:00 0
    3  28a28
    4  > ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0  [vsyscall]

The bug has something to do with setting m->version before all the
seq_printf's have been performed.  show_map was doing this correctly,
but show_smap was doing this in the middle of its seq_printf sequence.
This patch arranges things so that the setting of m->version in show_smap
is also done at the end of its seq_printf sequence.

Testing: in addition to the above grep test, for each process I summed
up the 'Rss' fields of /proc/pid/smaps and compared that to the 'VmRSS'
field of /proc/pid/status.  All matched except for Xorg (which has a
/dev/mem mapping which Rss accounts for but VmRSS does not).  This result
gives us some confidence that neither /proc/pid/maps nor /proc/pid/smaps
are any longer skipping or double-counting vmas.

Signed-off-by: Joe Korty 
Cc: Matt Mackall 
Signed-off-by: Andrew Morton 
Signed-off-by: Alexey Dobriyan

ext[234]: Avoid printk floods in the face of directory corruption (CVE-2008-3528)

2008-10-25T21:32:40+00:00

This is a trivial backport of the following upstream commits:

- bd39597cbd42a784105a04010100e27267481c67 (ext2)
- cdbf6dba28e8e6268c8420857696309470009fd9 (ext3)
- 9d9f177572d9e4eba0f2e18523b44f90dd51fe74 (ext4)

This addresses CVE-2008-3528

ext[234]: Avoid printk floods in the face of directory corruption

Note: some people thinks this represents a security bug, since it
might make the system go away while it is printing a large number of
console messages, especially if a serial console is involved.  Hence,
it has been assigned CVE-2008-3528, but it requires that the attacker
either has physical access to your machine to insert a USB disk with a
corrupted filesystem image (at which point why not just hit the power
button), or is otherwise able to convince the system administrator to
mount an arbitrary filesystem image (at which point why not just
include a setuid shell or world-writable hard disk device file or some
such).  Me, I think they're just being silly. --tytso

Signed-off-by: Eric Sandeen 
Signed-off-by: "Theodore Ts'o" 
Cc: linux-ext4@vger.kernel.org
Cc: Eugene Teo 
Signed-off-by: Greg Kroah-Hartman

CIFS: fix saving of resume key before CIFSFindNext

2008-10-25T21:32:40+00:00

commit a364bc0b37f14ffd66c1f982af42990a9d77fa43 upstream

We recently fixed the cifs readdir code so that it saves the resume key
before calling CIFSFindNext. Unfortunately, this assumes that we have
just done a CIFSFindFirst (or FindNext) and have resume info to save.
This isn't necessarily the case. Fix the code to save resume info if we
had to reinitiate the search, and after a FindNext.

This fixes connectathon basic test6 against NetApp filers.

Signed-off-by: Jeff Layton 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

xfs: fix remount rw with unrecognized options

2008-10-22T21:21:10+00:00

commit 6c5e51dae2c37127e00be392f40842e08077e96a upstream

When we skip unrecognized options in xfs_fs_remount we should just break
out of the switch and not return because otherwise we may skip clearing
the xfs-internal read-only flag.  This will only show up on some
operations like touch because most read-only checks are done by the VFS
which thinks this filesystem is r/w.  Eventually we should replace the
XFS read-only flag with a helper that always checks the VFS flag to make
sure they can never get out of sync.

Bug reported and fix verified by Marcel Beister on #xfs.
Bug fix verified by updated xfstests/189.

Signed-off-by: Christoph Hellwig 
Acked-by: Eric Sandeen 
Signed-off-by: Timothy Shimmin 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

CIFS: make sure we have the right resume info before calling CIFSFindNext

2008-10-18T17:49:11+00:00

commit 0752f1522a9120f731232919f7ad904e9e22b8ce upstream

When we do a seekdir() or equivalent, we usually end up doing a
FindFirst call and then call FindNext until we get to the offset that we
want. The problem is that when we call FindNext, the code usually
doesn't have the proper info (mostly, the filename of the entry from the
last search) to resume the search.

Add a "last_entry" field to the cifs_search_info that points to the last
entry in the search. We calculate this pointer by using the
LastNameOffset field from the search parms that are returned. We then
use that info to do a cifs_save_resume_key before we call CIFSFindNext.

This patch allows CIFS to reliably pass the "telldir" connectathon test.

Signed-off-by: Jeff Layton 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

Fix barrier fail detection in XFS

2008-10-18T17:49:11+00:00

commit 73f6aa4d44ab6157badc456ddfa05b31e58de5f0 upstream.

Currently we disable barriers as soon as we get a buffer in xlog_iodone
that has the XBF_ORDERED flag cleared.  But this can be the case not only
for buffers where the barrier failed, but also the first buffer of a
split log write in case of a log wraparound.  Due to the disabled
barriers we can easily get directory corruption on unclean shutdowns.
So instead of using this check add a new buffer flag for failed barrier
writes.

This is a regression vs 2.6.26 caused by patch to use the right macro
to check for the ORDERED flag, as we previously got true returned for
every buffer.

Thanks to Toei Rei for reporting the bug.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Eric Sandeen 
Reviewed-by: David Chinner 
Signed-off-by: Tim Shimmin 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Don't allow splice() to files opened with O_APPEND

2008-10-09T21:26:38+00:00

This is debatable, but while we're debating it, let's disallow the
combination of splice and an O_APPEND destination.

It's not entirely clear what the semantics of O_APPEND should be, and
POSIX apparently expects pwrite() to ignore O_APPEND, for example.  So
we could make up any semantics we want, including the old ones.

But Miklos convinced me that we should at least give it some thought,
and that accepting writes at arbitrary offsets is wrong at least for
IS_APPEND() files (which always have O_APPEND set, even if the reverse
isn't true: you can obviously have O_APPEND set on a regular file).

So disallow O_APPEND entirely for now.  I doubt anybody cares, and this
way we have one less gray area to worry about.

Reported-and-argued-for-by: Miklos Szeredi 
Acked-by: Jens Axboe 
Signed-off-by: Linus Torvalds

mm: tiny-shmem nommu fix

2008-10-02T22:53:13+00:00

The previous patch db203d53d474aa068984e409d807628f5841da1b ("mm:
tiny-shmem fix lock ordering: mmap_sem vs i_mutex") to fix the lock
ordering in tiny-shmem breaks shared anonymous and IPC memory on NOMMU
architectures because it was using the expanding truncate to signal ramfs
to allocate a physically contiguous RAM backing the inode (otherwise it is
unusable for "memory mapping" it to userspace).

However do_truncate is what caused the lock ordering error, due to it
taking i_mutex.  In this case, we can actually just call ramfs directly to
allocate memory for the mapping, rather than go via truncate.

Acked-by: David Howells 
Acked-by: Hugh Dickins 
Signed-off-by: Nick Piggin 
Cc: Matt Mackall 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds