Bug 12412 - freshclam can't chdir() back to its original directory, then double-free()s
freshclam can't chdir() back to its original directory, then double-free()s
Status: RESOLVED FIXED
Product: ClamAV
Classification: ClamAV
Component: freshclam
stable
x86 GNU/Linux
: P3 normal
: 0.101.0
Assigned To: Micah Snyder
:
: 12442 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-10-06 22:07 EDT by Todd Eigenschink
Modified: 2019-11-18 21:27 EST (History)
2 users (show)

See Also:
QA Contact:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Todd Eigenschink 2019-10-06 22:07:20 EDT
After updating to 0.102.0, our regularly scheduled freshclam dies like so:

ClamAV update process started at Sun Oct  6 21:36:50 2019
ERROR: Failed to change back to original directory /root
double free or corruption detected in tcache 2


It's permission-related, as after doing its setuid() to the clamav user, it no longer has permission to chdir back to /root (where cron starts it). That makes sense, but then it goes off the rails and dies with the double free.

If run from a directory like /tmp, it works fine.

For my purposes, I suppressed the fetch of the starting directory, so it doesn't try to chdir back. In the process of doing that, I realized there was a missing line in one of the three functions that saves/restores the current dir.

I could tinker with the starting dir to avoid the problem, but (1) it seems like maybe a command line option to suppress the chdir might be better. I haven't thought much about it...I'm not sure why the save/restore is even needed, except maybe for daemon mode?

Anyway, (2) even if the feature stays as is, failing to chdir back shouldn't cause a double free.


Here's the patch I'm running with for the moment. The very first addition is the line that's missing, regardless of the chdir issue.


--- clamav-0.102.0/libfreshclam/libfreshclam.c.orig	2019-10-01 13:24:09.000000000 -0400
+++ clamav-0.102.0/libfreshclam/libfreshclam.c	2019-10-06 21:51:51.000000000 -0400
@@ -313,8 +313,10 @@
 
     char currDir[PATH_MAX];
 
+    currDir[0] = '\0';
+
     /* Store CWD */
-    if (!getcwd(currDir, PATH_MAX)) {
+    if (0 && !getcwd(currDir, PATH_MAX)) {
         logg("!getcwd() failed\n");
         status = FC_EDIRECTORY;
         goto done;
@@ -622,7 +624,7 @@
     *bUpdated = 0;
 
     /* Store CWD */
-    if (!getcwd(currDir, PATH_MAX)) {
+    if (0 && !getcwd(currDir, PATH_MAX)) {
         logg("!getcwd() failed\n");
         status = FC_EDIRECTORY;
         goto done;
@@ -784,7 +786,7 @@
     *bUpdated = 0;
 
     /* Store CWD */
-    if (!getcwd(currDir, PATH_MAX)) {
+    if (0 && !getcwd(currDir, PATH_MAX)) {
         logg("!getcwd() failed\n");
         status = FC_EDIRECTORY;
         goto done;
Comment 1 Micah Snyder 2019-10-09 21:58:42 EDT
Hi Todd,

For a moment, I got your bug report confused with a report in an email from another user who is experiencing the same issue.  

Thanks for the report and for identifying the cause.  We'll look into this and see if we can get a fix into an upcoming 0.102.1 patch release.

Micah
Comment 2 Micah Snyder 2019-11-05 16:52:04 EST
Hi Todd,

We've fixed this here: https://github.com/Cisco-Talos/clamav-devel/commit/4d0d744988f04dc3d77574c629997a85e9b15648

We've also fixed it in the dev branch for 0.102.1, but that branch is private for now while we address security related bugfixes. 

Thanks for reporting the issue!

Micah
Comment 3 Micah Snyder 2019-11-18 21:27:04 EST
*** Bug 12442 has been marked as a duplicate of this bug. ***