Bug #4824

vty comand "show sndcp" can cause SEGV in vty_dump_sne()

Added by keith about 1 month ago. Updated about 1 month ago.

Target version:
Start date:
Due date:
% Done:


Spec Reference:


(gdb) bt
#0  vty_dump_sne (vty=0x558339e52010, sne=0x558339e57360) at gprs_sndcp_vty.c:44
#1  0x000055833916afb7 in show_sndcp (self=0x55833939aac0 <show_sndcp_cmd>, vty=0x558339e52010, argc=0, argv=0x7ffcb165cf50) at gprs_sndcp_vty.c:60                    


#1 Updated by keith about 1 month ago

static void vty_dump_sne(struct vty *vty, struct gprs_sndcp_entity *sne)
    vty_out(vty, " TLLI %08x SAPI=%u NSAPI=%u:%s",
        sne->lle->llme->tlli, sne->lle->sapi, sne->nsapi, VTY_NEWLINE);
    vty_out(vty, "  Defrag: npdu=%u highest_seg=%u seg_have=0x%08x tot_len=%u%s",
        sne->defrag.npdu, sne->defrag.highest_seg, sne->defrag.seg_have,
        sne->defrag.tot_len, VTY_NEWLINE);
(gdb) p sne->lle->llme
$6 = (struct gprs_llc_llme *) 0x0

#2 Updated by keith about 1 month ago

Can anyone shed any light on if this is an expected condition, and should be fixed by simply checking before access, of it it betrays an underlying bug?

#3 Updated by laforge about 1 month ago

I don't think this is expected. The LLME is the LLC Management Entity. So you have LLC Enties with out its related management.

I can currently only find code that sets lle->llme during lle_init(), but I cannot find any other place (which would set it to NULL)

#4 Updated by laforge about 1 month ago

maybe the entire 'lle' is gone, and the reference from the sne (sndcp entity) is already problematic? Can you print the lle in the debugger?

#5 Updated by laforge about 1 month ago

also, the lle are an array inside the llme. So it's impossible that a LLE has no LLME. The back-pointer is not written to anywhere, so I think indeed the sne->lle pointer may be stale, or the entire sne.

#6 Updated by laforge about 1 month ago

so the SNE is free'd via sndcp_sm_deactivate_ind(), which happens at PDP context termination.

the LLME with all its LLEs is free'd via gprs_llgmm_assign(..., new_tlli=TLLI_UNASSIGNED)

maybe there are other situations in whihc the LLME is freed, where the SNE is not free'd before? As all the gprs_llgmm_assign() calls originate from gprs_gmm, it may be in the path for GGSN side PDP context termination from sgsn_libgtp.c -> sndcp_sm_deactivate_ind() where the SNDCP entity is not free'd.

I'll drop looking at it further here.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)