Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
DescriptionJaroslav Škarvada
2021-07-03 10:47:20 UTC
+++ This bug was initially created as a clone of Bug #1977732 +++
Description of problem:
When a user entry has only whitespaces in the GECOS field, writing a mail makes postfix/cleanup crash.
The crash happens because unallocated memory is accessed in tok822_free() on line 780: it appears that token variable, which is the result of tok822_scan_limit() on line 774, is NULL:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
660 static void cleanup_header_done_callback(void *context)
661 {
:
747 /*
748 * Add a missing (Resent-)From: header.
749 */
750 if ((state->hdr_rewrite_context || var_always_add_hdrs)
751 && (state->headers_seen & (1 << (state->resent[0] ?
752 HDR_RESENT_FROM : HDR_FROM))) == 0) {
:
769 case HFROM_FORMAT_CODE_STD:
770 vstring_sprintf(state->temp2, "%sFrom: ", state->resent);
771 if (state->fullname[strcspn(state->fullname,
772 "%!" LEX_822_SPECIALS)] == 0) {
773 /* Normalize whitespace. */
774 token = tok822_scan_limit(state->fullname, &dummy_token,
775 var_token_limit);
776 } else {
:
778 }
779 tok822_externalize(state->temp2, token, TOK822_STR_NONE);
780 tok822_free(token);
:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
GDB trace, doing step-by-step debugging:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
(gdb) next
774 token = tok822_scan_limit(state->fullname, &dummy_token,
(gdb)
779 tok822_externalize(state->temp2, token, TOK822_STR_NONE);
(gdb) p token
$1 = (TOK822 *) 0x0
(gdb) p ((CLEANUP_STATE *)$rbx)->fullname
$2 = 0x5618ae9cae90 " "
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
Here above, we can see that the fullname contained in the message is an empty string containing a unique space character.
We can check this in the original mail file:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
T1625052190 858445Arewrite_context=localF SmyuserRroot@localhost...
^^^
HERE, only whitespace
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
Reading tok822_scan_limit(), we can see that in such case, the return value of the function is head, which is NULL.
This happens because the parsing on line 442/444 does nothing (it skips spaces) and hence it goes directly to line 474 without having assigned anything else to head variable than NULL.
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
427 TOK822 *tok822_scan_limit(const char *str, TOK822 **tailp, int tok_count_limit)
428 {
429 TOK822 *head = 0;
:
442 while ((ch = *(unsigned char *) str++) != 0) {
443 if (IS_SPACE_TAB_CR_LF(ch))
444 continue;
:
471 }
472 if (tailp)
473 *tailp = tail;
474 return (head);
475 }
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
Version-Release number of selected component (if applicable):
postfix-3.5.8-1.el8.x86_64
How reproducible:
ALWAYS
Steps to Reproduce:
1. Create a user account with only-whitespace GECOS field
# useradd -c " " myuser
2. Send a mail as the user
# su - myuser
$ mail -s TEST root@localhost
^D
3. Check postfix service
# journalctl -u postfix | tail
Actual results:
Jun 30 13:31:13 vm-postfix8 postfix/pickup[4476]: 91309115983C: uid=1000 from=<myuser>
Jun 30 13:31:13 vm-postfix8 postfix/pickup[4476]: warning: maildrop/D19752025C83: error writing 91309115983C: queue file write error
Jun 30 13:31:13 vm-postfix8 postfix/master[4475]: warning: process /usr/libexec/postfix/cleanup pid 4797 killed by signal 11
Expected results:
No crash, email sent.
Additional info:
This is a regression compared to RHEL7's postfix (postfix-2.10.1-9.el7.x86_64)
I'm creating this with Sev1/Prio1 because remote users may not be fixable at all.
--- Additional comment from Jaroslav Škarvada on 2021-07-03 12:41:15 CEST ---
(In reply to Renaud Métrich from comment #0)
Thanks for excellent analysis. I will clone this bug to RHEL-9, because all new postfix versions are affected by this problem. Workaround patch attached. I forwarded this report to upstream to get their statement.
--- Additional comment from Jaroslav Škarvada on 2021-07-03 12:42:37 CEST ---