Note: This is an archival copy of Security Sun Alert 200407 as previously published on
Latest version of this security advisory is available from as Sun Alert 1000292.1.
Article ID : 1000292.1
Article Type : Sun Alerts (SURE)
Last reviewed : 2007-01-29
Audience : PUBLIC
Copyright Notice: Copyright © 2010, Oracle Corporation and/or its affiliates.

A "Use-after-free" Vulnerability in Sendmail Versions Before 8.13.8 may Allow a Denial of Service (DoS)


Release Phase

Solaris 9 Operating System
Solaris 10 Operating System

Bug Id

Date of Workaround Release

Date of Resolved Release


A "use-after-free" security vulnerability in sendmail(1M) relating to the handling of long header lines may allow a local or remote unprivileged user to fill up a disk if sendmail(1M) is configured to write unique core files. The core files created by sendmail(1M) would be written to the disk partition configured with coreadm(1M). The ability to consume all available space of a disk partition (which may be the root "/" partition) is a type of denial of service (DoS).

Additional information regarding this issue is available at:

Contributing Factors

This issue can occur in the following releases:

SPARC Platform

  • Solaris 9 without patch 113575-08
  • Solaris 10 without patch 125011-01

x86 Platform

  • Solaris 9 without patch 114137-07
  • Solaris 10 without patch 125012-01

Note 1: Sendmail versions prior to 8.12.0 are not impacted by this issue. Solaris 8 uses sendmail versions prior to 8.12.0 and thus is not impacted.

Note 2: This issue only affects systems which have sendmail(1M) versions 8.12.0 to 8.13.7 enabled and have configured sendmail(1M) to create unique core dumps.

To determine the version of sendmail(1M) running on a system, the mconnect(1) command can be used:

    $ /usr/bin/mconnect
    connecting to host localhost (, port 25
    connection open
    220 ESMTP Sendmail 8.13.5+Sun/8.13.5;
    Mon, 20 Mar 2006 17:07:57 GMT
    221 2.0.0 closing connection

If sendmail is not running on the system the mconnect(1) command will report the following:

    $ /usr/bin/mconnect
    connecting to host localhost (, port 25
    connect: Connection refused

To determine if sendmail(1M) has been configured to create unique core dumps the coreadm(1M) command can be utilized to check the global and per-process core dump settings which affect sendmail processes:

    $ coreadm | grep global
    global core file pattern: /var/cores/core.%f.%p
    global core file content: default
    global core dumps: enabled
    global setid core dumps: disabled
    global core dump logging: disabled
    # coreadm `pgrep sendmail`
    109584:  core.%f.%p      default



If the described issue occurs, the symptoms would be a decreasing amount or no free space, as displayed by the df(1M) utility, on the file system partition which sendmail(1M) is configured to write core files to using coreadm(1M) due to a large number of sendmail core dumps.


To prevent sendmail(1M) from filling up the configured disk partition with unique core dumps, the coreadm(1M) utility can be used to configure sendmail to create statically named core files. This should be applied to both the global core file pattern (if enabled) and the per-process core file pattern.

To configure sendmail to create core files with static filenames until the sendmail service is restarted:

    # coreadm -p core.%f $(pgrep sendmail)



This issue is addressed in the following releases:

SPARC Platform

  • Solaris 9 with patch 113575-08 or later
  • Solaris 10 with patch 125011-01 or later

x86 Platform

  • Solaris 9 with patch 114137-07 or later
  • Solaris 10 with patch 125012-01 or later

Modification History
Date: 27-NOV-2006
  • Upated Contributing Factors and Resolution sections.

Date: 12-DEC-2006
  • Updated Relief/Workaround section

Date: 30-JAN-2007
  • State: Resolved
  • Updated Contributing Factors and Resolution sections



This solution has no attachment