RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

When reading strings, the generated *_validate functions do not check if the buffer has space for the length field.  It seems that this can lead to an assert when decoding a message.

The generated function __qmi_message_dms_set_firmware_preference_request_create() calls qmi_utils_write_string_to_buffer() in a loop.  It is not immediately obvious why the statically allocated target buffer has sufficient storage space for all those strings.  In other cases, only a single PASCAL string is written to a buffer which has slightly less than 1024 bytes, which should be okay.

I don't know where the data comes from and if an untrusted source might trigger crashes this way, hence the private bug.

Upstream fix:

http://cgit.freedesktop.org/libqmi/commit/?id=451d627530686833fd5fffba9d412dfa9fe41fc5 qmi-codegen: make sure expected len is 4 bytes

http://cgit.freedesktop.org/libqmi/commit/?id=150768f6bba84182e7d3a956c36d5a7d27129759 qmi-codegen: error out if invalid array size element in JSON

http://cgit.freedesktop.org/libqmi/commit/?id=b439d6d13ec8a8e4ff247b7d042424f10574aa84 qmi-codegen: avoid buffer overlow in emit_input_tlv_add()

http://cgit.freedesktop.org/libqmi/commit/?id=c744b04814098ea3647de8d618bd88e5554e1a26 libqmi,utils: assert input buffer size when writing strings to buffer

http://cgit.freedesktop.org/libqmi/commit/?id=471d038fe38f7b99383f9654dcc8f6662d96e6f8 qmi-codegen: ensure enough buffer available to read string/array size variable

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0579.html