public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: "Jason Pyeron" <jpyeron@pdinc.us>
To: <cygwin@cygwin.com>
Subject: FW: Postfix stable release 3.7.2 - interest in updated package?
Date: Thu, 28 Apr 2022 10:39:56 -0400	[thread overview]
Message-ID: <038401d85b0d$d4a2a140$7de7e3c0$@pdinc.us> (raw)

I will prioritize the packaging of this release (see below) based on community interest, otherwise looking at late May.

My task #10403

-Jason

-----Original Message-----
From: Wietse Venema
Sent: Thursday, April 28, 2022 9:23 AM
To: Postfix announce 
Cc: Postfix users 
Subject: Postfix stable release 3.7.2

[An on-line version of this announcement will be available at
https://www.postfix.org/announcements/postfix-3.7.2.html]

This reverts an overly complex change in the postscreen SMTP engine
(made during Postfix 3.7 development), and replaces it with much
simpler code. The bad change was crashing postscreen on some systems
after receiving malformed input (for example, a TLS "hello" message).

Workarounds are at the end of this text.

Under conditions described below, the postscreen program attempted
to read through an uninitialized 'const' pointer. The pointer value
depended on the compiler type and compiler options, but crucially,
it did not depend on network inputs.

The conditions were that 1) postscreen was enabled (not the default),
2) SMTPUTF8 support was enabled (the default), and 3) postscreen
received non-UTF8 input, for example, a TLS or RDP (remote desktop)
handshake request.

Depending on compiler details, the result of the read operation
could be "uninteresting", a combined memory leak and file handle
leak, or a postscreen crash with a segmentation violation (signal
11).

The segmentation violation result was observed by Michael Grimm
while running Postfix 3.7 and 3.8 on a FreeBSD 13.1 pre-release
version, while the result was "uninteresting" with FreeBSD 13.0
(both systems use Clang instead of GCC). The result was also
"uninteresting" on Fedora Linux with GCC, and on a few older systems
with GCC.

Workarounds:

  * Do nothing. On most systems the result is "uninteresting".

  * Do nothing. On systems where postscreen does crash, the crashes
    are rare, harmless, and postscreen restarts immediately when
    an SMTP client connects. On systems where postscreen does leak
    a file handle, it will restart when it reaches a resource limit.

  * Disable postscreen. Follow instructions in
    https://www.postfix.org/POSTSCREEN_README.html#turnoff

You can find the updated Postfix source code at the mirrors listed
at https://www.postfix.org/.




                 reply	other threads:[~2022-04-28 14:39 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='038401d85b0d$d4a2a140$7de7e3c0$@pdinc.us' \
    --to=jpyeron@pdinc.us \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).