Michael Stone <mst...@debian.org> (11/02/2012): > Package: bash > Version: 4.2-1 > Severity: critical > Justification: breaks unrelated software
I don't think it's bash at fault here. Seen on 4.1-3 as well (squeeze's). > $ dash -c 'while read line ; do echo $line ; done < /proc/net/dev' > Inter-| Receive | Transmit > face |bytes packets errs drop fifo frame compressed multicast|bytes packets > errs drop fifo colls carrier compressed > eth0.6: 128 1 0 0 0 0 0 1 9447 34 0 0 0 0 0 0 > lo: 1160 20 0 0 0 0 0 0 1160 20 0 0 0 0 0 0 > eth0: 544591 566 0 0 0 0 0 0 88849 553 0 0 0 0 0 0 > eth0.3: 533751 526 0 0 0 0 0 3 69559 482 0 0 0 0 0 0 strace shows it's reading byte after byte, so easy peasy. > $ ksh -c 'while read line ; do echo $line ; done < /proc/net/dev' strace shows it's reading 8KB at once, so easy peasy too, but a different one. > $ bash -c 'while read line ; do echo $line ; done < /proc/net/dev' > Inter-| Receive | Transmit > face |bytes packets errs drop fifo frame compressed multicast|bytes packets > errs drop fifo colls carrier compressed > lo: 1160 20 0 0 0 0 0 0 1160 20 0 0 0 0 0 0 strace shows it's reading 128 bytes, then trying to adjust using lseek(), which might explain what you're seeing if the read() + lseek() calls trigger nasty things. > Note that the output from bash is missing several lines that are in the output > from dash. I've also seen cases where bogus output is added. This only seems > to > affect cases where input is redirected from a /proc file; if I cat the > procfile > and pipe into the while loop it isn't an issue. Yeah, /proc files are special. > Problem presents with kernel 3.2.0; the problem does not appear if booted with > an older kernel (tested with 2.6.32). OTOH, all other tested shells do not > exhibit the problem. Based on the above comments, other shells don't really matter, they read the file in a different manner. A small PoC with a tiny source file would be nice, I'll try and gather that. Mraw, KiBi.
signature.asc
Description: Digital signature
