| 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
| ||
|
Message-ID: <20090312041352.GA6035@redhat.com> Date: Thu, 12 Mar 2009 00:13:52 -0400 From: Dave Jones <davej@...hat.com> To: netdev@...r.kernel.org Subject: VIA velocity skb leak. I think I've found a bug in the via-velocity driver, but I'm not sure how to fix it. We've been carrying some debug patches in the Fedora kernel that dwmw2 wrote, which do some sanity checks on dma allocations. Velocity triggered this trace.. [ 324.777540] ------------[ cut here ]------------ [ 324.777559] WARNING: at lib/dma-debug.c:470 check_unmap+0x196/0x3e4() (Not tainted) [ 324.777575] Hardware name: [ 324.777591] via-velocity 0000:00:0e.0: DMA-API: device driver frees DMA memory with different size [device address=0x000000001a4c8ca2] [map size=60 bytes] [unmap size=54 bytes] [ 324.777614] Modules linked in: ipt_MASQUERADE iptable_nat nf_nat ipt_LOG xt_limit sunrpc nf_conntrack_netbios_ns ip6t_REJECT ip6table_filter ip6_tables ipv6 cpufreq_ondemand serio_raw usb_storage pcspkr i2c_viapro 3c59x mii i2c_core firewire_ohci via_velocity firewire_core crc_ccitt crc_itu_t ata_generic pata_acpi pata_via ext2 [last unloaded: scsi_wait_scan] [ 324.777792] Pid: 0, comm: swapper Not tainted 2.6.29-0.179.rc6.git5.fc11.i686.PAE #1 [ 324.777807] Call Trace: [ 324.777839] [<c0437a9f>] warn_slowpath+0x7c/0xa7 [ 324.777870] [<c0701800>] ? _spin_unlock_irq+0x1c/0x34 [ 324.777899] [<c042ae55>] ? account_group_exec_runtime+0x4d/0x54 [ 324.777929] [<c045783c>] ? mark_lock+0x1e/0x30b [ 324.777952] [<c045783c>] ? mark_lock+0x1e/0x30b [ 324.777973] [<c0554765>] ? get_hash_bucket+0x26/0x2f [ 324.777995] [<c0554fc3>] check_unmap+0x196/0x3e4 [ 324.778021] [<c040de4d>] ? sched_clock+0x9/0xd [ 324.778042] [<c05553bf>] debug_dma_unmap_page+0x68/0x70 [ 324.778064] [<c05553bf>] ? debug_dma_unmap_page+0x68/0x70 [ 324.778111] [<dcfc251c>] pci_unmap_single+0x65/0x70 [via_velocity] [ 324.778148] [<dcfc25f5>] velocity_tx_srv+0xce/0x183 [via_velocity] [ 324.778188] [<dcfc39a7>] velocity_intr+0x52f/0x594 [via_velocity] [ 324.778211] [<c0457023>] ? trace_hardirqs_off+0xb/0xd [ 324.778232] [<c067d15d>] ? netif_rx+0x9d/0x11a [ 324.778277] [<dc861f8e>] ? boomerang_interrupt+0x324/0x331 [3c59x] [ 324.778300] [<c045783c>] ? mark_lock+0x1e/0x30b [ 324.778330] [<c047a6a4>] ? handle_fasteoi_irq+0x76/0xb7 [ 324.778351] [<c04566d8>] ? lock_release_holdtime+0x2b/0x123 [ 324.778374] [<c0479284>] handle_IRQ_event+0x22/0x58 [ 324.778394] [<c0479284>] ? handle_IRQ_event+0x22/0x58 [ 324.778417] [<c047a6ae>] handle_fasteoi_irq+0x80/0xb7 [ 324.778437] [<c047a62e>] ? handle_fasteoi_irq+0x0/0xb7 [ 324.778450] <IRQ> [<c0409cac>] ? common_interrupt+0x2c/0x34 [ 324.778490] [<c0457d78>] ? trace_hardirqs_on+0xb/0xd [ 324.778501] [<c059fcca>] ? acpi_idle_enter_simple+0x13a/0x179 [ 324.778501] [<c059f9b4>] ? acpi_idle_enter_bm+0xd1/0x2ad [ 324.778501] [<c0660105>] ? menu_select+0x3d/0xa4 [ 324.778501] [<c065f670>] ? cpuidle_idle_call+0x65/0x9d [ 324.778501] [<c065f670>] ? cpuidle_idle_call+0x65/0x9d [ 324.778501] [<c040871e>] ? cpu_idle+0x72/0x90 [ 324.778501] [<c06efa03>] ? rest_init+0x53/0x55 [ 324.778501] ---[ end trace 57ea7e11ea46a364 ]--- It looks like in velocity_xmit we do the skb_padto because the length is below the minimum frame size (56 bytes) and pci_map the resulting 60 byte skb. But later, when we free it, we forget that we did that size adjustment. Does skb_padto adjust the skb->len somewhere, or is this responsibility of the caller? Dave -- http://www.codemonkey.org.uk -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists