From jhb at freebsd.org Fri Nov 6 15:51:04 2009 From: jhb at freebsd.org (John Baldwin) Date: Fri Nov 6 15:51:10 2009 Subject: [PATCH] Buffer overflow in devclass_add_device() In-Reply-To: <3bbf2fe10911060720m6d6919ffw91dcc5b6c1c2016a@mail.gmail.com> References: <3bbf2fe10911060720m6d6919ffw91dcc5b6c1c2016a@mail.gmail.com> Message-ID: <200911061043.52738.jhb@freebsd.org> On Friday 06 November 2009 10:20:35 am Attilio Rao wrote: > A buffer overflow is possible in devclass_add_device(). > More specifically, the dev nameunit construction is based on the > assumption that the unit linked with the device is invariant but that > can change when calling devclass_alloc_unit() (because -1 is passed > or, more simply, because the unit choosen is beyond the table limits). > This results in a buffer overflow if the bug is too short on the > second snprintf(). > This patch should fix it: > http://www.freebsd.org/~attilio/Sandvine/STABLE_8/subr_bus/subr_bus.diff > > aiming for the max possible number of digits necessary. > This bug has been found by Sandvine Incorporated. > Please reivew. Looks ok to me. -- John Baldwin From attilio at freebsd.org Fri Nov 6 15:52:08 2009 From: attilio at freebsd.org (Attilio Rao) Date: Fri Nov 6 15:52:14 2009 Subject: [PATCH] Buffer overflow in devclass_add_device() Message-ID: <3bbf2fe10911060720m6d6919ffw91dcc5b6c1c2016a@mail.gmail.com> A buffer overflow is possible in devclass_add_device(). More specifically, the dev nameunit construction is based on the assumption that the unit linked with the device is invariant but that can change when calling devclass_alloc_unit() (because -1 is passed or, more simply, because the unit choosen is beyond the table limits). This results in a buffer overflow if the bug is too short on the second snprintf(). This patch should fix it: http://www.freebsd.org/~attilio/Sandvine/STABLE_8/subr_bus/subr_bus.diff aiming for the max possible number of digits necessary. This bug has been found by Sandvine Incorporated. Please reivew. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From imp at bsdimp.com Fri Nov 6 16:21:11 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Fri Nov 6 16:21:22 2009 Subject: [PATCH] Buffer overflow in devclass_add_device() In-Reply-To: <3bbf2fe10911060720m6d6919ffw91dcc5b6c1c2016a@mail.gmail.com> References: <3bbf2fe10911060720m6d6919ffw91dcc5b6c1c2016a@mail.gmail.com> Message-ID: <20091106.091543.2076840904.imp@bsdimp.com> In message: <3bbf2fe10911060720m6d6919ffw91dcc5b6c1c2016a@mail.gmail.com> Attilio Rao writes: : A buffer overflow is possible in devclass_add_device(). : More specifically, the dev nameunit construction is based on the : assumption that the unit linked with the device is invariant but that : can change when calling devclass_alloc_unit() (because -1 is passed : or, more simply, because the unit choosen is beyond the table limits). : This results in a buffer overflow if the bug is too short on the : second snprintf(). : This patch should fix it: : http://www.freebsd.org/~attilio/Sandvine/STABLE_8/subr_bus/subr_bus.diff : : aiming for the max possible number of digits necessary. : This bug has been found by Sandvine Incorporated. : Please reivew. I don't see a problem with it, except you'd want -INT_MAX to be paranoid, since it is one character longer (or just add 1) :) However, it might be better to just allocate strlen(dc->name) + log10(INT_MAX) + 2 and not have snprintf do that calculation. But it doesn't look like there's a compile-time constant for that... Warner From attilio at freebsd.org Fri Nov 6 16:22:38 2009 From: attilio at freebsd.org (Attilio Rao) Date: Fri Nov 6 16:22:45 2009 Subject: [PATCH] Buffer overflow in devclass_add_device() In-Reply-To: <20091106.091543.2076840904.imp@bsdimp.com> References: <3bbf2fe10911060720m6d6919ffw91dcc5b6c1c2016a@mail.gmail.com> <20091106.091543.2076840904.imp@bsdimp.com> Message-ID: <3bbf2fe10911060822g35b81099ib6fa53473d7c20fe@mail.gmail.com> 2009/11/6 M. Warner Losh : > In message: <3bbf2fe10911060720m6d6919ffw91dcc5b6c1c2016a@mail.gmail.com> > Attilio Rao writes: > : A buffer overflow is possible in devclass_add_device(). > : More specifically, the dev nameunit construction is based on the > : assumption that the unit linked with the device is invariant but that > : can change when calling devclass_alloc_unit() (because -1 is passed > : or, more simply, because the unit choosen is beyond the table limits). > : This results in a buffer overflow if the bug is too short on the > : second snprintf(). > : This patch should fix it: > : http://www.freebsd.org/~attilio/Sandvine/STABLE_8/subr_bus/subr_bus.diff > : > : aiming for the max possible number of digits necessary. > : This bug has been found by Sandvine Incorporated. > : Please reivew. > > I don't see a problem with it, except you'd want -INT_MAX to be > paranoid, since it is one character longer (or just add 1) :) I don't think that unit number can grow negative, can they? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From jhb at freebsd.org Fri Nov 6 16:45:30 2009 From: jhb at freebsd.org (John Baldwin) Date: Fri Nov 6 16:45:36 2009 Subject: [PATCH] Buffer overflow in devclass_add_device() In-Reply-To: <20091106.091543.2076840904.imp@bsdimp.com> References: <3bbf2fe10911060720m6d6919ffw91dcc5b6c1c2016a@mail.gmail.com> <20091106.091543.2076840904.imp@bsdimp.com> Message-ID: <200911061145.19212.jhb@freebsd.org> On Friday 06 November 2009 11:15:43 am M. Warner Losh wrote: > In message: <3bbf2fe10911060720m6d6919ffw91dcc5b6c1c2016a@mail.gmail.com> > Attilio Rao writes: > : A buffer overflow is possible in devclass_add_device(). > : More specifically, the dev nameunit construction is based on the > : assumption that the unit linked with the device is invariant but that > : can change when calling devclass_alloc_unit() (because -1 is passed > : or, more simply, because the unit choosen is beyond the table limits). > : This results in a buffer overflow if the bug is too short on the > : second snprintf(). > : This patch should fix it: > : http://www.freebsd.org/~attilio/Sandvine/STABLE_8/subr_bus/subr_bus.diff > : > : aiming for the max possible number of digits necessary. > : This bug has been found by Sandvine Incorporated. > : Please reivew. > > I don't see a problem with it, except you'd want -INT_MAX to be > paranoid, since it is one character longer (or just add 1) :) > > However, it might be better to just allocate strlen(dc->name) + > log10(INT_MAX) + 2 and not have snprintf do that calculation. But it > doesn't look like there's a compile-time constant for that... In this case I think the snprintf() is fine as code-wise I think it is simpler (it matches up well with the later snprintf() to fill out the buffer). Given that adding devices isn't generally a critical-path, I think the clarity is worth the probably quite small additional cost of snprintf(). -- John Baldwin From imp at bsdimp.com Fri Nov 6 16:49:47 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Fri Nov 6 16:49:54 2009 Subject: [PATCH] Buffer overflow in devclass_add_device() In-Reply-To: <3bbf2fe10911060822g35b81099ib6fa53473d7c20fe@mail.gmail.com> References: <3bbf2fe10911060720m6d6919ffw91dcc5b6c1c2016a@mail.gmail.com> <20091106.091543.2076840904.imp@bsdimp.com> <3bbf2fe10911060822g35b81099ib6fa53473d7c20fe@mail.gmail.com> Message-ID: <20091106.093847.1347313226.imp@bsdimp.com> In message: <3bbf2fe10911060822g35b81099ib6fa53473d7c20fe@mail.gmail.com> Attilio Rao writes: : 2009/11/6 M. Warner Losh : : > In message: <3bbf2fe10911060720m6d6919ffw91dcc5b6c1c2016a@mail.gmail.com> : > Attilio Rao writes: : > : A buffer overflow is possible in devclass_add_device(). : > : More specifically, the dev nameunit construction is based on the : > : assumption that the unit linked with the device is invariant but that : > : can change when calling devclass_alloc_unit() (because -1 is passed : > : or, more simply, because the unit choosen is beyond the table limits). : > : This results in a buffer overflow if the bug is too short on the : > : second snprintf(). : > : This patch should fix it: : > : http://www.freebsd.org/~attilio/Sandvine/STABLE_8/subr_bus/subr_bus.diff : > : : > : aiming for the max possible number of digits necessary. : > : This bug has been found by Sandvine Incorporated. : > : Please reivew. : > : > I don't see a problem with it, except you'd want -INT_MAX to be : > paranoid, since it is one character longer (or just add 1) :) : : I don't think that unit number can grow negative, can they? They can't, but this is about an abundance of caution, right? Warner From attilio at freebsd.org Sun Nov 8 16:53:23 2009 From: attilio at freebsd.org (Attilio Rao) Date: Sun Nov 8 16:53:34 2009 Subject: [PATCH] Collapsing device_state_t with devinfo_state_t Message-ID: <3bbf2fe10911080853qad0057w490694e5627681fe@mail.gmail.com> This patch should collpase device_state_t with devinfo_state_t and remove a bogus replication of this struct: http://www.freebsd.org/~attilio/devinfo.diff This patch breaks ABI so it cannot be MFC'ed (and it is not intended to do). Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From attilio at freebsd.org Sun Nov 8 16:54:53 2009 From: attilio at freebsd.org (Attilio Rao) Date: Sun Nov 8 16:55:08 2009 Subject: [PATCH] Collapsing device_state_t with devinfo_state_t In-Reply-To: <3bbf2fe10911080853qad0057w490694e5627681fe@mail.gmail.com> References: <3bbf2fe10911080853qad0057w490694e5627681fe@mail.gmail.com> Message-ID: <3bbf2fe10911080854x64d18e40hf639634e625dd11b@mail.gmail.com> 2009/11/8 Attilio Rao : > This patch should collpase device_state_t with devinfo_state_t and > remove a bogus replication of this struct: > http://www.freebsd.org/~attilio/devinfo.diff Sorry, forgot to mention: I thought about adding _bus.h interface because I thought that devinfo.h wanted to avoid a namespace pollution, but that's not really the case as 85% of the bus.h is already under _KERNEL labels. That means the pollution is minimal and restricted to 1-2 further structs. Attilio -- Peace can only be achieved by understanding - A. Einstein From imp at bsdimp.com Mon Nov 9 01:34:11 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Mon Nov 9 01:34:18 2009 Subject: [PATCH] Collapsing device_state_t with devinfo_state_t In-Reply-To: <3bbf2fe10911080854x64d18e40hf639634e625dd11b@mail.gmail.com> References: <3bbf2fe10911080853qad0057w490694e5627681fe@mail.gmail.com> <3bbf2fe10911080854x64d18e40hf639634e625dd11b@mail.gmail.com> Message-ID: <20091108.182556.1680365520.imp@bsdimp.com> In message: <3bbf2fe10911080854x64d18e40hf639634e625dd11b@mail.gmail.com> Attilio Rao writes: : 2009/11/8 Attilio Rao : : > This patch should collpase device_state_t with devinfo_state_t and : > remove a bogus replication of this struct: : > http://www.freebsd.org/~attilio/devinfo.diff : : Sorry, forgot to mention: : I thought about adding _bus.h interface because I thought that : devinfo.h wanted to avoid a namespace pollution, but that's not really : the case as 85% of the bus.h is already under _KERNEL labels. That : means the pollution is minimal and restricted to 1-2 further structs. I'm cool with this patch, and that decision. Warner From attilio at freebsd.org Mon Nov 9 02:02:23 2009 From: attilio at freebsd.org (Attilio Rao) Date: Mon Nov 9 02:02:29 2009 Subject: [PATCH] Collapsing device_state_t with devinfo_state_t In-Reply-To: <3F7C0F44-7E90-4196-8CFA-724E1297B2A6@samsco.org> References: <3bbf2fe10911080853qad0057w490694e5627681fe@mail.gmail.com> <3F7C0F44-7E90-4196-8CFA-724E1297B2A6@samsco.org> Message-ID: <3bbf2fe10911081802q2b691218hd2a2736fefcb232c@mail.gmail.com> 2009/11/9 Scott Long : > On Nov 8, 2009, at 9:53 AM, Attilio Rao wrote: >> >> This patch should collpase device_state_t with devinfo_state_t and >> remove a bogus replication of this struct: >> http://www.freebsd.org/~attilio/devinfo.diff >> >> This patch breaks ABI so it cannot be MFC'ed (and it is not intended to >> do). >> > > Does this hinder FreeBSD 8 from ever getting a Giant-free newbus? As foretold in several e-mails and threads, FreeBSD-8 has all the needed support for Giant-free newbus, that's just an improvement I couldn't let happen before because we had to maintain ABI stability over the release process, but it doesn't compromise at all possibility to MFC Giant-free newbus. Attilio -- Peace can only be achieved by understanding - A. Einstein From scottl at samsco.org Mon Nov 9 02:12:00 2009 From: scottl at samsco.org (Scott Long) Date: Mon Nov 9 02:12:06 2009 Subject: [PATCH] Collapsing device_state_t with devinfo_state_t In-Reply-To: <3bbf2fe10911080853qad0057w490694e5627681fe@mail.gmail.com> References: <3bbf2fe10911080853qad0057w490694e5627681fe@mail.gmail.com> Message-ID: <3F7C0F44-7E90-4196-8CFA-724E1297B2A6@samsco.org> On Nov 8, 2009, at 9:53 AM, Attilio Rao wrote: > This patch should collpase device_state_t with devinfo_state_t and > remove a bogus replication of this struct: > http://www.freebsd.org/~attilio/devinfo.diff > > This patch breaks ABI so it cannot be MFC'ed (and it is not intended > to do). > Does this hinder FreeBSD 8 from ever getting a Giant-free newbus? Scott