Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#17825 closed defect (fixed)

Fix segfaults due to wxCFStringRef creating null references

Reported by: botg Owned by: Vadim Zeitlin <vadim@…>
Priority: normal Milestone:
Component: wxOSX Version: dev-latest
Keywords: Cc:
Blocked By: Blocking:
Patch: yes

Description

If a string passed to the wxCFStringRef constructor cannot be represented in the target encoding, a null wxCFStringRef is created.

Most users of wxCFStringRef do not check for null and thus segfault with a null-pointer dereference.

This patch for both trunk and WX_3_0_BRANCH changes the wxCFStringRef constructur to instead create a reference to an empty string.

Attachments (1)

0001-If-the-passed-string-cannot-be-represented-in-the-ta.patch download (1.4 KB) - added by botg 5 years ago.
Path for both master and WX_3_0_BRANCH

Download all attachments as: .zip

Change History (4)

Changed 5 years ago by botg

Path for both master and WX_3_0_BRANCH

comment:1 Changed 5 years ago by Vadim Zeitlin <vadim@…>

  • Owner set to Vadim Zeitlin <vadim@…>
  • Resolution set to fixed
  • Status changed from new to closed

In 8f12eaf98037a3b04f05072c9e8ca34c8083abd5/git-wxWidgets:

Create empty wxCFStringRef and not null one if conversion fails

If the passed string cannot be represented in the target encoding in the
wxCFStringRef constructor, create a reference to an empty string instead of a
null ref. Most users of wxCFStringRef cannot handle a null wxCFStringRef.

Closes #17825.

(cherry picked from commit a2b04536d37e8387724f8b8cd68410dd72c67ce6)

comment:2 Changed 5 years ago by Vadim Zeitlin <vadim@…>

In a2b04536d37e8387724f8b8cd68410dd72c67ce6/git-wxWidgets:

Create empty wxCFStringRef and not null one if conversion fails

If the passed string cannot be represented in the target encoding in the
wxCFStringRef constructor, create a reference to an empty string instead of a
null ref. Most users of wxCFStringRef cannot handle a null wxCFStringRef.

Closes #17825.

comment:3 Changed 5 years ago by vadz

See 493643477c99a3ab79d9f8dedc10b79edc860a0b and 397e6e9e357702c9b9497d980283ff36675117fa (its backport to 3.0) for the compilation fixes after this.

I do wonder now if the original patch was actually tested, this seems unlikely if it didn't even compile... Maybe it was a bad idea applying it in the first place? Any other thoughts about this?

Note: See TracTickets for help on using tickets.