Hi Jonas, Thanks for your time going into detail about it.
On Fri, Dec 09, 2022 at 03:59:47PM +0100, Jonas Smedegaard wrote: > Hi Salvatore, > > Quoting Salvatore Bonaccorso (2022-12-09 15:15:26) > > This issue does not appear to be fixed with the > > 1:20.0.1~dfsg+~cs6.12.40431414-1 . could you double-check again? > > First of all: Thanks a lot for doublechecking! > > I did not test the bug nor the bugfix - I only traced reports across > projects when I closed this bug. > > If you reopen similarly based only on tracing reports across projects, > then I suspect the (sub)issue really is Asterisk project failing to > prominently reference CVE or GHSA issue hints in their bug closure. > > The issue tracked here - unless I am mistaken - is CVE-2022-31031, also > reported as GHSA-26j7-ww69-c4qj against PJSIP project, and (referencing > only GHSA identifiers, and only in patch content not commit header) This is correct, we are talking about CVE-2022-31031 known as well as GHSA-26j7-ww69-c4qj. > > PJSIP project fix is here: > https://github.com/pjsip/pjproject/commit/450baca Correct, this is the one referenced. > > Asterisk inclusion of the PJSIP fix is here: > https://github.com/asterisk/asterisk/commit/702f400 This looks as well correct. > Debian inclusion of Asterisk inclusion of PJSIP fix is here: > https://salsa.debian.org/pkg-voip-team/asterisk/-/blob/debian/1%2520.0.1_dfsg+_cs6.12.40431414-1/third-party/pjproject/patches/0201-potential-stack-buffer-overflow-when-parsing-message-as-a-STUN-client.patch > > I have now double-checked that during build the configure target has > succesfully applied the STUN-related patch, and that the file > third-party/pjproject/source/pjlib-util/src/pjlib-util/stun_simple.c > contains the newly introduced string "attr_max_cnt" unique to the PJSIP > bugfix. Ok so now I see what went possibly wrong. On source unpack an applying all debian/patches, the file ./Xpjproject/pjlib-util/src/pjlib-util/stun_simple.c was still unpatched. >From here I now understand they are patched by the upstream approach trough third-party/pjproject/Makefile using the apply_patches script and the build of the third_party included projects is triggered in the build. > I (still) consider this issue fixed, but will leave this bugreport open > awaiting your further assesment. Thanks so at further look and understanding the above, the additional patches get applied and so CVE-2022-31031 should indeed be fixed. I checked now again the explicit build, and the file get patched in ./asterisk-20.0.1~dfsg+~cs6.12.40431414/third-party/pjproject/source/pjlib-util/src/pjlib-util/stun_simple.c Regards, Salvatore
