1. 12 10月, 2010 4 次提交
  2. 11 10月, 2010 1 次提交
  3. 10 10月, 2010 2 次提交
  4. 09 10月, 2010 1 次提交
    • D
      isdn: strcpy() => strlcpy() · b530fb69
      Dan Carpenter 提交于
      setup.phone and setup.eazmsn are 32 character buffers.
      rcvmsg.msg_data.byte_array is a 48 character buffer.
      sc_adapter[card]->channel[rcvmsg.phy_link_no - 1].dn is 50 chars.
      
      The rcvmsg struct comes from the memcpy_fromio() in receivemessage().
      I guess that means it's data off the wire.  I'm not very familiar with
      this code but I don't see any reason to assume these strings are NULL
      terminated.
      
      Also it's weird that "dn" in a 50 character buffer but we only seem to
      use 32 characters.  In drivers/isdn/sc/scioc.h, "dn" is only a 49
      character buffer.  So potentially there is still an issue there.
      
      The important thing for now is to prevent the memory corruption.
      Signed-off-by: NDan Carpenter <error27@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b530fb69
  5. 07 10月, 2010 1 次提交
  6. 06 10月, 2010 2 次提交
    • N
      bonding: fix WARN_ON when writing to bond_master sysfs file · 27e6f065
      Neil Horman 提交于
      Fix a WARN_ON failure in bond_masters sysfs file
      
      Got a report of this warning recently
      
      bonding: bond0 is being created...
      ------------[ cut here ]------------
      WARNING: at fs/proc/generic.c:590 proc_register+0x14d/0x185()
      Hardware name: ProLiant BL465c G1
      proc_dir_entry 'bonding/bond0' already registered
      Modules linked in: bonding ipv6 tg3 bnx2 shpchp amd64_edac_mod edac_core
      ipmi_si
      ipmi_msghandler serio_raw i2c_piix4 k8temp edac_mce_amd hpwdt microcode hpsa
      cc
      iss radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded:
      scsi_wai
      t_scan]
      Pid: 935, comm: ifup-eth Not tainted 2.6.33.5-124.fc13.x86_64 #1
      Call Trace:
      [<ffffffff8104b54c>] warn_slowpath_common+0x77/0x8f
      [<ffffffff8104b5b1>] warn_slowpath_fmt+0x3c/0x3e
      [<ffffffff8114bf0b>] proc_register+0x14d/0x185
      [<ffffffff8114c20c>] proc_create_data+0x87/0xa1
      [<ffffffffa0211e9b>] bond_create_proc_entry+0x55/0x95 [bonding]
      [<ffffffffa0215e5d>] bond_init+0x95/0xd0 [bonding]
      [<ffffffff8138cd97>] register_netdevice+0xdd/0x29e
      [<ffffffffa021240b>] bond_create+0x8e/0xb8 [bonding]
      [<ffffffffa021c4be>] bonding_store_bonds+0xb3/0x1c1 [bonding]
      [<ffffffff812aec85>] class_attr_store+0x27/0x29
      [<ffffffff8115423d>] sysfs_write_file+0x10f/0x14b
      [<ffffffff81101acf>] vfs_write+0xa9/0x106
      [<ffffffff81101be2>] sys_write+0x45/0x69
      [<ffffffff81009b02>] system_call_fastpath+0x16/0x1b
      ---[ end trace a677c3f7f8b16b1e ]---
      bonding: Bond creation failed.
      
      It happens because a user space writer to bond_master can try to
      register an already existing bond interface name.  Fix it by teaching
      bond_create to check for the existance of devices with that name first
      in cases where a non-NULL name parameter has been passed in
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      27e6f065
    • S
      skge: add quirk to limit DMA · 392bd0cb
      Stanislaw Gruszka 提交于
      Skge devices installed on some Gigabyte motherboards are not able to
      perform 64 dma correctly due to board PCI implementation, so limit
      DMA to 32bit if such boards are detected.
      
      Bug was reported here:
      https://bugzilla.redhat.com/show_bug.cgi?id=447489Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
      Tested-by: NLuya Tshimbalanga <luya@fedoraproject.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      392bd0cb
  7. 05 10月, 2010 1 次提交
  8. 04 10月, 2010 1 次提交
  9. 03 10月, 2010 7 次提交
  10. 02 10月, 2010 7 次提交
  11. 01 10月, 2010 10 次提交
  12. 30 9月, 2010 3 次提交