Summary: | ASTERISK-14078: [patch] Data truncated in ooh323_request because of sizeof incorrect usage | ||
Reporter: | Igor Goncharovsky (igorg) | Labels: | |
Date Opened: | 2009-05-06 23:35:14 | Date Closed: | 2009-09-08 13:25:36 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Addons/chan_ooh323 |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) chan_ooh323_cpy_string_fix.c.v1.diff | |
Description: | On form user reported that destination passed via Dial to OOH323 channel. Issue caused by improper sizeof usage: data passed to ooh323_request is void* and not an static array. ****** ADDITIONAL INFORMATION ****** -- Executing [7160@default:1] Dial("SIP/6073-093e0a80", "OOH323/7160") in new stack --- ooh323_request - data 7160 format 0x2 (gsm) --- ooh323_alloc +++ ooh323_alloc --- find_peer "716" +++ find_peer "716" --- ooh323_new - 716 +++ h323_new | ||
Comments: | By: cmaj (cmaj) 2009-07-13 10:52:07 How can this be against trunk? When chan_ooh323 was moved into addons/ it was left broken because of the underlying RTP->RTP_ENGINE changes. By: Leif Madsen (lmadsen) 2009-08-20 14:45:05 cmaj: this issue was submitted in May, which I suspect was before that change. Anyone have any suggestions as to how I should handle this issue? Should it still be open, or is there anything that can be done here? By: Igor Goncharovsky (igorg) 2009-09-06 01:25:10 Seems no changes from May. Problem here in using ast_copy_string with array length calculated as sizeof(data). data in this function is void*, when in others similar places sizeof taken from array with defined length. In this situation always one byte copied, ignoring other string symbols. I have not know if it broken some functionality, but it is buggy string length anyway. By: Igor Goncharovsky (igorg) 2009-09-06 01:30:35 It is for trunk. As for reworked channel, it is really have this bug fixed. In that part my bug duplicates it and can be closed, I think, By: Leif Madsen (lmadsen) 2009-09-08 13:25:36 Closing per the reporter. Please reopen should this not be the case. |