#4720 Webmin 1.780 File Manager: CPU redlines after file upload double-submit.

[Chris Luzine]

Platform: RHEL 6.7
Browser: IE 11 (not reproducible on Firefox 44.0.2)

From the Webmin 1.780 (HTML) File Manager,
1- click the 'Upload Files' button (green up-arrow icon)
2- browse to a file for upload
3- click the OK button multiple times in rapid succession

The file upload completes successfully. However, multiple upload processes persist, and, collectively, they max out the CPU:

top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11457 root 20 0 98516 24m 2504 R 33.4 0.6 3:30.12 miniserv.pl
11755 root 20 0 98512 24m 2492 R 33.4 0.6 3:29.58 miniserv.pl
11804 root 20 0 98496 24m 2492 R 31.4 0.6 3:29.43 miniserv.pl

ps -ef | grep upload.cgi
root 11457 5921 29 11:04 ? 00:03:48 /usr/libexec/webmin/filemin/upload.cgi
root 11755 5921 32 11:05 ? 00:03:47 /usr/libexec/webmin/filemin/upload.cgi
root 11804 5921 32 11:05 ? 00:03:47 /usr/libexec/webmin/filemin/upload.cgi

An interesting oddity: instead of seeing the Upload progress popup, the following security warning popup was being issued by IE 11:

Warning! Webmin has detected that the program https://xxxxx:10000/uptracker.cgi?id=145796856913399&uid=0 was linked to from an unknown URL, which appears to be outside the Webmin server. This may be an attempt to trick your server into executing a dangerous command. Make sure your browser is configured to send referrer information so that it can be verified by Webmin.

This was not the cause of the problem, though. Upon setting referers_none=0 in the webmin config file, the Upload progress window did appear, but the 100% CPU utilization issue still emerged.

Another interesting oddity: if you upload a file from Windows using IE 11, the entire source path is embedded in the destination filename, whereras if you upload the same file from Firefox 44.0.2, only the file name proper appears.

ls -l /tmp
-rw-r-----. 1 root root 28708923 Mar 14 12:50 webmin-1.791-1.noarch.rpm
-rw-r-----. 1 root root 28708923 Mar 14 12:50 C:\Users\xxx\Downloads\webmin-1.791-1.noarch.rpm

[Jamie Cameron]

This has been a tough one for me to re-produce. Does it only happen on IE11, and only if you click the OK button multiple times?

[Chris Luzine]

I upgraded to Webmin 1.791 and repeated the steps. I was able to reproduce the issue using IE11 (11.0.28) and also Chrome 49.0.2623.87. I still cannot reproduce on Firefox 44.0.2.
I only see the problem when I re-click the OK button while the upload is in progress. Basically, click OK, wait for the first set of bars to appear on the progress dialogue, then click OK again. On IE and Chrome, a new progress dialogue appears, allowing you to re-click again. (On Chrome, the progress dialogue covers the OK button, so you have to alt-tab; on IE, the progress dialogue doesn't hide the OK button.) If, in total, I click OK say, four times, I end up with three stray processes. In the browser, I eventually see the message:

Following errors occured while performing operation

/tmp/webmin-1.780-1.noarch.rpm already exists, skipping
<-  Return to previous page

...and the file is indeed on disk.

[Chris Luzine]

I instrumented (aka put some print statements into) filemin/upload.cgi. Here's what I've learned: the last process is the only one that actually exits. All earlier processes hang around, chewing cpu. The proximate cause of this is the code

while (1)
{
$line = <STDIN>
...
}

In a two process example, the first process is chugging away, uploading the file and writing it to disk. After the second process is spawned, the first process is able to read about 65K more data (a buffer's worth???), before the readline operator <> returns undef. Since the condition is not checked, it loops forever after. The first process never reads the boundary line indicating the end of the mime part.

The second process does everything right. It detects the prior existence of the file, and starts skipping over data. It does see the multipart mime boundary ( -----------------------------7e0bb33300e40-- in my case). Thereupon it exits, and reports the error back to the browser.

Note that while the file exists on disk afterward, it is generally not complete -- being smaller than the original.

At a guess, the browser terminates the first file upload when it receives a second overlapping request to the upload the same file.

[Jamie Cameron]

Thanks for debugging this! I will fix this in the next Webmin release.

[Chris Luzine]

I verified using the latest version of filemin/upload.cgi from github. Definitely a step in the right direction. As it happens, there are two nested while loops. The fix kicks us out of the inner loop. We need something similar to exit the outer loop. I tried the following (find attached a diff file) -- it is more of a quick fix than a long term solution. It does seem to solve the problem, and, as a bonus, removes the partially uploaded file.

Let me know if there is a better way for me to send source and diffs.

[Jamie Cameron]

Ok, I've committed another fix to break completely out of the loop on an error.