Hide Forgot
Description of problem: A patch to address CVE-2010-4352 (bug #663673) as used in the dbus packages in EL6 is not applied correctly. This is due to one of the hunks from the upstream git changeset not being applicable to the EL6 code base: --- a/dbus/dbus-marshal-validate.h +++ b/dbus/dbus-marshal-validate.h @@ -112,6 +112,7 @@ typedef enum DBUS_INVALID_DICT_ENTRY_NOT_INSIDE_ARRAY = 54, DBUS_INVALID_DICT_KEY_MUST_BE_BASIC_TYPE = 55, DBUS_INVALID_MISSING_UNIX_FDS = 56, + DBUS_INVALID_NESTED_TOO_DEEPLY = 57, DBUS_VALIDITY_LAST } DBusValidity; While EL6 dbus has this definition of the DBusValidity enum: DBUS_INVALID_DICT_ENTRY_HAS_NO_FIELDS = 51, DBUS_INVALID_DICT_ENTRY_HAS_ONLY_ONE_FIELD = 52, DBUS_INVALID_DICT_ENTRY_HAS_TOO_MANY_FIELDS = 53, DBUS_INVALID_DICT_ENTRY_NOT_INSIDE_ARRAY = 54, DBUS_INVALID_DICT_KEY_MUST_BE_BASIC_TYPE = 55, DBUS_VALIDITY_LAST } DBusValidity; i.e. does not define DBUS_INVALID_MISSING_UNIX_FDS. The patch fails to apply when running patch with default fuzz, but it succeeds when called during the rpm build due to the abusive setting for the _default_patch_fuzz rpm macro (999), which causes patch to ignore all context in the diff and apply the change to the specific line, resulting in the following change being applied: --- dbus-1.2.24.orig/dbus/dbus-marshal-validate.h +++ dbus-1.2.24/dbus/dbus-marshal-validate.h @@ -112,6 +112,7 @@ typedef enum DBUS_INVALID_EXCEEDED_MAXIMUM_DICT_ENTRY_RECURSION = 48, DBUS_INVALID_DICT_ENTRY_ENDED_BUT_NOT_STARTED = 49, DBUS_INVALID_DICT_ENTRY_STARTED_BUT_NOT_ENDED = 50, + DBUS_INVALID_NESTED_TOO_DEEPLY = 57, DBUS_INVALID_DICT_ENTRY_HAS_NO_FIELDS = 51, DBUS_INVALID_DICT_ENTRY_HAS_ONLY_ONE_FIELD = 52, DBUS_INVALID_DICT_ENTRY_HAS_TOO_MANY_FIELDS = 53, As a consequence, DBUS_VALIDITY_LAST numeric value is not updated (remains 56). This value is used to determine required size for the validities_seen[] array. A possible attempt to update validities_seen[] at the position for DBUS_INVALID_NESTED_TOO_DEEPLY results in an off-by-two access. Version-Release number of selected component (if applicable): dbus-1.2.24-4.el6_0
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative.
(In reply to comment #0) > Description of problem: > A patch to address CVE-2010-4352 (bug #663673) as used in the dbus packages in > EL6 is not applied correctly. This is due to one of the hunks from the > upstream git changeset not being applicable to the EL6 code base: Argh =/ > This value is used to determine required size for the validities_seen[] array. But validities_seen is only built in the tests; it's not run as part of the daemon. So it's not worth doing an update for. How did you notice this issue? Looking around in the code I'm not seeing how this could create a runtime problem.
(In reply to comment #4) > > This value is used to determine required size for the validities_seen[] array. > > But validities_seen is only built in the tests; it's not run as part of the > daemon. So it's not worth doing an update for. Ok, thank you for looking. > How did you notice this issue? Looking around in the code I'm not seeing how > this could create a runtime problem. It was reported by a user trying to do rebuild with _default_patch_fuzz definition removed, indicating we've not really patched the original issue.
(In reply to comment #5) > It was reported by a user trying to do rebuild with _default_patch_fuzz > definition removed, indicating we've not really patched the original issue. Ok, that makes sense. Is there a procedure for committing things that we want in case a future update is made? Could I fix the patch in CVS, referencing the original bug?
(In reply to comment #6) > Ok, that makes sense. Is there a procedure for committing things that we want > in case a future update is made? Could I fix the patch in CVS, referencing the > original bug? The patch needs to be committed to CVS HEAD anyway (bug #684853), so we can commit corrected version there. I'm not sure what would be the cleanest way process-wise to correct in 6.0 branch, original bug should still allow you to commit though.
Looks like this bug needs pm_ack ?
Created attachment 504209 [details] patch for spec
Created attachment 504210 [details] rebased correct CVE-2010-4352 patch
Oh I see, I have to use bug 684583 in the commit. Done. Should this bug be closed now or should we reopen it in case we need to update the Z-stream again?
Updated patch file (comment #10) was not committed. Once that happens, please move this to modified.
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate, in the next release of Red Hat Enterprise Linux.
This was fixed in RHEL 6.3.