Bug 488188 - kernel: hfs: try_to_release_page() null pointer deref
kernel: hfs: try_to_release_page() null pointer deref
Status: NEW
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
medium Severity low
: ---
: ---
Assigned To: Red Hat Product Security
Depends On: 479607 488048 488189 488190
  Show dependency treegraph
Reported: 2009-03-02 22:46 EST by Eugene Teo (Security Response)
Modified: 2015-05-04 21:26 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Eugene Teo (Security Response) 2009-03-02 22:46:26 EST
Description of problem:
When mounting a corrupted HFS image, the panic has been seen,

hfs: bad catalog namelength
hfs_fs: get root inode failed.
Unable to handle kernel NULL pointer dereference at 0000000000000038 RIP: 
PML4 0 
Oops: 0000 [1] SMP 
CPU 0 
Modules linked in: hfs parport_pc lp parport md5 ipv6 autofs4 sunrpc ds
yenta_socket pcmcia_core cpufreq_powersave loop button battery ac uhci_hcd
ehci_hcd snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm
snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd
soundcore tg3 floppy dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod ata_piix
libata sd_mod scsi_mod
Pid: 59, comm: kswapd0 Not tainted 2.6.9-78.0.13.ELlargesmp
RIP: 0010:[<ffffffffa02a1df3>] <ffffffffa02a1df3>{:hfs:hfs_releasepage+91}
RSP: 0018:000001001f635ae8  EFLAGS: 00010246
RAX: 000001001bb96b80 RBX: 0000000000000001 RCX: 0000010000b32a78
RDX: 000001001c423c00 RSI: 00000000000000d0 RDI: 0000010000b32a50
RBP: 0000010000b32a50 R08: 0000000000000002 R09: 000001001f365360
R10: 000001001f365360 R11: ffffffffa02a1d98 R12: 0000000000000000
R13: 000001000000d380 R14: 0000000000000001 R15: 000001001f635e48
FS:  0000000000000000(0000) GS:ffffffff8051ff00(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000038 CR3: 0000000000101000 CR4: 00000000000006e0
Process kswapd0 (pid: 59, threadinfo 000001001f634000, task 000001001f5ef7f0)
Stack: 0000000000000001 0000010000b32a50 0000010014dd6540 000001000000d380 
       0000010014dd6540 ffffffff80166f75 000001001f635c44 0000000300000001 
       ffffffff00000013 0000000000000202 
Call Trace:<ffffffff80166f75>{shrink_cache+1741}
       <ffffffff8015b78e>{wake_up_page+9} <ffffffff80167a5c>{shrink_zone+1887} 
       <ffffffff80167f87>{balance_pgdat+547} <ffffffff801681d8>{kswapd+252} 
       <ffffffff80110fd3>{child_rip+8} <ffffffff801680dc>{kswapd+0} 

Code: 41 81 7c 24 38 ff 0f 00 00 48 8b 57 20 49 8d 7c 24 6c 41 8b 
RIP <ffffffffa02a1df3>{:hfs:hfs_releasepage+91} RSP <000001001f635ae8>
CR2: 0000000000000038
 <0>Kernel panic - not syncing: Oops

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. while :; do mount hfs.59.img /mnt/tmp/ -t hfs -o loop; done &
2. x.y.z.redhat.com will panic by running for around a hour.
   s390 and s390x will panic by running for around half a hour.

Additional information:
Comment #11 From  Vitaly Mayatskikh (vmayatsk@redhat.com)  2009-01-09 16:08:28
EDT   (-) [reply] -------      Private

I got memory dump with similar crash:

Unable to handle kernel pointer dereference at virtual kernel address
Oops: 0004 [#1]
CPU:    0    Not tainted
Process kswapd0 (pid: 87, task: 000000001ffe4cb0, ksp: 000000001ffe3d10)
Krnl PSW : 0700200180000000 00000000002018ba (__lock_text_start+0xa/0x14)
Krnl GPRS: 0000000000000000 00000000002018b4 000000000000006c 0000000000000000
           0000000000000000 0000000000000000 0000000000000002 0000000000000001
           0000000000000000 0000000000001000 0000000000000000 0000000017164bb8
           0000000000d74948 0000000020d6e198 0000000020d6b54e 000000001ffe39b8
Krnl Code: ba 31 20 00 a7 44 ff fb 07 fe 58 10 20 00 a7 38 00 00 ba 13 
Call Trace:
([<0000000000faf110>] 0xfaf110)
 [<0000000000096b24>] try_to_release_page+0x80/0x98
 [<000000000007a8d0>] shrink_cache+0x94c/0xe24
 [<000000000007b6be>] shrink_zone+0x916/0x9ac
 [<000000000007be00>] kswapd+0x2f8/0x438
 [<0000000000019ab6>] kernel_thread_starter+0x6/0xc
 [<0000000000019ab0>] kernel_thread_starter+0x0/0xc

The problem was triggered from fs/buffer.c try_to_release_page() function:

int try_to_release_page(struct page *page, int gfp_mask)
 struct address_space * const mapping = page->mapping;

 if (PageWriteback(page))
  return 0;

 if (mapping && mapping->a_ops->releasepage)
  return mapping->a_ops->releasepage(page, gfp_mask);
page->a_ops->releasepage contain garbage data which cause kernel to execute
random code. The bug is somewhere in hfs code (perhaps, mm data corruption),
but this is definitely another issue.

Note that this is not CVE-2008-5025, even though it uses the same reproducer.
Comment 3 Eugene Teo (Security Response) 2009-03-02 23:10:27 EST
Note to self: /etc/fstab; ''user''  (allow  a  user to mount).
Comment 29 Eugene Teo (Security Response) 2009-03-26 19:23:45 EDT

Note You need to log in before you can comment on or make changes to this bug.