Bug 5444

Summary: busybox segfaults with 2-component linux version string
Product: Busybox Reporter: Michael Tokarev <mjt+busybox>
Component: OtherAssignee: unassigned
Status: RESOLVED FIXED    
Severity: minor CC: busybox-cvs
Priority: P5    
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Linux   
Host: Target:
Build:
Attachments: patch fixing this issue

Description Michael Tokarev 2012-08-11 19:05:29 UTC
I remember I filed a similar bug already, but can't find it now, so here it goes.

The summary tells it all.  With 2-component linux version string (like 3.0 or 3.5), busybox segfaults, because it expects the kernel version string to have at least 3 components.

The attached patch fixes this.
Comment 1 Michael Tokarev 2012-08-11 19:06:00 UTC
Created attachment 4484 [details]
patch fixing this issue
Comment 2 Denys Vlasenko 2012-08-16 09:18:55 UTC
Fixed already:

commit 556ac3633ce3e7bd51c93b78827ae3874d856257
Author: Andreas Oberritter <obi@opendreambox.org>
Date:   Sat May 5 17:47:23 2012 +0200

    get_linux_version_code: don't fail on Linux version strints like "3.0-foo"

    Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
    Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>

diff --git a/libbb/kernel_version.c b/libbb/kernel_version.c
index a168a1e..738ed02 100644
--- a/libbb/kernel_version.c
+++ b/libbb/kernel_version.c
@@ -20,18 +20,15 @@
 int FAST_FUNC get_linux_version_code(void)
 {
        struct utsname name;
-       char *s;
+       char *s, *t;
        int i, r;

-       if (uname(&name) == -1) {
-               bb_perror_msg("can't get system information");
-               return 0;
-       }
-
+       uname(&name); /* never fails */
        s = name.release;
        r = 0;
        for (i = 0; i < 3; i++) {
-               r = r * 256 + atoi(strtok(s, "."));
+               t = strtok(s, ".");
+               r = r * 256 + (t ? atoi(t) : 0);
                s = NULL;
        }
        return r;
Comment 4 Michael Tokarev 2012-09-21 04:22:42 UTC
Actually I don't think fixing this is necessary.  Well... It depends.

This whole function - get_linux_version_code() - is called for 2 reasons.

First is several places in modutils/, to support pre-2.4 kernel module loading.

And second is in nfs mount, to check that the kernel is more recent than 2.2.18(!), to use different nfs mount version.

I'm not sure how relevant both of these today.  For nfs mount, I don't think it counts at all nowadays.  For modutils it is questionable but might be useful still.  For these, maybe smaller code might be used, which just strcmp's uname.release with "2.4".

In debian I just patched out the call to get_linux_version_code() from nfs mount -- see http://anonscm.debian.org/gitweb/?p=d-i/busybox.git;a=commit;h=275f8c5dfc56b6d90846a249fc77a75731f01a3e .