Fix SIGSEGV when cur_req is null pointer #45

JoeyJiao · 2019-11-28T12:37:16Z

No description provided.

crash-utility · 2019-11-28T13:05:21Z

Can you show me how/where this can happen (i.e. where pc->cur_req can be NULL)?

crash-utility · 2019-11-28T16:27:51Z

Note: theoretically this should never happen, but if it does, I would actually prefer that it generate a SIGSEGV. I need to see how it's possible, and then preferably fix it at its source instead of papering it over with a return TRUE, which is not what is expected from the call site in the gdb code if the read request fails.

JoeyJiao · 2019-11-29T01:21:09Z

The problem happens when I was trying to do whatis(sym).ctype in epython for all kernel symbols.

Program received signal SIGSEGV, Segmentation fault.
gdb_readmem_callback (addr=18446743524119739464, buf=0x7fffffffc360, len=8, write=0) at gdb_interface.c:834
warning: Source file is more recent than executable.
834 if (!pc->cur_req)
(gdb) bt
#0 gdb_readmem_callback (addr=18446743524119739464, buf=0x7fffffffc360, len=8, write=0) at gdb_interface.c:834
#1 0x00005555558bd92b in target_read_memory (memaddr=memaddr@entry=18446743524119739464, myaddr=, len=) at target.c:1784
#2 0x00005555559022f9 in read_memory (memaddr=18446743524119739464, myaddr=, len=) at corefile.c:221
#3 0x000055555590351f in execute_stack_op (ctx=ctx@entry=0x5555570370b0, op_ptr=0x7fffe973fa25 "1\036\060"\237<\253\316\001", op_ptr@entry=0x7fffe973fa1b "\003H\374\344\t\200\377\377\377\006\061\036\060"\237<\253\316\001",
op_end=op_end@entry=0x7fffe973fa2a "<\253\316\001") at dwarf2expr.c:1045
#4 0x0000555555904884 in dwarf_expr_eval (ctx=ctx@entry=0x5555570370b0, addr=addr@entry=0x7fffe973fa1b "\003H\374\344\t\200\377\377\377\006\061\036\060"\237<\253\316\001", len=len@entry=15) at dwarf2expr.c:364
#5 0x00005555559056a4 in dwarf2_evaluate_loc_desc_full (type=0x55555b8aefa0, frame=0x0, data=0x7fffe973fa1b "\003H\374\344\t\200\377\377\377\006\061\036\060"\237<\253\316\001", size=15, per_cu=0x555556eb9830, byte_offset=0) at dwarf2loc.c:2167
#6 0x000055555583b0dc in default_read_var_value (var=0x55555bd18370, frame=0x0) at findvar.c:586
#7 0x000055555584aee6 in evaluate_subexp_standard (expect_type=expect_type@entry=0x0, exp=exp@entry=0x5555998488d0, pos=pos@entry=0x7fffffffc9cc, noside=, noside@entry=EVAL_AVOID_SIDE_EFFECTS) at eval.c:767
#8 0x00005555559220bc in evaluate_subexp_c (expect_type=0x0, exp=0x5555998488d0, pos=0x7fffffffc9cc, noside=EVAL_AVOID_SIDE_EFFECTS) at c-lang.c:708
#9 0x000055555584a425 in evaluate_subexp (noside=EVAL_AVOID_SIDE_EFFECTS, pos=0x7fffffffc9cc, exp=, expect_type=0x0) at eval.c:157
#10 evaluate_type (exp=) at eval.c:157
#11 0x00007fffe6bff7bc in py_gdb_whatis (self=, args=) at gdbspec.c:486
#12 0x00007fffe6c0a117 in cfunction_call_varargs (func=0x7ffff7282cc0, args=, kwargs=) at Objects/call.c:757
#13 0x00007fffe6c0a7e7 in _PyObject_MakeTpCall (callable=0x7ffff7282cc0, args=, nargs=, keywords=0x0) at Objects/call.c:159
#14 0x00007fffe6bf1903 in _PyObject_Vectorcall (kwnames=0x0, nargsf=, args=, callable=0x7ffff7282cc0) at ./Include/cpython/abstract.h:125
#15 _PyObject_Vectorcall (kwnames=, nargsf=, args=, callable=) at ./Include/cpython/abstract.h:115
#16 call_function (tstate=tstate@entry=0x5555564a9260, pp_stack=pp_stack@entry=0x7fffffffcb88, oparg=, kwnames=kwnames@entry=0x0) at Python/ceval.c:4987
#17 0x00007fffe6bf89c1 in _PyEval_EvalFrameDefault (f=, throwflag=) at Python/ceval.c:3469
#18 0x00007fffe6bf056b in function_code_fastcall (co=, args=, nargs=1, globals=) at Objects/call.c:283
#19 0x00007fffe6bf187d in _PyObject_Vectorcall (kwnames=, nargsf=, args=, callable=) at ./Include/cpython/abstract.h:123
#20 call_function (tstate=tstate@entry=0x5555564a9260, pp_stack=pp_stack@entry=0x7fffffffcd70, oparg=, kwnames=kwnames@entry=0x0) at Python/ceval.c:4987
#21 0x00007fffe6bf4722 in _PyEval_EvalFrameDefault (f=, throwflag=) at Python/ceval.c:3500
#22 0x00007fffe6bf056b in function_code_fastcall (co=, args=, nargs=1, globals=) at Objects/call.c:283
#23 0x00007fffe6bf187d in _PyObject_Vectorcall (kwnames=, nargsf=, args=, callable=) at ./Include/cpython/abstract.h:123
#24 call_function (tstate=tstate@entry=0x5555564a9260, pp_stack=pp_stack@entry=0x7fffffffcf50, oparg=, kwnames=kwnames@entry=0x0) at Python/ceval.c:4987
#25 0x00007fffe6bf4722 in _PyEval_EvalFrameDefault (f=, throwflag=) at Python/ceval.c:3500
#26 0x00007fffe6bf056b in function_code_fastcall (co=, args=, nargs=1, globals=) at Objects/call.c:283
#27 0x00007fffe6bf187d in _PyObject_Vectorcall (kwnames=, nargsf=, args=, callable=) at ./Include/cpython/abstract.h:123
#28 call_function (tstate=tstate@entry=0x5555564a9260, pp_stack=pp_stack@entry=0x7fffffffd130, oparg=, kwnames=kwnames@entry=0x0) at Python/ceval.c:4987
#29 0x00007fffe6bf4722 in _PyEval_EvalFrameDefault (f=, throwflag=) at Python/ceval.c:3500
#30 0x00007fffe6ca8f4b in _PyEval_EvalCodeWithName (_co=_co@entry=0x7ffff7a13870, globals=globals@entry=0x7ffff7a98880, locals=locals@entry=0x7ffff7a98880, args=args@entry=0x0, argcount=argcount@entry=0, kwnames=kwnames@entry=0x0, kwargs=0x0, kwcount=0, kwstep=2,
defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0) at Python/ceval.c:4298
#31 0x00007fffe6ca92ce in PyEval_EvalCodeEx (_co=_co@entry=0x7ffff7a13870, globals=globals@entry=0x7ffff7a98880, locals=locals@entry=0x7ffff7a98880, args=args@entry=0x0, argcount=argcount@entry=0, kws=kws@entry=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0,
closure=0x0) at Python/ceval.c:4327
#32 0x00007fffe6ca92fb in PyEval_EvalCode (co=co@entry=0x7ffff7a13870, globals=globals@entry=0x7ffff7a98880, locals=locals@entry=0x7ffff7a98880) at Python/ceval.c:718
#33 0x00007fffe6bfac96 in run_fromzip (progname=0x7fffffffd3a0 "progs/showfops", zipfilename=zipfilename@entry=0x555557800f70 "/usr/lib64/crash/extensions/mpykdump.so") at epython.c:474
#34 0x00007fffe6bfbabb in epython_execute_prog (argc=1, argc@entry=2, argv=argv@entry=0x555557783f20, quiet=quiet@entry=0) at epython.c:749
#35 0x00007fffe6bfc81a in epython_subcommand () at functions.c:1309
#36 0x0000555555648dfb in exec_command () at main.c:879
#37 0x0000555555648bdb in main_loop () at main.c:826
#38 0x0000555555898773 in captured_command_loop (data=data@entry=0x0) at main.c:258
#39 0x0000555555896e7a in catch_errors (func=func@entry=0x555555898760 <captured_command_loop>, func_args=func_args@entry=0x0, errstring=errstring@entry=0x555555ae383f "", mask=mask@entry=6) at exceptions.c:557
#40 0x0000555555899836 in captured_main (data=data@entry=0x7fffffffd9f0) at main.c:1064
#41 0x0000555555896e7a in catch_errors (func=func@entry=0x555555898a40 <captured_main>, func_args=func_args@entry=0x7fffffffd9f0, errstring=errstring@entry=0x555555ae383f "", mask=mask@entry=6) at exceptions.c:557
#42 0x0000555555899bd1 in gdb_main (args=0x7fffffffd9f0) at main.c:1079
#43 gdb_main_entry (argc=, argv=) at main.c:1099
#44 0x00005555557032ca in gdb_main_loop (argc=2, argv=0x7fffffffdb78) at gdb_interface.c:76
#45 0x00005555556488a6 in main (argc=4, argv=0x7fffffffdb78) at main.c:707
*(gdb) print 18446743524119739464
Cannot access memory at address 0xffffff8009e4fc48
(gdb) print pc->cur_req
$1 = (struct gnu_request *) 0x0
(gdb) p pc
$2 = (struct program_context *) 0x555555c89160 <program_context>

JoeyJiao · 2019-11-29T01:29:22Z

My symbol address is like this: ffffffa9a7c80000 (T) _text,
kaslr offset is 0x000000299fc00000, so 0xffffff8009e4fc48 should be FFFFFFA9A9A4FC48.
In sym list, it is ffffffa9a9a4fc48 (r) swiotlb.

JoeyJiao · 2019-11-29T01:33:12Z

(gdb) info args
addr = 18446743524119739464
buf = 0x7fffffffc360
len = 8
write = 0

JoeyJiao · 2019-11-29T01:34:05Z

(gdb) info registers
rax 0x0 0
rbx 0x55556f0cfd30 93825423703344
rcx 0x0 0
rdx 0x8 8
rsi 0x7fffffffc360 140737488339808
rdi 0xffffff8009e4fc48 -549589812152
rbp 0x7fffffffc330 0x7fffffffc330
rsp 0x7fffffffc2e0 0x7fffffffc2e0
r8 0x7fffffffc360 140737488339808
r9 0xffffff8009e4fc48 -549589812152
r10 0x0 0
r11 0x7 7
r12 0x7fffe973fa25 140737110080037
r13 0x7fffe973fa25 140737110080037
r14 0x5555570370b0 93825020424368
r15 0x6 6
rip 0x5555557056c2 0x5555557056c2 <gdb_readmem_callback+52>
eflags 0x10246 [ PF ZF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0

JoeyJiao · 2019-11-29T01:48:27Z

crash64> p swiotlb
swiotlb = $1 = 0

JoeyJiao · 2019-11-29T02:08:52Z

crash64> dis swiotlb
0xffffffa9a9a4fc48 : .inst 0x00000000 ; undefined

crash-utility · 2019-11-29T13:46:13Z

Sorry, I'm not familiar with mypkdump, but that command does end up using target_read_memory() in an unexpected way. But with your patch, you are returning TRUE without reading anything, so that makes little sense.

crash-utility · 2019-11-29T14:14:26Z

At a minimum, if there is no pc->cur_req then memtype and the readflags would need to be initialized, and then a readmem() issued. Presumably KVADDR and RETURN_ON_ERROR would suffice?
Interesting that this has never come up before, either from the author of mypkdump, or by our (Red Hat) support staff, who do utilize that extension module.

crash-utility · 2019-11-30T12:17:57Z

Try this:

--- a/gdb_interface.c 2018-11-07 12:00:00.000000000 -0500
+++ b/gdb_interface.c 2019-11-30 07:15:09.971483590 -0500
@@ -831,6 +831,11 @@ gdb_readmem_callback(ulong addr, void *b
if (write)
return FALSE;

```
  if (!(pc->cur_req)) {
```

          return(readmem(addr, KVADDR, buf, len,

                  "gdb_readmem_callback", RETURN_ON_ERROR));

```
  }
```

  if (pc->cur_req->flags & GNU_NO_READMEM)
          return TRUE;

crash-utility · 2019-11-30T12:19:46Z

Well, that patch didn't display as I had entered it -- so guess I don't know how to properly show a patch in these comments, but you get the idea...

crash-utility · 2019-12-01T19:20:22Z

e13b51a

Fix SIGSEGV when cur_req is null pointer

a3cd9c1

crash-utility closed this Dec 1, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix SIGSEGV when cur_req is null pointer #45

Fix SIGSEGV when cur_req is null pointer #45

JoeyJiao commented Nov 28, 2019

crash-utility commented Nov 28, 2019

crash-utility commented Nov 28, 2019

JoeyJiao commented Nov 29, 2019

JoeyJiao commented Nov 29, 2019 •

edited

Loading

JoeyJiao commented Nov 29, 2019

JoeyJiao commented Nov 29, 2019

JoeyJiao commented Nov 29, 2019

JoeyJiao commented Nov 29, 2019

crash-utility commented Nov 29, 2019

crash-utility commented Nov 29, 2019

crash-utility commented Nov 30, 2019

crash-utility commented Nov 30, 2019

crash-utility commented Dec 1, 2019

Fix SIGSEGV when cur_req is null pointer #45

Fix SIGSEGV when cur_req is null pointer #45

Conversation

JoeyJiao commented Nov 28, 2019

crash-utility commented Nov 28, 2019

crash-utility commented Nov 28, 2019

JoeyJiao commented Nov 29, 2019

JoeyJiao commented Nov 29, 2019 • edited Loading

JoeyJiao commented Nov 29, 2019

JoeyJiao commented Nov 29, 2019

JoeyJiao commented Nov 29, 2019

JoeyJiao commented Nov 29, 2019

crash-utility commented Nov 29, 2019

crash-utility commented Nov 29, 2019

crash-utility commented Nov 30, 2019

crash-utility commented Nov 30, 2019

crash-utility commented Dec 1, 2019

JoeyJiao commented Nov 29, 2019 •

edited

Loading