Skip to contentSkip to conversation

fix use after free in smbfs.

PATCH New Dave Jones 1 participant 1 message Jul 7, 2005

lore
Share & tools
lore

Dave Jones

author
#0 lore raw

PATCH 1/1 fix use after free in smbfs.

Quoted 1 line

From code inspection it seems that after freeing 'req', in smb_request()

we continue to dereference it a dozen or so times.

That whole area of code looks suspect.

		...
        smb_lock_server(server);
        if (!(req->rq_flags & SMB_REQ_RECEIVED)) {
            list_del_init(&req->rq_queue);
            smb_rput(req);
        }

smb_rput() also does a list_del_init, but only if its safe to do so (ie, the refcount has dropped to 0).
To my not-smbfs-savvy eyes, it would seem that we could potentially nuke the ->rq_queue list, and return from smb_rput() if the request was still in use. What the rest of the code does with such a buggered-up request, I've no idea, but it probably isn't pretty.

Perhaps smb_rput should be taking a pointer to a request that can be null'd on success ?

fs/smbfs/request.c renamed from fs/smbfs/request.c~ +1 -0
@@ -348,6 +348,7 @@ int smb_add_request(struct smb_request *
 			smb_rput(req);
 		}
 		smb_unlock_server(server);
+		return -EINTR;
 	}
 
 	if (!timeleft) {

Looking further, we do exactly the same thing in smb_request_recv()

        smb_rput(req);
        wake_up_interruptible(&req->rq_wait);
    }

ditto in smbiod.c..

What am I missing here? smb_rput() -> smb_free_request() does a kmem_cache_free(req_cachep, req); making further use of that cache item invalid.

Dave