freebsd-update odd behavior

D

dr_grid

Greetings all. I am running FreeBSD 13.5-RELEASE-p10 on two systems here. The periodic daily security job alerted about a new
patch to fix a vulnerability, specifically:

Code: 
FreeBSD-kernel-13.5_10 is vulnerable:
 FreeBSD -- Remote code execution via RPCSEC_GSS packet validation
 CVE: CVE-2026-4747
 WWW: https://vuxml.FreeBSD.org/freebsd/733febba-28d2-11f1-b35e-bc241121aa0a.html

I ran freebsd-update fetch and freebsd-update install yesterday on both machines, and even rebooted one of
the machines last night.

Today the periodic security job is still reporting the same vulnerability on both machines. A quick check with freebsd-version -ku shows that the userland is now at patch level 11, where it should be, but the kernel is a patch level 10.

What did I miss? I would expect patch 11 on both the userland and the kernel, so I am not sure what went wrong.
Thanks in advance for any insight.
 

Attachments

  • 1774737055312.png
    1774737055312.png
    10 KB · Views: 13
nxjoseph@ said:
Hi.

That looks like a package for me, any chance you're using PkgBase?
Click to expand...
No, I am not using PkgBase. So far I have had success with freebsd-update since 10.2.

Another note, I see that I did receive a new kgssapi.ko in the /boot/kernel directory,
so it would seem the correct patch was applied to the kernel. But the kernel is reported to be at patch level 10.
 
nxjoseph@ said:
Hmm. Maybe the kernel did not get rebuild so that it still stays on -p10 but the kernel files has been updated?
Click to expand...
From my experience freebsd-update does not rebuild, that is, recompile the kernel. It will replace binaries as needed. I am not sure, but I think there is a file with the kernel's version and patch level. If this was not updated, then I would be getting the results I am seeing. But again, I am not sure that is the way it works.
 
dr_grid said:
From my experience freebsd-update does not rebuild, that is, recompile the kernel.
Click to expand...
Yes, it's for binary upgrading. My guess is that the kernel did not need to get rebuild in order to fix that security update but only files (as in libraries, modules) get updated, like you've noticed. If it doesn't get rebuild, it keeps the old patch version number.

I don't know why that periodic-job thinks you are unsafe, maybe because of the baked-in version thing above.
 
how about actually posting the output of "freebsd-version -kru"?
-k "installed kernel"
-r "currently running kernel"
-u "userland"

There are times when a patch may only update userland or it may update the kernel. But a kernel update may show difference between the "currently running kernel" and the "installed kernel" until you reboot.

If you specify "-kru" it always reports in "-k" "-r" -"u" order so "-ukr" is the same as "-kru"

freebsd-update does not rebuild kernel.
 
nxjoseph@ said:
Yes, it's for binary upgrading. My guess is that the kernel did not need to get rebuild in order to fix that security update but only files (as in libraries, modules) get updated, like you've noticed. If it doesn't get rebuild, it keeps the old patch version number.

I don't know why that periodic-job thinks you are unsafe, maybe because of the baked-in version thing above.
Click to expand...
I think you may be right about the kernel having that string "baked-in". I just ran
strings /boot/kernel/kernel | grep p10 and got, among other strings, these three strings:
Code: 
@(#)FreeBSD 13.5-RELEASE-p10 GENERIC
FreeBSD 13.5-RELEASE-p10 GENERIC
13.5-RELEASE-p10
I would suspect that freebsd-version -k looks in the kernel for such a string for its response. If anyone could confirm that, then I consider the problem solved, and I learned something new today.
 
dr_grid said:
I think you may be right about the kernel having that string "baked-in". I just ran
strings /boot/kernel/kernel | grep p10 and got, among other strings, these three strings:
Code: 
@(#)FreeBSD 13.5-RELEASE-p10 GENERIC
FreeBSD 13.5-RELEASE-p10 GENERIC
13.5-RELEASE-p10
I would suspect that freebsd-version -k looks in the kernel for such a string for its response. If anyone could confirm that, then I consider the problem solved, and I learned something new today.
Click to expand...
freebsd-version -k looks at the "installed kernel" which may not be the same as the "currently running kernel". I'm not sure if it's looking at the "strings" in the elf executable, but "-k" is "installed kernel" "-r" is "currently running kernel". These may be different until a system reboot.
 
mer said:
how about actually posting the output of "freebsd-version -kru"?
-k "installed kernel"
-r "currently running kernel"
-u "userland"

There are times when a patch may only update userland or it may update the kernel. But a kernel update may show difference between the "currently running kernel" and the "installed kernel" until you reboot.

If you specify "-kru" it always reports in "-k" "-r" -"u" order so "-ukr" is the same as "-kru"

freebsd-update does not rebuild kernel.
Click to expand...
Here you go:
Code: 
[matt@dagobah ~]$ freebsd-version -kru
13.5-RELEASE-p10
13.5-RELEASE-p10
13.5-RELEASE-p11

This was the result on both the machine that was not rebooted AND the machine that was rebooted. This reinforces my notion of where the version information is obtained.
 
Ok. This is one of the most common threads around "what does freebsd-version" report.
And yes, it is a bit confusing because if an update only affects userland, you wind up with difference between "kernel" and "userland".

What this output tells me is freebsd-13.5-RELEASE latest updates has only userland updates.
Not a big deal, but one needs to understand what the tool says.
I don't know for certain, but I believe "strings" in the different kernel images feeds into the output.
 
You must log in or register to reply here.
Back
Top