Bug#701201: Bug#701805: add_uevent_var: buffer size too small
-------- Forwarded Message --------
From: Dr. Lars Hanke <lars@lhanke.de>
To: Ben Hutchings <ben@decadent.org.uk>
Subject: Re: Bug#701805: add_uevent_var: buffer size too small
Date: Wed, 27 Feb 2013 19:49:13 +0100
Am 27.02.2013 15:11, schrieb Ben Hutchings:
> Control: tag -1 moreinfo
>
> On Wed, 2013-02-27 at 12:46 +0100, Lars Hanke wrote:
> > Package: linux-2.6
> > Version: 2.6.32-48squeeze1
> > Severity: normal
> >
> >
> > I'm not sure what actually caused the issue. I did disconnect my
> > WD-Book (sdd) from the USB. I re-attached it after the error using
> > eSATA. This is what you see in the kernel log. However, the kernel
> > source points to a buffer overflow, which already happened, when this
> > message is generated. So it might be a critical security issue.
>
> The add_uevent_var() function uses vsnprintf() which limits the
> formatted string length. There is no buffer overflow.
Sorry, just had a glance at the code. Of course you're right.
>
> [...]
> > [ 1999.656073] usb 3-7: USB disconnect, address 5
> > [ 1999.681146] ------------[ cut here ]------------
> > [ 1999.681153] WARNING: at
> /build/buildd-linux-2.6_2.6.32-48squeeze1-amd64-qu4MIV/linux-2.6-2.6.32/debian/build/source_amd64_openvz/lib/kobject_uevent.c:313
> add_uevent_var+0xaf/0xf0()
> > [ 1999.681158] Hardware name: MS-7395
> > [ 1999.681160] add_uevent_var: buffer size too small
> > [ 1999.681171] Modules linked in: ses enclosure usbhid usb_storage
> hid ebtable_nat ebtables vzethdev vznetdev simfs vzrst vzcpt vzdquota
> vzmon vzdev ip6t_REJECT ip6table_mangle ip6table_filter ip6_tables
> xt_length xt_hl xt_limit xt_dscp ipt_REJECT acpi_cpufreq
> cpufreq_conservative cpufreq_stats cpufreq_powersave cpufreq_userspace
> capi capifs vzevent kvm_intel kvm fuse pppoe pppox ppp_generic slhc
> ipt_MASQUERADE iptable_nat nf_nat ipt_LOG nf_conntrack_ipv4
> nf_defrag_ipv4 xt_state xt_multiport iptable_filter xt_TCPMSS
> xt_tcpmss xt_tcpudp iptable_mangle ip_tables x_tables bridge stp xfs
> exportfs ext2 dm_crypt coretemp f71882fg nf_conntrack_ftp nf_conntrack
> loop snd_hda_codec_atihdmi snd_hda_codec_realtek snd_hda_intel
> snd_hda_codec snd_hwdep snd_pcm snd_seq b1pci b1dma b1 snd_timer
> kernelcapi snd_seq_device snd shpchp radeon ttm drm_kms_helper
> i2c_i801 pci_hotplug drm soundcore i2c_algo_bit parport_pc
> snd_page_alloc pcspkr usblp psmouse i2c_core parport evdev serio_raw
> processor
> > button ext3 jbd mbcache dm_mod raid456 md_mod async_raid6_recov
> async_pq raid6_pq async_xor xor async_memcpy async_tx sg sr_mod cdrom
> sd_mod crc_t10dif ata_generic ahci pata_jmicron r8169 ata_piix aic7xxx
> uhci_hcd thermal sundance libata mii ehci_hcd scsi_transport_spi
> scsi_mod thermal_sys usbcore nls_base [last unloaded: scsi_wait_scan]
> > [ 1999.681281] Pid: 264, comm: khubd Tainted: G W
> 2.6.32-5-openvz-amd64 #1
> > [ 1999.681283] Call Trace:
> > [ 1999.681288] [<ffffffff8117cc2b>] ? add_uevent_var+0xaf/0xf0
> > [ 1999.681292] [<ffffffff8117cc2b>] ? add_uevent_var+0xaf/0xf0
> > [ 1999.681296] [<ffffffff8104e0e4>] ? warn_slowpath_common+0x77/0xa3
> > [ 1999.681300] [<ffffffff8104e16c>] ? warn_slowpath_fmt+0x51/0x59
> > [ 1999.681304] [<ffffffff8118224e>] ? vsnprintf+0x40a/0x449
> > [ 1999.681308] [<ffffffff8117cc2b>] ? add_uevent_var+0xaf/0xf0
> > [ 1999.681313] [<ffffffff8121c116>] ? input_dev_uevent+0x267/0x29f
> > [ 1999.681318] [<ffffffff8120c102>] ? dev_uevent+0x13f/0x146
> > [ 1999.681322] [<ffffffff8117ce96>] ? kobject_uevent_env+0x22a/0x3e6
> > [ 1999.681326] [<ffffffff81210d90>] ? release_nodes+0x152/0x18b
> > [ 1999.681330] [<ffffffff8120c6a1>] ? device_del+0x15a/0x198
> > [ 1999.681334] [<ffffffff8120c6e8>] ? device_unregister+0x9/0x12
> > [ 1999.681340] [<ffffffffa0641518>] ? hidinput_disconnect+0x49/0x62
> [hid]
> > [ 1999.681344] [<ffffffffa063ff3a>] ? hid_disconnect+0x12/0x38 [hid]
> > [ 1999.681349] [<ffffffffa063ff8c>] ? hid_device_remove+0x2c/0x48 [hid]
> > [ 1999.681353] [<ffffffff8120e6fc>] ? __device_release_driver+0x96/0xeb
> > [ 1999.681357] [<ffffffff8120e809>] ? device_release_driver+0x1e/0x2a
> > [ 1999.681361] [<ffffffff8120de05>] ? bus_remove_device+0x8d/0xac
> > [ 1999.681365] [<ffffffff8120c677>] ? device_del+0x130/0x198
> > [ 1999.681369] [<ffffffffa063facb>] ? hid_destroy_device+0x19/0x35
> [hid]
> > [ 1999.681374] [<ffffffffa066c899>] ? usbhid_disconnect+0x30/0x39
> [usbhid]
> > [ 1999.681386] [<ffffffffa00117e5>] ?
> usb_unbind_interface+0x5b/0xe3 [usbcore]
> [...]
>
> This is all about a HID (human input device) being removed. Is there a
> button on the WD-Book that is meant to start a backup, or something like
> that?
It has a single button, which is supposed to switch it on and off. This
actually doesn't work too well, so I usually tear out the AC adapter. If
at the end of the day they register this button as HID and use some M$
driver to do it in software, this would explain both the strange
behavior of the WD-Book and the kernel log.
Hmm, now took some minutes to look at the code. A 2k buffer seems fair
enough for some event data concerning device disconnection. Don't know
what is intended in the kernel, i.e. whether this is an issue with the
kernel or with the device. On the other hand, the device has already
been disconnected when the ENOMEM was issued. So it's unlikely data sent
by the device causing the error.
Regards,
- lars.
Reply to: