On 18/07/13 17:26, John Foley wrote: > We've seen BUS errors on some platforms. I'm not confident the > following patch was ever pushed back to libsrtp. There's a chance this > may resolve the problem on sparc. Unfortunately I don't have a sparc > system to try this myself.
Thanks for this feedback The patch doesn't apply - all but one hunk fails I tried it against the Debian source package and I also tried applying it against the repository https://github.com/cisco/libsrtp Can you tell me the SVN URL where you got this and I can try checking it out and building it? > > Modified: branches/proto/libsrtp_30/srtp/include/srtp.h > =================================================================== > --- branches/proto/libsrtp_30/srtp/include/srtp.h 2013-04-24 19:44:23 UTC > (rev 1292) > +++ branches/proto/libsrtp_30/srtp/include/srtp.h 2013-04-29 14:17:03 UTC > (rev 1293) > @@ -52,6 +52,11 @@ > > #ifdef _MSC_VER > #pragma pack(4) > +#define PACK > +#elif defined(__GNUC__) > +#define PACK __attribute__ ((packed)) > +#else > +#define PACK > #endif > > #include "crypto_kernel.h" > > Modified: branches/proto/libsrtp_30/srtp/include/srtp_priv.h > =================================================================== > --- branches/proto/libsrtp_30/srtp/include/srtp_priv.h 2013-04-24 > 19:44:23 UTC (rev 1292) > +++ branches/proto/libsrtp_30/srtp/include/srtp_priv.h 2013-04-29 > 14:17:03 UTC (rev 1293) > @@ -68,7 +68,7 @@ > * fully pack the bit fields. > */ > > -typedef struct { > +typedef struct PACK { > unsigned char cc : 4; /* CSRC count */ > unsigned char x : 1; /* header extension flag */ > unsigned char p : 1; /* padding flag */ > @@ -82,7 +82,7 @@ > > #else /* BIG_ENDIAN */ > > -typedef struct { > +typedef struct PACK { > unsigned char version : 2; /* protocol version */ > unsigned char p : 1; /* padding flag */ > unsigned char x : 1; /* header extension flag */ > @@ -96,7 +96,7 @@ > > #endif > > -typedef struct { > +typedef struct PACK { > uint16_t profile_specific; /* profile-specific info */ > uint16_t length; /* number of 32-bit words in extension */ > } srtp_hdr_xtnd_t; > @@ -111,7 +111,7 @@ > > #ifndef WORDS_BIGENDIAN > > -typedef struct { > +typedef struct PACK { > unsigned char rc : 5; /* reception report count */ > unsigned char p : 1; /* padding flag */ > unsigned char version : 2; /* protocol version */ > @@ -120,7 +120,7 @@ > uint32_t ssrc; /* synchronization source */ > } srtcp_hdr_t; > > -typedef struct { > +typedef struct PACK { > unsigned int index : 31; /* srtcp packet index in network order! */ > unsigned int e : 1; /* encrypted? 1=yes */ > /* optional mikey/etc go here */ > @@ -130,7 +130,7 @@ > > #else /* BIG_ENDIAN */ > > -typedef struct { > +typedef struct PACK { > unsigned char version : 2; /* protocol version */ > unsigned char p : 1; /* padding flag */ > unsigned char rc : 5; /* reception report count */ > @@ -139,7 +139,7 @@ > uint32_t ssrc; /* synchronization source */ > } srtcp_hdr_t; > > -typedef struct { > +typedef struct PACK { > unsigned int version : 2; /* protocol version */ > unsigned int p : 1; /* padding flag */ > unsigned int count : 5; /* varies by packet type */ > @@ -147,7 +147,7 @@ > uint16_t length; /* len of uint32s of packet less header */ > } rtcp_common_t; > > -typedef struct { > +typedef struct PACK { > unsigned int e : 1; /* encrypted? 1=yes */ > unsigned int index : 31; /* srtcp packet index */ > /* optional mikey/etc go here */ > > > > On 07/18/2013 10:51 AM, Jonathan Lennox wrote: >> Sparc failing with "Bus Error" usually indicates an unaligned access. Other >> platforms tolerate this, but at some performance cost, so it's good to get >> rid of it across the board. I wouldn't expect it to be a security >> vulnerability. >> >> Can you pull the current GIT repo to see if it fails the same way? >> >> On Jul 18, 2013, at 7:47 AM, Daniel Pocock <dan...@pocock.com.au> wrote: >> >>> There is a long outstanding bug in Debian for sparc, specifically, bus >>> error in the test cases: >>> >>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628583 >>> >>> While the error only appears on sparc it may be indicative of other problems >>> >>> Given concern about the recent CVE-2013-2139 (buffer overflow) it might >>> also be helpful to try and correct things like this that suggest some >>> coding issues still exist >>> >>> Has anybody already looked at the issue in the past? Does the stack >>> trace suggest any particular problem? >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> See everything from the browser to the database with AppDynamics >>> Get end-to-end visibility with application monitoring from AppDynamics >>> Isolate bottlenecks and diagnose root cause in seconds. >>> Start your free trial of AppDynamics Pro today! >>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Srtp-development mailing list >>> srtp-developm...@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/srtp-development >> -- >> Jonathan Lennox >> jonat...@vidyo.com >> >> >> >> ------------------------------------------------------------------------------ >> See everything from the browser to the database with AppDynamics >> Get end-to-end visibility with application monitoring from AppDynamics >> Isolate bottlenecks and diagnose root cause in seconds. >> Start your free trial of AppDynamics Pro today! >> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk >> _______________________________________________ >> Srtp-development mailing list >> srtp-developm...@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/srtp-development >> > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > > > _______________________________________________ > Srtp-development mailing list > srtp-developm...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/srtp-development
