Solaris Critical Patch Updates (CPUs)

It's Oracle standard practice to release quarterly Critical Patch Updates (CPUs) containing security fixes.  These scheduled releases enable customers to plan maintenance windows.

Solaris now conforms to this practice and Solaris OS CPUs are now available.

The Solaris OS CPU is an archived snapshot of the Solaris OS Recommended Patch Cluster.

Please note that the Solaris OS bug fixing processes have not changed.  Security and other bugs continue to be fixed as soon as possible, patches containing such fixes for the Solaris OS will continue to be released as quickly as possible, and they will continue to be included in the Recommended Solaris OS Patch Clusters as soon as they become available. 

The Solaris OS CPU simply provides another, archived, patch collation option for customers.

See and in particular Document 1446032.1 on My Oracle Support (MOS),, which includes CVE mappings for Oracle Sun products. 


  1. The CPUs were created on July 6th and released on July 13th.
  2. Solaris 8 is in Vintage support so no patch clusters are updated for Solaris 8.  Instead, the above document lists Solaris 8 patches released in the last quarter which address Security issues.  A Solaris 8 Vintage support contract is needed to access some of them.
Update: CVE to patch mappings are now available for the Solaris CPU from July.  Please see


For customers who patch via the xref, is there a concise list of patch revisions (for Solaris 9 and 10) which contain the new security fixes in the CPU?

The CPU advisory doc lists only the CVE numbers, I didn't see any CR's or patch ID's. The availability doc simply refers to the bundle.

The bundle README's list only patch ID's, and not CR's or CVE's. They also contain all of the prerequisite patches, not just the new ones.

Patchfinder doesn't always know the fixes by CVE number, so that doesn't help either. It seems that I cannot easily cross-reference the CVE list.

Let me know if I missed something obvious. Thanks for any info... -cheers, CSB

Posted by Craig Bell on July 13, 2010 at 03:25 PM IST #

In the last advisory in april there was a list of CVE IDs to Sun Alerts mapping. These alerts contained detailed information like patch IDs. This way we could identify patch IDs required by a specific CVE ID.

Such a list is missing this time for operating system Solaris. At the bottom of document
we can see a list of all vulnerabilities covered by the current advisory, but there are no further details.

For documentation purposes we need a mapping of security issues or vulnerability IDs to patch IDs.

During security audits the auditor usually comes with a list of vulnerabilities and wants to know if they are fixed. This can be done only by checking if certain patches are installed or not. That's why we need a relation of vulnerabilities and patches.


Posted by Andreas Koppenhoefer on July 14, 2010 at 04:48 AM IST #

Hi Andreas, Craig,

I've forwarded your feedback to the Security team and I'm awaiting their response.

Best Wishes,


Posted by Gerry Haskins on July 15, 2010 at 03:02 AM IST #

Hi Andreas, Craig,

The intention here is that all systems should install the CPU cluster.
If a patch is already installed, or if a patch does not apply to your system
because that package is not installed, then that patch will be skipped.

The new Oracle way of working does not link individual issues to specific patches.

The April 2010 CPU was the first CPU for the Sun products. At that time we
had not fully adopted the new Oracle way of working.

Best wishes


Posted by Angela Byrne on July 15, 2010 at 05:59 AM IST #

So to verify all CVEs are covered,
we would need to check for
the presence of all patches
delivered by the CPU set?

Posted by Stuart Remphrey on July 19, 2010 at 03:52 AM IST #

Angela, thanks for the info. Like many customers, we use only the xref to analyze patches, and have not ever used bundles. Thus we feel that it's still important to know which revisions matter for the CPU.

Let me ask another way: Is every CPU-related revision in the new Recommended bundle also marked with the R flag in the contemporaneous xref file? If so, then we could simply apply all R patches after that day, and get the same benefit.

Or we could apply all R and S, if that flag also matters from the CPU release point of view. Thanks again. -cheers, CSB

Posted by Craig S. Bell on July 20, 2010 at 11:59 AM IST #

Angela - this policy is not acceptable to at least some of your enterprise customers. For those that have strict vulnerability tracking this policy will not work.

For instance if a customer tracks CVEs independently and uses software/OS inventory tracking to determine compliance this policy effectively means that remediations can no longer be tracked. This in turn makes your operating platform unacceptable for use to these customers as they can no longer demonstrate to regulatory authorities (such as the OCC) that they in fact do have procedures to both identify and manage risk.

If Oracle does not identify the individual patch then how can the customer document the solution, identify the level of risk through non-compliance, and demonstrate we are taking the appropriate corrective actions?

Posted by Enterprise Financial Customer on July 21, 2010 at 09:02 AM IST #

Well put, EFC. =-) Analysis, documentation, and audit review are critical considerations for my systems as well. Our security process assumes that we know exactly what we are applying, and why. We never patch blindly.

I start with the alert, follow it to the specific CR number, and ultimately the patch revision, t-patch, IDR, &c. which includes that CR. I review each and every patch before it goes on. Yes, all of them, every time.

Without a transparent path from the CVE to the patch revision, this "just apply everything in the bundle" philosophy will \*not\* meet our security process needs. There needs to be a way to map the vulnerabilities to the resolution.

In the context of the CPU, the obvious remedy would be to include CR (and patch rev when available) numbers in the availability docs, and also make sure that CVE numbers are listed in the CR description, and thus the patch README.

That seems simple enough to me. I'm not sure what is gained by de-coupling the vulnerability from the resolution, but this is going to make life much harder for your (many) customers with even semi-serious security processes.

As mentioned earlier, it would help if I knew that the "R" flag in the xref file included everything required by the CPU. Even then, I still must browse the patch README, and understand what it's fixing -- regardless of criticality.

Thanks again for your thoughts. -cheers, CSB

Posted by Craig S. Bell on July 22, 2010 at 12:38 PM IST #

Hi Stuart, Craig, and "Enterprise Financial Customer",

Firstly, I've forwarded the concerns raised about the mapping of CVEs to PatchIDs to the Security team and my peer there is raising the matter again with his management chain.

Secondly, all security related issues in the Solaris CPU and Recommended Cluster are marked "S" (for Security) in the patchdiag.xref file ( available from the SunSolve Patch Download page (

The "S" (Security) flag is associated with any patch containing a Security fix for any product, not just the Solaris OS.

The "R" (Recommended) flag is associated with any patch in the current Solaris OS Recommended Cluster - i.e. just Solaris OS patches. These are all Solaris OS patches which address Security, Data Corruption, and System Availability issues as well as the latest patch utility patches and any patches required by the above.

So patches marked both "R" and "S" are the current Solaris OS Recommended Security patches.

See for further information.

However, a better way to identify security fixes is to use the PatchFinder tool,

You can use the "Security Filter" to show all patches containing either "Accumulated Security Fixes", which provides the same information as the "S" flag in patchdiag.xref above - i.e. the latest revision of patches which have accumulated security fixes.

But, more advantageously, you can also select "New Security Fixes" which will return the exact revisions of all patches which contain new security fixes.

How does this help ?

For example, let's say a security issue is fixed in /usr/bin/ls in patch 123456-01. This revision will be marked as containing a New Security Fix. It will also be marked "S" in patchdiag.xref. But let's say that patch gets accumulated into the Kernel patch 118833-36 due to mutual code interdependencies introduced by the "Trusted Solaris Extensions" project. The "S" flag in patchdiag.xref which is the same as the "Accumulated Security Fix" flag in PatchFinder will be propagated forward to all accumulating patches, in this case 118833-36, even if (let's pretend for the purposes of this example) no additional security fixes were included in 118833-36 over and above 123456-01. If you look at the "S" flag in patchdiag.xref, or the "Accumulated Security Fix" flag in PatchFinder, it'll seem to suggest that 118833-36 (and any other patches that may eventually accumulate the contents of 123456-01) contain new security fixes. This may cause customers to apply far more patches than necessary to get all security fixes. In contrast, the "New Security Fix" flag in PatchFinder will tell you precisely which revisions of which patches introduced \*new\* security fixes. Hence the "New Security Fix" flag in PatchFinder provides much more precise security fix information than patchdiag.xref, and hence PatchFinder is the superior solution to avoid unnecessary patching to get security fixes.

But to save all the hassle of this pick-and-choose method, we recommend that customers simply keep as up to date as possible with the contents of the Solaris OS Recommended Cluster (or the CPU which is an archived copy of it) - i.e. simply apply the cluster in your next scheduled patching maintenance window.

Clear as mud ?

Posted by Gerry Haskins on July 23, 2010 at 06:40 AM IST #

Gerry, thank you for passing that along. Knowing that R and S is sufficient to encompass the CPU goes a long way towards addressing the practical issue.

I'm not too concerned about new vs. accumulated fixes so long as I can analyze the README for myself, i.e. the CVE's (and their CR's) are visible. =-) -c

Posted by Craig S. Bell on July 23, 2010 at 11:05 AM IST #

Previously Sun provided a file called SApatches-pub.txt which mapped Security Alert ID's to the Solaris patch number-rev that satisfied the Alert. I've been trying to get that re-instated as it disappeared about 2-3 months ago. I would like to see it again, but with the addition of the CVE number in addition to the SA/ID, so patches can be mapped to the different documents which different auditors, etc. use.

We currently review the various alert documents, rate for our environment and then patch within a scheduled time frame based on that rating. I used the SApatches-pub.txt file to audit internally as well as for compliance auditors to show the state of a system. In fact, just today I got asked about the CVE's and how they now fit into this process, and how we would audit compliance.

Anyway, I can't understand the difficulty to re-instate that file (you generated it for years) and add in the CVE number to the table, this would then meet your customer's requirements based on their procedures.

Making things like this, that your customers have to do for compliance, so difficult is one more way you push them to other vendors. Add this to the new 12% premium support cost which is only useful if your facility is within 25 miles of a depot (if not your 2 hour support turns into next day best effort) and you get customers asking questions like a manager asked me the other day, "Why are we buying something we can't get adequate support for, even when we pay a lot of money for it?".

Posted by Dave on July 29, 2010 at 04:38 AM IST #

Hi Folks,

I'm delighted to see that Oracle is listening to your feedback.

Please see

Many thanks to my colleagues in the Security team.

Best Wishes,


Posted by Gerry Haskins on August 05, 2010 at 10:06 AM IST #

Thanks to the Security team for making this available. I will contact those interested in understanding our security policies and process. -c

Posted by Craig S. Bell on August 05, 2010 at 11:25 AM IST #

interesting read, nice collection

Posted by çeviri on August 10, 2010 at 03:39 PM IST #

Post a Comment:
  • HTML Syntax: NOT allowed

This blog is to inform customers about patching best practice, feature enhancements, and key issues. The views expressed on this blog are my own and do not necessarily reflect the views of Oracle. The Documents contained within this site may include statements about Oracle's product development plans. Many factors can materially affect these plans and the nature and timing of future product releases. Accordingly, this Information is provided to you solely for information only, is not a commitment to deliver any material code, or functionality, and SHOULD NOT BE RELIED UPON IN MAKING PURCHASING DECISIONS. The development, release, and timing of any features or functionality described remains at the sole discretion of Oracle. THIS INFORMATION MAY NOT BE INCORPORATED INTO ANY CONTRACTUAL AGREEMENT WITH ORACLE OR ITS SUBSIDIARIES OR AFFILIATES. ORACLE SPECIFICALLY DISCLAIMS ANY LIABILITY WITH RESPECT TO THIS INFORMATION. ~~~~~~~~~~~~ Gerry Haskins, Director, Software Lifecycle Engineer


« June 2016