Home/ Questions/Q 6557041
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T13:01:28+00:00

I am linking liboauth library with my application, from the core dump file it

  • 0

I am linking liboauth library with my application, from the core dump file it is showing from oauth_sign_array2 it started using invalid pointer which is getting called inside that lib only

Below is bt for the application 

#0  0x000000000070c3cb in lh_retrieve ()
#1  0x000000000070db4b in int_thread_get_item ()
#2  0x000000000070eb6a in ERR_get_state ()
#3  0x000000000070f509 in ERR_set_mark ()
#4  0x000000000077bce0 in engine_table_select ()
#5  0x000000000070f829 in EVP_DigestInit_ex ()
#6  0x00000000006f39dd in HMAC_Init_ex ()
#7  0x00000000006f3ed1 in HMAC ()
#8  0x0000000000528bee in oauth_sign_hmac_sha1_raw (
    m=0x7fe88c101230 "<one secret url >"..., ml=366, 
    k=0x7fe88c03a150 "anonymous&nhjLEo8rcuvaqyL2ippxfAD2", kl=34)
    at ./src/liboauth/hash5.c:314
#9  0x0000000000527b0d in oauth_sign_array2_process (argcp=0x7fe892ffcb34, 
    argvp=0x7fe892ffcb38, postargs=<value optimized out>, method=OA_HMAC, 
    http_method=<value optimized out>, c_key=<value optimized out>, 
    c_secret=0x27b2230 "anonymous", 
    t_key=0x27b2710 "<token key>", 
    t_secret=0x2778e50 "<token secret>")
    at ./src/liboauth/oauth.c:785
#10 0x0000000000527c1e in oauth_sign_array2 (argcp=0x8688170, 
    argvp=0x7fe892ffc060, postargs=0x20, method=495, 
    http_method=0x20 <Address 0x20 out of bounds>, 
    c_key=0x101010101010101 <Address 0x101010101010101 out of bounds>, 
    c_secret=0x1 <Address 0x1 out of bounds>, 
    t_key=0x1 <Address 0x1 out of bounds>, 
    t_secret=0x1 <Address 0x1 out of bounds>) at ./src/liboauth/oauth.c:812
#11 0x0000000000527d0d in oauth_sign_url2 (url=<value optimized out>, 
    postargs=0x7fe892ffcb88, method=OA_HMAC, http_method=0x7b89c7 "GET", 
    c_key=0x277cbc0 "anonymous", c_secret=0x27b2230 "anonymous", 
    t_key=0x1 <Address 0x1 out of bounds>,

info registers give me 

rax            0x1      1
rbx            0x6e65637365643d72       7954873664093306226
rcx            0x1ef    495
rdx            0x20     32
rsi            0x7fe892ffc060   140636875374688
rdi            0x8688170        141066608
rbp            0x270b480        0x270b480
rsp            0x7fe892ffbff0   0x7fe892ffbff0
r8             0x20     32
r9             0x101010101010101        72340172838076673
r10            0x416678707069324c       4712586484407415372
r11            0x7fe89a15e0ae   140636994265262
r12            0x7fe8700b8208   140636288942600
r13            0x67ecf76fde2e0  1828279379944160
r14            0x7fe892ffc060   140636875374688
r15            0x70da00 7395840
rip            0x70c3cb 0x70c3cb <lh_retrieve+139>
eflags         0x10202  [ IF RF ]
cs             0xe033   57395
ss             0xe02b   57387
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0
fctrl          0x37f    895
fstat          0x0      0
ftag           0xffff   65535
fiseg          0x0      0
fioff          0x6316b9 6493881
foseg          0x7fe8   32744
fooff          0x92ffc078       -1828732808
fop            0x55c    1372
mxcsr          0x1fa0   [ PE IM DM ZM OM UM PM ]
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    People are voting to close, but personally, in the right sort of mood I don’t mind a little detective work. 🙂

    Per chat with Vivek the faulting instruction in lh_retrieve was:

    cmp %r13,0x10(%rbx)

    Per above rbx is 0x6e65637365643d72 which doesn’t look anything like a valid pointer or have any resemblance to the other pointers we see on the stack.

    When I google some of the functions on the stack, it looks like OpenSSL routines for generating hashes, then routine looking at a hash table structure… Probably some code, possibly Vivek’s, has corrupted the hash table’s structure by overrunning a buffer somewhere. It might help to show us more code. 🙂

    • 0