This sounds like a use-after-free. That memory is either poisoned by
the allocator, or re-allocated and used by something that memset() it.
You can try running under valgrind, if it's fast enough, or you can try
backporting the ASAN additions from these commits:
1b48c0237c10c48d33840ab278d5cf0c2a8a8e4a
9c69aeb4c0f313650897d78590be4c07b41a8e40
Daniel
On 10/31/2017 10:45 AM, Sachin Punadikar wrote:
William,
You are right, gsh_calloc is getting invoked (even for 2.3 code).
Interestingly for the core we got in testing, has almost all the fields
filled with 0xFF. So wondering is it something to do with underneath
glibc or RHEL in general.
Here is the gdb o/p indicating the same.
(gdb) p reqdata->r_u.req.svc
$7 = {rq_prog = 4294967295, rq_vers = 4294967295, rq_proc = 4294967295,
rq_cred = {oa_flavor = -1,
oa_base = 0xffffffffffffffff <Address 0xffffffffffffffff out of
bounds>, oa_length = 4294967295},
rq_clntcred = 0x7f183c0a83e0, rq_xprt = 0x7f1932423830,
rq_clntname = 0xffffffffffffffff <Address 0xffffffffffffffff out of
bounds>,
rq_svcname = 0xffffffffffffffff <Address 0xffffffffffffffff out of
bounds>, rq_msg = 0x7f183c0a8020, rq_context = 0x0,
rq_u1 = 0xffffffffffffffff, rq_u2 = 0xffffffffffffffff, rq_cksum =
18446744073709551615, rq_xid = 4294967295, rq_verf = {
oa_flavor = -1, oa_base = 0xffffffffffffffff <Address
0xffffffffffffffff out of bounds>, oa_length = 4294967295},
rq_auth = 0xffffffffffffffff, rq_ap1 = 0xffffffffffffffff, rq_ap2 =
0xffffffffffffffff, rq_raddr = {ss_family = 65535,
__ss_align = 18446744073709551615, __ss_padding = '\377' <repeats
112 times>}, rq_daddr = {ss_family = 65535,
__ss_align = 18446744073709551615, __ss_padding = '\377' <repeats
112 times>}, rq_raddr_len = 0, rq_daddr_len = 0}
(gdb) p reqdata->r_u.req
$8 = {xprt = 0x7f1932423830, svc = {rq_prog = 4294967295, rq_vers =
4294967295, rq_proc = 4294967295, rq_cred = {
oa_flavor = -1, oa_base = 0xffffffffffffffff <Address
0xffffffffffffffff out of bounds>, oa_length = 4294967295},
rq_clntcred = 0x7f183c0a83e0, rq_xprt = 0x7f1932423830,
rq_clntname = 0xffffffffffffffff <Address 0xffffffffffffffff out of
bounds>,
rq_svcname = 0xffffffffffffffff <Address 0xffffffffffffffff out of
bounds>, rq_msg = 0x7f183c0a8020, rq_context = 0x0,
rq_u1 = 0xffffffffffffffff, rq_u2 = 0xffffffffffffffff, rq_cksum =
18446744073709551615, rq_xid = 4294967295,
rq_verf = {oa_flavor = -1, oa_base = 0xffffffffffffffff <Address
0xffffffffffffffff out of bounds>,
oa_length = 4294967295}, rq_auth = 0xffffffffffffffff, rq_ap1 =
0xffffffffffffffff, rq_ap2 = 0xffffffffffffffff,
rq_raddr = {ss_family = 65535, __ss_align = 18446744073709551615,
__ss_padding = '\377' <repeats 112 times>},
rq_daddr = {ss_family = 65535, __ss_align = 18446744073709551615,
__ss_padding = '\377' <repeats 112 times>},
rq_raddr_len = 0, rq_daddr_len = 0}, lookahead = {flags =
4294967295, read = 65535, write = 65535}, arg_nfs = {
arg_getattr3 = {object = {data = {data_len = 4294967295,
data_val = 0xffffffffffffffff <Address 0xffffffffffffffff out
of bounds>}}}, arg_setattr3 = {object = {data = {
data_len = 4294967295, data_val = 0xffffffffffffffff <Address
0xffffffffffffffff out of bounds>}},
new_attributes = {mode = {set_it = -1, set_mode3_u = {mode =
4294967295}}, uid = {set_it = -1, set_uid3_u = {
uid = 4294967295}}, gid = {set_it = -1, set_gid3_u = {gid =
4294967295}}, size = {set_it = -1, set_size3_u = {
size = 18446744073709551615}}, atime = {
set_it = (SET_TO_SERVER_TIME | SET_TO_CLIENT_TIME | unknown:
4294967292), set_atime_u = {atime = {
tv_sec = 4294967295, tv_nsec = 4294967295}}}, mtime = {
set_it = (SET_TO_SERVER_TIME | SET_TO_CLIENT_TIME | unknown:
4294967292), set_mtime_u = {mtime = {
tv_sec = 4294967295, tv_nsec = 4294967295}}}}, guard =
{check = -1, sattrguard3_u = {obj_ctime = {
tv_sec = 4294967295, tv_nsec = 4294967295}}}}, arg_lookup3
= {what = {dir = {data = {data_len = 4294967295,
data_val = 0xffffffffffffffff <Address 0xffffffffffffffff
out of bounds>}},
name = 0xffffffffffffffff <Address 0xffffffffffffffff out of
bounds>}}, arg_access3 = {object = {data = {
data_len = 4294967295, data_val = 0xffffffffffffffff <Address
0xffffffffffffffff out of bounds>}},
access = 4294967295}, arg_readlink3 = {symlink = {data =
{data_len = 4294967295,
data_val = 0xffffffffffffffff <Address 0xffffffffffffffff out
of bounds>}}}, arg_read3 = {file = {data = {
data_len = 4294967295, data_val = 0xffffffffffffffff <Address
0xffffffffffffffff out of bounds>}},
offset = 18446744073709551615, count = 4294967295}, arg_write3 =
{file = {data = {data_len = 4294967295,
data_val = 0xffffffffffffffff <Address 0xffffffffffffffff out
of bounds>}}, offset = 18446744073709551615,
count = 4294967295, stable = (DATA_SYNC | FILE_SYNC | unknown:
4294967292), data = {data_len = 4294967295,
data_val = 0xffffffffffffffff <Address 0xffffffffffffffff out
of bounds>}}, arg_create3 = {where = {dir = {data = {
data_len = 4294967295, data_val = 0xffffffffffffffff
<Address 0xffffffffffffffff out of bounds>}},
name = 0xffffffffffffffff <Address 0xffffffffffffffff out of
bounds>}, how = {
mode = (GUARDED | EXCLUSIVE | unknown: 4294967292),
createhow3_u = {obj_attributes = {mode = {set_it = -1,
---Type <return> to continue, or q <return> to quit---
Let me know if any one observed this kind of behavior.
Thanks in advance.
On Mon, Oct 30, 2017 at 9:38 PM, William Allen Simpson
<william.allen.simp...@gmail.com
<mailto:william.allen.simp...@gmail.com>> wrote:
On 10/27/17 7:56 AM, Sachin Punadikar wrote:
Ganesha 2.3 got segfault with below :
[...]
After analyzing the core and related code found that - In
"thr_decode_rpc_request" function, if call to SVC_RECV fails,
then free_nfs_request is invoked to free the resources. But so
far one of the field "reqdata->r_u.req.svc.rq_auth" is not
initialized nor allocated, which is leading to segfault.
The code in this area is same for Ganesha 2.3 and 2.5.
I have created below patch to overcome this issue. Please review
and if suitable merge with Ganesha 2.5 stable.
https://github.com/sachinpunadikar/nfs-ganesha/commit/91baffa8bd197c78eff106f42927a370155ae6b4
<https://github.com/sachinpunadikar/nfs-ganesha/commit/91baffa8bd197c78eff106f42927a370155ae6b4>
While your code should be harmless, at least in V2.5 that is already
initialized with gsh_calloc(). So it should already be NULL.
The answer of course as always is to upgrade.... There are a lot of
fixes in V2.4 and V2.5, the current stable branch!
--
with regards,
Sachin Punadikar
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
