[PATCH] Don't modify memory reference provided by value
Swen Schillig
swen at vnet.ibm.com
Tue Feb 6 11:59:20 UTC 2018
On Tue, 2018-02-06 at 12:45 +0100, Stefan Metzmacher wrote:
> Hi Swen,
>
> what problem are you trying to solve here?
>
> talloc_memdup() is at least wrong here! (The same applies to the
> push_blocking_lock_request() patch).
Sorry, I tried to explain it as good as I can.
The problem is, that memory is accessed after the ownership moved.
...and even a use-after-free situation could occur.
Here's the possible call stack
void reply_write_and_X(struct smb_request *req)
{
.....
if(numtowrite == 0) {
nwritten = 0;
} else {
if (req->unread_bytes == 0) {
status = schedule_aio_write_and_X(conn,
req, <====
fsp,
data,
startpos,
numtowrite);
...
out:
if (req->unread_bytes) { <=== here we access req which was talloc_moved above
/* writeX failed. drain socket. */
if (drain_socket(xconn->transport.sock, req->unread_bytes) !=
req->unread_bytes) {
smb_panic("failed to drain pending bytes");
}
req->unread_bytes = 0;
}
}
and within schedule_aio_write_and_X we do what's wrong
NTSTATUS schedule_aio_write_and_X(connection_struct *conn,
struct smb_request *smbreq, <=====
files_struct *fsp, const char *data,
off_t startpos,
size_t numtowrite)
{
...
aio_ex->smbreq = talloc_move(aio_ex, &smbreq); <=== zero'ing smbreq is
only having local
effect but the
stealing part
is problematic
...
}
Am I missing something ?
...and why is talloc_memdup wrong ?
Cheers Swen
More information about the samba-technical
mailing list