Bug in 'sort -n' (textutils-2.0a)

[ewheeler]

To whoever will get to fix this:
        sort -n works great as long as there is something following the
number that is more than a carriage return.  

Ex:
        file 'a' contains 
5
2
2
6
7
222
6
23
62
112
74


If we 'cat a | sort -n' we get :
6
2
5
74
6
222
7
112
62
23


If we put a little while loop in the middle which pads the line with
*anything* (whitespace or other) with 
'cat a | (while read a; do echo "$a""b"; done) | sort -n'
It spits out:
2b
2b
5b
6b
6b
7b
23b
62b
74b
112b
222b

If this is done padding with a space rather than a 'b' with 
'cat tt | (while read a; do echo "$a "; done) | sort -n'
we get out:
2
2
5
6
6
7
23
62
74
112
222



I found this when tring to sort the N's of my eth:N aliases like this:
ifconfig | grep 'eth0:[0-9]' | cut -f2 -d : | cut -f1 -d ' ' | sort -n


If spat out 
1
0
3
5
4
8
7
6
19
10
9
13
12
11
15
14
18
17
16

When I reordered the command with the second cut after the sort, it looked
like the following since sort received the numbers with some stuff
trailing rather than being strait numbers as before.  The command I used
was 
"ifconfig | grep 'eth0:[0-9]' | cut -f2 -d : | sort -n | cut -f1 -d ' '"
Which spit out what it should have in the first place:
0
1
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

I doubt this is exploitable since sort isn't suid-anything, but it does
point out a flaw in sort one way or another and I don't know if it leads
to a buffer overflow or not.  If it does, WAHOO!  I found a possible
exploitable tool.  If not, then :(.  If this is wrong, or has already been
fixed then let me know.  I'd like to know the outcome of this reguardless
of what happens.

--Eric Wheeler