--8323328-1707146190-910408192=:12744
Content-Type: TEXT/PLAIN; charset=US-ASCII
A call to getsockname() will always return EFAULT but will in fact succeed
(given it *really* succeeds, it might actually EFAULT you know). included is
a server.c and client.c used to test the patch I've included.
Here it is, real quick like. From sys_getsockname() -> move_addr_to_user()
you will find that the following call to get_user will always result in an
-EFAULT return value.
-------snip-------
int move_addr_to_user(void *kaddr, int klen, void *uaddr, int *ulen)
{
int err;
int len;
if((err=get_user(len, ulen)))
return err;
-------snip-------
with get_user() you should be passing the address of the data you wish to
get the length of, where here you are passing the length of the data that
you want to get the length of.
Am I wrong on this? I checked the source as well as the man 9 get_user
documentation and this is what I've concluded. If you look at the order in
which sys_getsockname() does it's work this would fit very well with the
fact that sockgetname() will always succeed but always return EFAULT.
Here is a stupid little patch, this is against 2.1.127pre7, I don't know if
it applies to anything sooner. I know nothing pre 2.1.x works like this
though.
-------snip-------
--- socket.c.old Thu Aug 27 19:33:09 1998
+++ socket.c Fri Nov 6 19:32:35 1998
@@ -170,7 +170,7 @@
int err;
int len;
- if((err=get_user(len, ulen)))
+ if((err=get_user(len, uaddr)))
return err;
if(len>klen)
len=klen;
-------snip-------
And just a purely stupid question here. Why would a kernel function set a
return value to something like -EFAULT or -EBADF when a user program would
check against that value with EFAULT or EBADF? Does the - not negate the
value? I'm not saying it's wrong LOL, because it works. But what does it
do why is it done that way?
:) Yeah, I should get a few interesting emails about that eh?
----------------------------------------------------
ely <plexus@ionet.net>
*********** quickie before I send this off **********
Here's a few instances where move_addr_to_user() is used and in all but one
case (sys_recvmsg it *seems*) that the calls should always return EFAULT
but they will otherwise succeed in their task. Kind of makes you wonder.
in socket.c -> sys_accept() :
-------
}
/* N.B. Should check for errors here */
move_addr_to_user(address, len, upeer_sockaddr,
upeer_addrlen);
}
-------
in socket.c -> sys_getpeername() :
-------
if (!err)
err=move_addr_to_user(address,len, usockaddr,
usockaddr_len);
sockfd_put(sock);
}
unlock_kernel();
return err;
}
-------
in socket.c -> sys_recvfrom() :
-------
if(err >= 0 && addr != NULL)
{
err2=move_addr_to_user(address, msg.msg_namelen, addr,
addr_len);
if(err2<0)
err=err2;
}
sockfd_put(sock);
out:
unlock_kernel();
return err;
}
-------
in socket.c -> sys_recvmsg() :
-------
if (uaddr != NULL) {
err = move_addr_to_user(addr, msg_sys.msg_namelen, uaddr,
uaddr_len);
if (err < 0)
goto out_freeiov;
}
-------
"awaiting the wave of kernel hacker flames"
--8323328-1707146190-910408192=:12744
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="client.c"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.05.9811062009520.12744@localhost.localdomain>
Content-Description:
Content-Disposition: attachment; filename="client.c"
LyogY2xpZW50LmMgKi8NCg0KI2luY2x1ZGUgPHN0ZGlvLmg+DQojaW5jbHVk
ZSA8c3RkbGliLmg+DQojaW5jbHVkZSA8c3lzL3NvY2tldC5oPg0KI2luY2x1
ZGUgPG5ldGluZXQvaW4uaD4NCiNpbmNsdWRlIDxhcnBhL2luZXQuaD4NCiNp
bmNsdWRlIDxlcnJuby5oPg0KDQppbnQgc29ja19kZXNjcmlwdG9yOw0Kc3Ry
dWN0IHNvY2thZGRyX2luCXNvY2tfYWRkcmVzcywgY29ubmVjdF9hZGRyZXNz
Ow0KY2hhciAqcmVzcG9uc2U7DQoNCmludCBtYWluKHZvaWQpIA0Kew0KCS8q
IG9wZW4gc29ja2V0ICovDQoJc29ja19kZXNjcmlwdG9yID0gc29ja2V0KEFG
X0lORVQsU09DS19TVFJFQU0sMCk7DQoJaWYgKHNvY2tfZGVzY3JpcHRvcj09
LTEpDQoJew0KCQlwcmludGYoInNvY2tldDogRmFpbGVkIHRvIG9wZW4gc29j
a2V0LlxuIik7DQoJCXJldHVybiAtMTsNCgl9DQoNCgkvKiBiaW5kIHNvY2tl
dCAqLw0KCXNvY2tfYWRkcmVzcy5zaW5fZmFtaWx5ID0gQUZfSU5FVDsNCglz
b2NrX2FkZHJlc3Muc2luX3BvcnQgPSBodG9ucygyMDA5Nik7DQoJaWYgKGlu
ZXRfYXRvbigiMTI3LjAuMC4xIiwgJnNvY2tfYWRkcmVzcy5zaW5fYWRkcik9
PTApIA0KCXsNCgkJcHJpbnRmKCJiaW5kIHNvY2tldDogaW52YWxpZCBpcC9o
b3N0IG51bWJlclxuIik7DQoJCWNsb3NlKHNvY2tfZGVzY3JpcHRvcik7DQoJ
CXJldHVybiAtMTsNCgl9DQoJaWYgKGJpbmQoc29ja19kZXNjcmlwdG9yLCAo
c3RydWN0IHNvY2thZGRyICopICZzb2NrX2FkZHJlc3MsIHNpemVvZihzdHJ1
Y3Qgc29ja2FkZHJfaW4pKT09LTEpDQoJew0KCQlwcmludGYoImJpbmQ6IGZh
aWxlZCB0byBiaW5kIGFkZHJlc3MgdG8gc29ja2V0LlxuIik7DQoJCWNsb3Nl
KHNvY2tfZGVzY3JpcHRvcik7DQoJCXJldHVybiAtMTsNCgl9DQoNCgkvKiBl
c3RhYmxpc2ggY29ubmVjdGlvbiAqLw0KCWNvbm5lY3RfYWRkcmVzcy5zaW5f
ZmFtaWx5ID0gQUZfSU5FVDsNCgljb25uZWN0X2FkZHJlc3Muc2luX3BvcnQg
PSBodG9ucygyMDA2OSk7DQoJaWYgKGluZXRfYXRvbigiMTI3LjAuMC4xIiwg
JmNvbm5lY3RfYWRkcmVzcy5zaW5fYWRkcik9PTApIA0KCXsNCgkJcHJpbnRm
KCJjb25uZWN0OiBpbnZhbGlkIGlwL2hvc3QgbnVtYmVyXG4iKTsNCgkJY2xv
c2Uoc29ja19kZXNjcmlwdG9yKTsNCgkJcmV0dXJuIC0xOw0KCX0NCgkNCglp
ZiAoZ2V0c29ja25hbWUoc29ja19kZXNjcmlwdG9yLCAoc3RydWN0IHNvY2th
ZGRyICopJnNvY2tfYWRkcmVzcywgKHNvY2tsZW5fdCopc2l6ZW9mKHN0cnVj
dCBzb2NrYWRkcl9pbikpPT0tMSkNCgl7DQoJCXByaW50ZigiZ2V0c29ja25h
bWU6IGFkZHJlc3MgcmVzb2x1dGlvbiBmYWlsdXJlICAgICBSZWFzb246ICIp
Ow0KCQlzd2l0Y2ggKGVycm5vKSB7DQoJCQljYXNlIEVCQURGOg0KCQkJCXBy
aW50ZigiRUJBREZcblxuIik7DQoJCQkJYnJlYWs7DQoJCQljYXNlIEVOT1RT
T0NLOg0KCQkJCXByaW50ZigiRU5PVFNPQ0tcblxuIik7DQoJCQkJYnJlYWs7
DQoJCQljYXNlIEVOT0JVRlM6DQoJCQkJcHJpbnRmKCJFTk9CVUZTXG5cbiIp
Ow0KCQkJCWJyZWFrOw0KCQkJY2FzZSBFRkFVTFQ6DQoJCQkJcHJpbnRmKCJF
RkFVTFRcblxuIik7DQoJCQkJYnJlYWs7DQoJCQlkZWZhdWx0Og0KCQkJCXBy
aW50ZigiVU5LTk9XTiBFUlJPUlxuXG4iKTsNCgkJCQlicmVhazsNCgkJCX0N
Ci8qCQljbG9zZShzb2NrX2Rlc2NyaXB0b3IpOw0KCQlyZXR1cm4gLTE7DQoq
Lwl9DQoNCglwcmludGYoImNsaWVudDogc3VjY2Vzc1xuIFNvY2tldCBpbmZv
OlxuTG9jYWw6IEFkZHJlc3MgJXMgUG9ydCAlaVxuUmVtb3RlOiBBZGRyZXNz
ICVzIFBvcnQgJWlcbiIsIGluZXRfbnRvYShzb2NrX2FkZHJlc3Muc2luX2Fk
ZHIpLCBudG9ocyhzb2NrX2FkZHJlc3Muc2luX3BvcnQpLCBpbmV0X250b2Eo
Y29ubmVjdF9hZGRyZXNzLnNpbl9hZGRyKSwgbnRvaHMoY29ubmVjdF9hZGRy
ZXNzLnNpbl9wb3J0KSk7DQoJDQoJaWYgKGNvbm5lY3Qoc29ja19kZXNjcmlw
dG9yLCAoc3RydWN0IHNvY2thZGRyICopICZjb25uZWN0X2FkZHJlc3MsIHNp
emVvZihzdHJ1Y3Qgc29ja2FkZHJfaW4pKT09LTEpDQoJew0KCQlwcmludGYo
ImNvbm5lY3Q6IHVuYWJsZSB0byBlc3RhYmxpc2ggY29ubmVjdGlvblxuIik7
DQoJCWNsb3NlKHNvY2tfZGVzY3JpcHRvcik7DQoJCXJldHVybiAtMTsNCgl9
DQoJDQoJc2xlZXAoMSk7DQoJcmVzcG9uc2U9KGNoYXIqKWNhbGxvYygxLDEw
MjQpOw0KCWlmIChyZWN2KHNvY2tfZGVzY3JpcHRvcixyZXNwb25zZSwxMDIz
LDApPT0tMSkNCgl7DQoJCXByaW50ZigicmVjdjogc29ja2V0IGlvIGZhaWx1
cmVcbiIpOw0KCQljbG9zZShzb2NrX2Rlc2NyaXB0b3IpOw0KCQlyZXR1cm4g
LTE7DQoJfQ0KCXNsZWVwKDEpOw0KCXByaW50ZigiXG5cbiVzXG4iLHJlc3Bv
bnNlKTsNCgkJDQoJLyogY2xlYW4gYW5kIGNsb3NlICovCQ0KCWNsb3NlKHNv
Y2tfZGVzY3JpcHRvcik7DQoJcmV0dXJuIDA7DQp9DQo=
--8323328-1707146190-910408192=:12744
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="server.c"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.05.9811062009521.12744@localhost.localdomain>
Content-Description:
Content-Disposition: attachment; filename="server.c"
Lyogc2VydmVyLmMgKi8NCg0KI2luY2x1ZGUgPHN0ZGlvLmg+DQojaW5jbHVk
ZSA8c3RkbGliLmg+DQojaW5jbHVkZSA8c3lzL3NvY2tldC5oPg0KI2luY2x1
ZGUgPG5ldGluZXQvaW4uaD4NCiNpbmNsdWRlIDxhcnBhL2luZXQuaD4NCiNp
bmNsdWRlIDxzeXMvdHlwZXMuaD4NCiNpbmNsdWRlIDxzdHJpbmcuaD4NCg0K
I2RlZmluZSBUSEVfTVNHICJzdWNjZXNzZnVsbCBjb25uZWN0aW9uIHRvIHNl
cnZlciINCg0KaW50IHNvY2tfZGVzY3JpcHRvciwgY29ubmVjdF9kZXNjcmlw
dG9yOw0Kc3RydWN0IHNvY2thZGRyX2luCXNvY2tfYWRkcmVzcywgY29ubmVj
dF9hZGRyZXNzOw0KDQoNCmludCBtYWluKHZvaWQpIA0Kew0KCS8qIG9wZW4g
c29ja2V0ICovDQoJc29ja19kZXNjcmlwdG9yID0gc29ja2V0KEFGX0lORVQs
U09DS19TVFJFQU0sMCk7DQoJaWYgKHNvY2tfZGVzY3JpcHRvcj09LTEpDQoJ
ew0KCQlwcmludGYoInNvY2tldDogRmFpbGVkIHRvIG9wZW4gc29ja2V0Llxu
Iik7DQoJCXJldHVybiAtMTsNCgl9DQoNCgkvKiBiaW5kIHNvY2tldCAqLw0K
CXNvY2tfYWRkcmVzcy5zaW5fZmFtaWx5ID0gQUZfSU5FVDsNCglzb2NrX2Fk
ZHJlc3Muc2luX3BvcnQgPSBodG9ucygyMDA2OSk7DQoJaWYgKGluZXRfYXRv
bigiMTI3LjAuMC4xIiwgJnNvY2tfYWRkcmVzcy5zaW5fYWRkcik9PTApIA0K
CXsNCgkJcHJpbnRmKCJiaW5kOiBpbnZhbGlkIGlwL2hvc3QgbnVtYmVyXG4i
KTsNCgkJY2xvc2Uoc29ja19kZXNjcmlwdG9yKTsNCgkJcmV0dXJuIC0xOw0K
CX0NCglpZiAoYmluZChzb2NrX2Rlc2NyaXB0b3IsIChzdHJ1Y3Qgc29ja2Fk
ZHIgKikgJnNvY2tfYWRkcmVzcywgc2l6ZW9mKHN0cnVjdCBzb2NrYWRkcl9p
bikpPT0tMSkNCgl7DQoJCXByaW50ZigiYmluZDogZmFpbGVkIHRvIGJpbmQg
YWRkcmVzcyB0byBzb2NrZXQuXG4iKTsNCgkJY2xvc2Uoc29ja19kZXNjcmlw
dG9yKTsNCgkJcmV0dXJuIC0xOw0KCX0NCg0KCXByaW50Zigic2VydmVyOiBz
dWNjZXNzXG5zdGFydGluZyBzZXJ2ZXIuLlxuIik7DQoJDQoJLyogc2V0IGxp
c3RlbiBvbiBzb2NrZXQgKi8NCglpZiAobGlzdGVuKHNvY2tfZGVzY3JpcHRv
ciwgNSk9PS0xKQ0KCXsNCgkJcHJpbnRmKCJsaXN0ZW46IGZhaWxlZCB0byBz
ZXQgc2VydmVyIHNvY2tldC5cbiIpOw0KCQljbG9zZShzb2NrX2Rlc2NyaXB0
b3IpOw0KCQlyZXR1cm4gLTE7DQoJfQ0KCQ0KCXByaW50Zigic2VydmVyOiB3
aWF0aW5nIGZvciBjbGllbnQgY29ubmVjdFxuIik7DQoJDQoJaWYgKChjb25u
ZWN0X2Rlc2NyaXB0b3I9YWNjZXB0KHNvY2tfZGVzY3JpcHRvciwgKHN0cnVj
dCBzb2NrYWRkciopJmNvbm5lY3RfYWRkcmVzcywgKHZvaWQqKSgoaW50KShz
aXplb2Yoc3RydWN0IHNvY2thZGRyX2luKSkpICkpPT0tMSkNCgl7DQoJCXBy
aW50ZigiYWNjZXB0OiBzZXJ2ZXIvc29ja2V0IGZhaWx1cmUuXG4iKTsNCgkJ
Y2xvc2Uoc29ja19kZXNjcmlwdG9yKTsNCgkJcmV0dXJuIC0xOw0KCX0NCgkN
CglwcmludGYoInNlcnZlcjogY29ubmVjdGlvbiBlc3RhYmxpc2hlZCAoJXMg
JWkpXG4iLCBpbmV0X250b2EoY29ubmVjdF9hZGRyZXNzLnNpbl9hZGRyKSwg
bnRvaHMoY29ubmVjdF9hZGRyZXNzLnNpbl9wb3J0KSk7DQoNCglpZiAoc2Vu
ZChjb25uZWN0X2Rlc2NyaXB0b3IsVEhFX01TRyxzdHJsZW4oVEhFX01TRyks
MCk9PS0xKQ0KCXsNCgkJcHJpbnRmKCJzZW5kOiBjb21tdW5pY2F0aW9uIGZh
aWx1cmVcbiIpOw0KCQljbG9zZShzb2NrX2Rlc2NyaXB0b3IpOw0KCQljbG9z
ZShjb25uZWN0X2Rlc2NyaXB0b3IpOw0KCQlyZXR1cm4gLTE7DQoJfQ0KCQ0K
CXByaW50Zigic2VydmVyOiBkYXRhIHNlbnQsIGtpbGxpbmcgY29ubmVjdGlv
blxuIik7DQoNCgkvKiBjbGVhbiBhbmQgY2xvc2UgKi8JDQoJY2xvc2UoY29u
bmVjdF9kZXNjcmlwdG9yKTsNCglzbGVlcCg0KTsNCgljbG9zZShzb2NrX2Rl
c2NyaXB0b3IpOw0KCXJldHVybiAwOw0KfQ0K
--8323328-1707146190-910408192=:12744--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/