linux-kernel - Bad Page State In File System Related Opeartions (3.10.35)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:	Sun, 15 Feb 2015 22:20:56 +0800
From:	Kai <mh2494@....hinet.net>
To:	linux-kernel@...r.kernel.org
Subject: Bad Page State In File System Related Opeartions (3.10.35)

While doing data transfer between several hosts with different file 
systems/protocols, I always get errors as below:


[ 5257.087865] BUG: Bad page state in process ftpd  pfn:2150f
[ 5257.093524] page:ffffea0000749b48 count:0 mapcount:0 
mapping:          (null) index:0x2
[ 5257.101547] page flags: 0x4000000000000004(referenced)

[ 5257.107003] Modules linked in: iscsi_tcp libiscsi_tcp libiscsi 
iscsi_target_mod(O) target_core_mod(O) iscsi_extent_pool(PO) 
iscsi_rodsp(PO) configfs nfsd exportfs rpcsec_gss_krb5 cifs udf isofs 
loop hid_generic usbhid hid usblp usb_storage btrfs zlib_deflate 
libcrc32c hfsplus md4 hmac tn40xx(O) ixgbe(O) be2net igb(O) i2c_algo_bit 
e1000e(O) dca fuse vfat fat crc32c_intel cryptd ecryptfs sha512_generic 
sha256_generic sha1_generic ecb aes_x86_64 authenc des_generic 
ansi_cprng cts md5 cbc cpufreq_conservative cpufreq_powersave 
cpufreq_performance cpufreq_ondemand acpi_cpufreq mperf processor 
thermal_sys cpufreq_stats freq_table dm_snapshot crc_itu_t crc_ccitt 
quota_v2 quota_tree psnap p8022 llc tunnel4 ipv6 zram(C) sg etxhci_hcd 
xhci_hcd ehci_pci ehci_hcd uhci_hcd usbcore usb_common [last unloaded: 
configfs]

[ 5257.184511] CPU: 0 PID: 17627 Comm: ftpd Tainted: P        WC O 
3.10.35 #1
[ 5257.191668] Hardware name: To be filled by O.E.M. To be filled by 
O.E.M./To be filled by O.E.M., BIOS 4.6.4 09/28/2012
[ 5257.202404]  ffffffff8149bbc3 0000000000000000 ffffffff8149a6d1 
0000000000000001
[ 5257.209964]  ffffffff810b2cac 000000000000001f 0000000000000246 
000213da00000000
[ 5257.217425]  0000000000000000 ffff880073171fd8 0000000000000030 
0000000000000001
[ 5257.224967] Call Trace:
[ 5257.227426]  [<ffffffff8149bbc3>] ? dump_stack+0xd/0x17
[ 5257.232701]  [<ffffffff8149a6d1>] ? bad_page+0xd4/0xeb
[ 5257.237940]  [<ffffffff810b2cac>] ? get_page_from_freelist+0x57c/0x660
[ 5257.244635]  [<ffffffff8133b315>] ? ata_qc_issue+0x195/0x3e0
[ 5257.250509]  [<ffffffff810b2ee1>] ? __alloc_pages_nodemask+0x151/0x7f0
[ 5257.257237]  [<ffffffff81000fa0>] ? __switch_to+0x3d0/0x460
[ 5257.262976]  [<ffffffff8149f67e>] ? __schedule+0x25e/0x5c0
[ 5257.268655]  [<ffffffff810b590c>] ? __do_page_cache_readahead+0xec/0x250
[ 5257.275611]  [<ffffffff813b11d3>] ? dm_any_congested+0x63/0x80
[ 5257.281676]  [<ffffffff810b5cdc>] ? ra_submit+0x1c/0x30
[ 5257.287086]  [<ffffffff810ac8c1>] ? generic_file_aio_read+0x481/0x6f0
[ 5257.293756]  [<ffffffff810e775a>] ? do_sync_read+0x6a/0xa0
[ 5257.299719]  [<ffffffff810e8940>] ? vfs_read+0xa0/0x160
[ 5257.305335]  [<ffffffff810ee921>] ? kernel_read+0x41/0x60
[ 5257.311060]  [<ffffffffa01bbca9>] ? ecryptfs_decrypt_page+0x1f9/0x390 
[ecryptfs]
[ 5257.318731]  [<ffffffff810587b5>] ? __wake_up_common+0x55/0x90
[ 5257.324998]  [<ffffffff810591c3>] ? __wake_up+0x43/0x70
[ 5257.330498]  [<ffffffffa01b9968>] ? ecryptfs_readpage+0xd8/0x120 
[ecryptfs]
[ 5257.337953]  [<ffffffff81115878>] ? 
__generic_file_splice_read+0x3c8/0x540
[ 5257.345346]  [<ffffffff81113e60>] ? page_cache_pipe_buf_release+0x20/0x20
[ 5257.352143]  [<ffffffff813c9a46>] ? kernel_sendpage+0x16/0x30
[ 5257.358282]  [<ffffffff813c9a82>] ? sock_sendpage+0x22/0x30
[ 5257.364188]  [<ffffffff81113cfd>] ? pipe_to_sendpage+0x4d/0x80
[ 5257.370355]  [<ffffffff81113e4c>] ? page_cache_pipe_buf_release+0xc/0x20
[ 5257.377369]  [<ffffffff81113de1>] ? splice_from_pipe_feed+0xb1/0x110
[ 5257.384019]  [<ffffffff81113cb0>] ? splice_from_pipe_begin+0x10/0x10
[ 5257.390536]  [<ffffffff8111400e>] ? __splice_from_pipe+0x3e/0x80
[ 5257.396793]  [<ffffffff81115ab8>] ? splice_from_pipe+0x58/0x70
[ 5257.402884]  [<ffffffff81115a24>] ? generic_file_splice_read+0x34/0x70
[ 5257.409627]  [<ffffffff811149eb>] ? splice_direct_to_actor+0x9b/0x1c0
[ 5257.416250]  [<ffffffff81114390>] ? do_splice_from+0x130/0x130
[ 5257.422227]  [<ffffffff81115b53>] ? do_splice_direct+0x53/0x70
[ 5257.428234]  [<ffffffff810e7d1f>] ? do_sendfile+0x1bf/0x560
[ 5257.433901]  [<ffffffff8102c5cf>] ? sys32_fstat64+0x1f/0x30
[ 5257.439750]  [<ffffffff810e9b45>] ? SyS_sendfile64+0x55/0xa0
[ 5257.445602]  [<ffffffff814a2391>] ? sysenter_dispatch+0x7/0x1e


The paths of the call-traces are random. However, the processes hitting 
the bad pages are usually cp, somtimes the processes accessing files 
like ftpd in this case.

When the fields count, mapcount, and map of a page are all 0 or NULL, is 
it valid that the page has the flag referenced set? I am wondering if 
this is a use-after-free case.

I also find that, after I remove the hfsplus volumes, this issue disappears.

I have traced into the kernel code for any potnetial racing with the 
finction mark_page_accessed() but find nothing.

Would any one suggest about this issue? All the suggestions and comments 
are appreciated.

Kai Gnep

---
Avast 防毒軟體已檢查此封電子郵件的病毒。
http://www.avast.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/