Bug 869569

Summary:	[abrt]: WARNING: at lib/list_debug.c:53 __list_del_entry+0x63/0xd0()
Product:	[Fedora] Fedora	Reporter:	Dmitri Skok <dima_skok>
Component:	kernel	Assignee:	Herbert Xu <zxu>
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	17	CC:	gansalmon, itamar, jforbes, jlayton, jonathan, kernel-maint, madhu.chinakonda, sprabhu
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Unspecified
Whiteboard:	abrt_hash:4e1122b95ae3783bed169cb5dcfae03382f7f5e8
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-02-01 15:50:00 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Dmitri Skok 2012-10-24 09:32:50 UTC

Additional info:
libreport version: 2.0.16
abrt_version:   2.0.13
cmdline:        placeholder root=UUID=e8eded05-aea6-4177-a764-9d64656a2710 ro rd.md=0 rd.lvm=0 rd.dm=0 SYSFONT=True rd.luks=0 KEYTABLE=ru LANG=en_US.UTF-8
kernel:         3.5.3-1.fc17.x86_64

backtrace:
:WARNING: at lib/list_debug.c:53 __list_del_entry+0x63/0xd0()
:Hardware name: P5KC
:list_del corruption, ffff880115ad8200->next is LIST_POISON1 (dead000000100100)
:Modules linked in: ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat xt_CHECKSUM iptable_mangle tun bridge nfs stp nls_utf8 llc cifs nfs_acl auth_rpcgss lockd sunrpc be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i cxgb4 cxgb3i bnep bluetooth rfkill cxgb3 mdio libcxgbi ib_iser rdma_cm ib_addr iw_cm ib_cm ib_sa ib_mad ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip6t_REJECT nf_conntrack_ipv6 cachefiles fscache nf_conntrack_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 ip6table_filter xt_state nf_conntrack ip6_tables fuse snd_hda_codec_hdmi snd_usb_audio snd_usbmidi_lib snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_rawmidi snd_seq snd_seq_device snd_pcm snd_page_alloc snd_timer snd soundcore coretemp lpc_ich atl1 mfd_core mii microcode i2c_i801 serio_raw asus_atk0110 xen_acpi_processor xen_netback xen_blkback xen_gntdev xen_evtchn xenfs binfmt_misc xen_privcmd uinput ata_generic pata_acpi firewire_ohci firewire_core crc_itu_t pata_jmicron usb
:_storage radeon i2c_algo_bit drm_kms_helper ttm drm i2c_core [last unloaded: scsi_wait_scan]
:Pid: 862, comm: mount.cifs Not tainted 3.5.3-1.fc17.x86_64 #1
:Call Trace:
: [<ffffffff810584bf>] warn_slowpath_common+0x7f/0xc0
: [<ffffffff810585b6>] warn_slowpath_fmt+0x46/0x50
: [<ffffffff8108d530>] ? try_to_wake_up+0x2c0/0x2c0
: [<ffffffff812e2ac3>] __list_del_entry+0x63/0xd0
: [<ffffffff812e2b41>] list_del+0x11/0x40
: [<ffffffff81295345>] crypto_larval_kill+0x25/0x60
: [<ffffffff81295beb>] crypto_alg_mod_lookup+0x6b/0x90
: [<ffffffff81295627>] crypto_alloc_tfm+0x67/0xf0
: [<ffffffff8129d299>] crypto_alloc_shash+0x19/0x20
: [<ffffffffa05ccc71>] cifs_crypto_shash_allocate+0x21/0x1a0 [cifs]
: [<ffffffffa05b4300>] cifs_get_tcp_session+0x160/0x730 [cifs]
: [<ffffffffa05b791d>] cifs_mount+0x7d/0x6b0 [cifs]
: [<ffffffffa05a5e56>] ? cifs_do_mount+0x86/0x4b0 [cifs]
: [<ffffffffa05a5e79>] cifs_do_mount+0xa9/0x4b0 [cifs]
: [<ffffffff8118b813>] mount_fs+0x43/0x1b0
: [<ffffffff811a454f>] vfs_kern_mount+0x6f/0x100
: [<ffffffff811a4f04>] do_kern_mount+0x54/0x110
: [<ffffffff811a682a>] do_mount+0x26a/0x880
: [<ffffffff811a642a>] ? copy_mount_options+0x3a/0x180
: [<ffffffff811a6f8d>] sys_mount+0x8d/0xe0
: [<ffffffff81614ae9>] system_call_fastpath+0x16/0x1b

Comment 1 Josh Boyer 2012-10-24 13:12:54 UTC

Does this happen with the 3.6.x updates in F17?

Comment 2 Jeff Layton 2012-10-24 13:26:24 UTC

Huh, cifs is a fairly naive user of the crypto APIs and I don't see where it's doing anything wrong...

It looks sort of like the kernel tried to look up a particular crypto algorithm and failed, and the list corruption was found during the error handling. Smells like some sort of generic memory corruption, really.

Yeah, is this reproducible on a 3.6-ish kernel?

Comment 3 Jeff Layton 2012-11-14 14:52:56 UTC

I took a look here but I don't know the crypto APIs well at all. It looks though like this crypto algorithm was freed while we were waiting on it to be set up or something? In any case, I'm fairly convinced that this is not related to CIFS at all...

I'm going to hand this off to Herbert in case he has seen this and is interested.

Comment 4 Justin M. Forbes 2013-02-01 15:50:00 UTC

This bug is being closed because it has been set needinfo for more than 2 weeks without a response. If this is still an issue, please reopen and reply with the requested information.