From: David Brownell <firstname.lastname@example.org> To: Andi Kleen <email@example.com> Cc: Matthew Dharm <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Re: [linux-usb-devel] [RFC] consolidate /sbin/hotplug call for pci and usb Date: Wed, 25 Sep 2002 19:30:41 -0700 [thread overview] Message-ID: <3D927151.email@example.com> (raw) In-Reply-To: <20020925174612.A13467@one-eyed-alien.net> >>>>+ envp[i++] = scratch; >>>>+ scratch += sprintf (scratch, "PCI_ID=%04X:%04X", >>>>+ pdev->vendor, pdev->device) + 1; >>> >>>And so forth. Use "snprintf" and prevent overrunning those buffers... >> >>Hmm? An %04X format is perfectly bounded. Which was my thought when I originally wrote the code which has been widely cut'n'pasted. Safe enough at that moment, but it's now become dangerous to leave that around as a copy/paste coding example. Those code fragments are now being used in contexts that aren't as controlled as the original: the code _using_ the buffer is no longer in charge of allocating it. There's no longer any way to guarantee that adding the next parameter to the environment isn't going to overrun the available space. Except by using "snprintf" and tracking how much space is left. Easy enough to do, and that's a habit that IMO _everyone_ should be getting into whenever they program in languages that permit such buffer overflows. > Technically, it isn't bounded. The field will expand if the value exceeds > 4 digits. > > However, these values can't do that. At least not now. > > But, as a good programming practice, snprintf should be used. Heck, PCI > 3.0 might use 32-bit vendor and device values, instead of 8 bit. So, if > nothing else, do it as insurance for the future. And to help ensure that as people continue to copy/paste code from the core hotpluggable systems, they won't break things when they add the parameters needed to set up their new subsystem or class, using the /sbin/hotplug mechanism. - Dave
next prev parent reply other threads:[~2002-09-26 2:25 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <20020925212955.GA32487@kroah.com.suse.lists.linux.kernel> [not found] ` <3D9250CD.firstname.lastname@example.org> 2002-09-26 0:33 ` Andi Kleen 2002-09-26 0:46 ` Matthew Dharm 2002-09-26 1:01 ` Andi Kleen 2002-09-26 2:30 ` David Brownell [this message] 2002-09-25 21:29 Greg KH 2002-09-26 0:11 ` [linux-usb-devel] " David Brownell 2002-09-26 0:25 ` Greg KH 2002-09-26 2:44 ` David Brownell 2002-09-26 4:27 ` Greg KH 2002-09-26 16:14 ` David Brownell 2002-09-26 18:43 ` Greg KH 2002-09-26 19:32 ` David Brownell 2002-09-26 19:34 ` Alan Stern
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=3D927151.email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [linux-usb-devel] [RFC] consolidate /sbin/hotplug call for pci and usb' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).