+++ 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 ---