oracle
How-to update Java 17 to latest CPU with CVE fixes?
How can one update to latest Java 17 in the container? Cloud vulnerabilities scan says the version of Java is not the latest and to update to Oracle Java Standard Edition (SE) Critical Patch Update - January 2025 (CPUJAN2025).
I can't sudo to run dnf as root inside container and not sure that is even the best method vs. others.
[oracle@2eeb69a6d317 /]$ update-alternatives --list
libnssckbi.so.x86_64 auto /usr/lib64/pkcs11/p11-kit-trust.so
java auto /usr/lib/jvm/jdk-17.0.12-oracle-x64/bin/java
java_jdk_17_oracle auto /usr/lib/jvm/jdk-17.0.12-oracle-x64
javac auto /usr/lib/jvm/jdk-17.0.12-oracle-x64/bin/javac
ksh auto /usr/bin/ksh93
ld auto /usr/bin/ld.bfd
python auto /usr/libexec/no-python
python3 manual /usr/bin/python3.11
BTW, you can enter the container as root user
podman exec -it -u root <container> bash
Thanks for the root user access info, cataloging that.
Yes it is the latest-23ai. I pulled the latest-23ai 4 days ago and it pulled down changes and came back up fine.
Tried pull again and says it is current, output: $ podman pull container-registry.oracle.com/database/adb-free:latest-23ai Trying to pull container-registry.oracle.com/database/adb-free:latest-23ai... Getting image source signatures Copying blob c027d4237e79 skipped: already exists Copying blob e5865cdd4317 skipped: already exists Copying blob 93388424bfae skipped: already exists Copying config 73b91e2be6 done | Writing manifest to image destination 73b91e2be6bbdb54c8b79c1b459c0c5c4b8fbb08f4c724793dddc56f491df782
Current:
rpm -qa | grep jdk
jdk-17-17.0.12-8.x86_64
Needs to be 17.0.15+, latest is 17.0.16.0.1, for current CVEs from April 2025 CPU (latest).
Tried to install latest jdk-17 but the repo's set from Oracle only have this version 17 available. So maybe repo(s) are missing in default configuration to find latest CPUs?
From dnf provides java:
jdk-17-2000:17.0.12-8.x86_64 : Java Platform Standard Edition Development Kit
Repo : @System
Matched from:
Provide : java = 2000:17.0.12
Last resort, downloaded jdk-17.0.16.0.1 RPM package file and installed with RPM.
What I tried in summary:
Tried addin oracle-java-jdk-release-el8 repository:
dnf install oracle-java-jdk-release-el8
But got errors and tried to modify the .repo with baseurl to the value on the https://yum.oracle.com/ linux 8 page vs. what came in via dnf and got it to list the Java SE versions but only listed v21+ not v17.
Looks like Oracle does not provide the v17 anymore from yum.oracle.com repos according to this page: https://yum.oracle.com/oracle-linux-java.html
Reverted the repo with dnf erase oracle-java-jdk-release-el8
I believe the current adb-free latest-23ai needs this updated, either move to java 21 if Oracle DB 21ai ADB will work with such or make sure that 17 version can be easily upgraded if/when needed.
@sjsaunde
We will check the minimum supported version of Java by ORDS and update accordingly in the next image. We release an image once every month.
@aosingh
Okay, I will await that update and apply it once it is available and then it will get scanned soon after that automatically.
Even though I did update it manually in the image, the scans still tag the storage overlay as having the vulnerable build of Java 17. ~/.local/share/containers/storage/overlay/
Example: Summary: Needing: Oracle Java Standard Edition (SE) Critical Patch Update - April 2025 (CPUAPR2025) Location: ~/.local/share/containers/storage/overlay/420f1c4d39fbbcc4ccd04eb4671c346fcc17fd0971a475e6f530cca526a8c803/diff/usr/lib/jvm/jdk-17.0.12-oracle-x64/bin/java 17.0.12+8-LTS-286 Enhanced
Hi @aosingh,
This is not a minimally supported java version issue. The update needed is to use the latest CPU (Critical Patch Update) of Java from Oracle for the version bundled in the container and to be diligent to keep it up to date with any quarterly CPU for Java that Oracle releases to avoid distributing known Security Vulnerabilities that will cause issues with using containers in Cloud or other environments requiring zero tolerance for such vulnerabilities.
In the meantime while awaiting action for the Security Vulnerabilities in the container I will look to modifying my container's configuration to get it to include the latest. Was hoping to not cause my container to no longer be able to take updates from this distribution,
@sjsaunde
We have released a new image with JDK 21. Please try with it
docker pull ghcr.io/oracle/adb-free:latest-23ai
Hi @aosingh ,
Previous container told to pull from was container-registry.oracle.com/database/adb-free:latest-23ai.
I tried pulling adb-free:latest-23ai leaving the location it pull from alone an it didn't seem to pull an update.
The container-registry.oracle.com https://container-registry.oracle.com/ords/ocr/ba/database/adb-free still shows
| Database version | Latest image tag | Specific release image tag |
|---|---|---|
| 23ai | latest-23ai | 24.11.4.2-23ai |
e.g. $ podman pull adb-free:latest-23ai $ podman start adb-free
$ podman pull adb-free:latest-23ai
Trying to pull container-registry.oracle.com/database/adb-free:latest-23ai...
Getting image source signatures
Copying blob c027d4237e79 skipped: already exists
Copying blob e5865cdd4317 skipped: already exists
Copying blob 93388424bfae skipped: already exists
Copying config 73b91e2be6 done |
Writing manifest to image destination
73b91e2be6bbdb54c8b79c1b459c0c5c4b8fbb08f4c724793dddc56f491df782
Is there a reason to use ghcr.io vs. container-registry.oracle.com or a delay in availability on container-registry.oracle.com ?
Used container-registry and adb-free:latest-23ai hoping to allow easy updating without resetting up everything, DB schemas, users, data, tablespaces, etc.
@sjsaunde We have to mirror the latest image on container-registry. We have 2 registries
- ghcr.io/oracle
- container-registry.oracle.com
I am working with Oracle Container Registry (OCR) folks to get the image updated. I will update when it's done.
Looks to be java 17 still in the container and in the user's podman container storage overlay directories:
~/.local/share/containers/storage/overlay/7e2cb54d706d7d861a9c7bfecfff580ab5f6eb2b6bfbaba37a70578c78813379/diff/usr/lib/jvm/jdk-17.0.12-oracle-x64
~/.local/share/containers/storage/overlay/7e2cb54d706d7d861a9c7bfecfff580ab5f6eb2b6bfbaba37a70578c78813379/diff/usr/java/jdk-17
~//.local/share/containers/storage/overlay/420f1c4d39fbbcc4ccd04eb4671c346fcc17fd0971a475e6f530cca526a8c803/diff/usr/java/jdk-17
~//.local/share/containers/storage/overlay/420f1c4d39fbbcc4ccd04eb4671c346fcc17fd0971a475e6f530cca526a8c803/diff/usr/java/jdk-17-oracle-x64
~/.local/share/containers/storage/overlay/420f1c4d39fbbcc4ccd04eb4671c346fcc17fd0971a475e6f530cca526a8c803/diff/usr/lib/jvm/jdk-17.0.12-oracle-x64
I do see a new jdk-21 directories in the same location:
./.local/share/containers/storage/overlay/0302c4f0a92857470e8f17075ce9f660fb8abe2b40401d6a790b7e1d6e5ab3db/diff/usr/java/jdk-21
./.local/share/containers/storage/overlay/0302c4f0a92857470e8f17075ce9f660fb8abe2b40401d6a790b7e1d6e5ab3db/diff/usr/java/jdk-21-oracle-x64
./.local/share/containers/storage/overlay/0302c4f0a92857470e8f17075ce9f660fb8abe2b40401d6a790b7e1d6e5ab3db/diff/usr/lib/jvm/jdk-21.0.8-oracle-x64
Can I remove the jdk-17 directories now, as maybe they were not removed in this new image when java 21 was added?
Or do I now need to do a podman commit to make those part of the image. If I do that won't it mean I can't take adb-free:latest-23ai updates anymore?
Details: I stopped container and ran pull:
$ podman pull container-registry.oracle.com/database/adb-free:latest-23ai
Trying to pull container-registry.oracle.com/database/adb-free:latest-23ai...
Getting image source signatures
Copying blob 8c2f0b4ba2e5 skipped: already exists
Copying blob 539f5690c025 skipped: already exists
Copying blob b5d38f03e337 skipped: already exists
Copying config 48c46871b8 done |
Writing manifest to image destination
48c46871b89a9735b03ea04e8e5cead42bc6be57d4c2861bcd9fc130492eb146
$ podman images
REPOSITORY TAG IMAGE ID CREATED SIZE
container-registry.oracle.com/database/adb-free latest-23ai 48c46871b89a 8 days ago 5.21 GB
Started back up and when in bash I see this:
[oracle@2eeb69a6d317 /]$ update-alternatives --list
libnssckbi.so.x86_64 auto /usr/lib64/pkcs11/p11-kit-trust.so
java auto /usr/lib/jvm/jdk-17.0.16.0.1-oracle-x64/bin/java
javac auto /usr/lib/jvm/jdk-17.0.16.0.1-oracle-x64/bin/javac
java_jdk_17_oracle auto /usr/lib/jvm/jdk-17.0.16.0.1-oracle-x64
ksh auto /usr/bin/ksh93
ld auto /usr/bin/ld.bfd
python auto /usr/libexec/no-python
python3 manual /usr/bin/python3.11
Hi @aosingh ,
Do I need to report these jdk-17.0.12-oracle-x64 files left on disk when updating as vulnerabilities?
They are showing as such in scans since they are on left on disk, even if not used.
Also, is the JDK 21 used the latest CPU so it is at least current clean from such vulnerabilities?
BTW, Oracle releases CPUs for vulnerabilities quarterly but this GitHub says it is updated monthly so consideration for the DB and JDK/JRE needs to be included as part of those monthly updates every month after the CPU quarterly is released.
hi @sjsaunde ,
i tried to pull the latest 23-ai image from both the registries and i see that jdk 21 is being used in both of them.
bash-4.4# update-alternatives --list
ksh auto /usr/bin/ksh93
python3 manual /usr/bin/python3.12
java auto /usr/lib/jvm/jdk-21.0.8-oracle-x64/bin/java
libnssckbi.so.x86_64 auto /usr/lib64/pkcs11/p11-kit-trust.so
ld auto /usr/bin/ld.bfd
javac auto /usr/lib/jvm/jdk-21.0.8-oracle-x64/bin/javac
python manual /usr/bin/python3.12
java_jdk_21_oracle auto /usr/lib/jvm/jdk-21.0.8-oracle-x64
can you please try this:
- stop the container
- remove the image
- again try to pull the image from the repo and check the jdk version
