Inconsistent version after upgrade ?

A

aji_pineapple

I'm a new FreeBSD user and just used freebsd-update fetch and freebsd-update install for the second time. I see inconsistent version numbers and am confused. Everything seems to be working. Is this normal ?

Also the handbook calls for upgrading packages after a major release via
pkg upgrade but is there any harm in doing this even otherwise ?

Lastly I'm using this on my personal laptop. What would be a reasonable/recommended cadence for doing both ?

Code: 
vikram@inspiron-2in-1 ~> freebsd-version  
14.1-RELEASE-p6

vikram@inspiron-2in-1 ~> freebsd-version -r
14.1-RELEASE-p5

vikram@inspiron-2in-1 ~> uname -r
14.1-RELEASE-p5

vikram@inspiron-2in-1 ~> cat /etc/os-release
NAME=FreeBSD
VERSION="14.1-RELEASE-p6"
VERSION_ID="14.1"
ID=freebsd
ANSI_COLOR="0;31"
PRETTY_NAME="FreeBSD 14.1-RELEASE-p6"
CPE_NAME="cpe:/o:freebsd:freebsd:14.1"
HOME_URL="https://FreeBSD.org/"
BUG_REPORT_URL="https://bugs.FreeBSD.org/"

vikram@inspiron-2in-1 ~> cat /var/run/os-release
NAME=FreeBSD
VERSION="14.1-RELEASE-p6"
VERSION_ID="14.1"
ID=freebsd
ANSI_COLOR="0;31"
PRETTY_NAME="FreeBSD 14.1-RELEASE-p6"
CPE_NAME="cpe:/o:freebsd:freebsd:14.1"
HOME_URL="https://FreeBSD.org/"
BUG_REPORT_URL="https://bugs.FreeBSD.org/"
 
freebsd-version -kru "kernel installed" "running kernel" "userland"
Depending on what is in a specific update (p-level) they may show differently.
Say an update is only userland components like sshd or ntpd. That version may likely be bumped.
A kernel only update will at first show a bump in the "k" version because that is what was installed.
Reboot will bring "k" and "r" versions into line.

uname only looks at the running kernel, should match freebsd-version -r.

man freebsd-version is pretty clear on this. The bolded paragraph explains the order the values are printed out; it is confusing when you specify -ruk but it actually print out in -kru order.
Code: 
NAME
     freebsd-version – print the version and patch level of the installed
     system

SYNOPSIS
     freebsd-version [-kru] [-j jail]

DESCRIPTION
     The freebsd-version utility makes a best effort to determine the version
     and patch level of the installed kernel and / or userland.

     The following options are available:

     -k          Print the version and patch level of the installed kernel.
                 Unlike uname(1), if a new kernel has been installed but the
                 system has not yet rebooted, freebsd-version will print the
                 version and patch level of the new kernel.

     -r          Print the version and patch level of the running kernel.
                 Unlike uname(1), this is unaffected by environment variables.

     -u          Print the version and patch level of the installed userland.
                 These are hardcoded into freebsd-version during the build.

     -j jail     Print the version and patch level of the installed userland
                 in the given jail specified by jid or name.  This option can
                 be specified multiple times.

     If several of the above options are specified, freebsd-version will print
     the installed kernel version first, then the running kernel version, next
     the userland version, and finally the userland version of the specified
     jails, on separate lines.  If neither is specified, it will print the
     userland version only.
 
aji_pineapple said:
I see inconsistent version numbers and am confused.
Click to expand...
fmc000 said:
it looks like the kernel is at patchlevel 5 whilst the userland is at 6.
Click to expand...

P6 fixed a couple of userland issues. The version of the kernel is baked in at compile time and because it hasn't been updated it should still show the 'old' version. If you (re)build the kernel it will show the 'new' version, but there will be no functional changes, it's merely cosmetic.
 
aji_pineapple said:
Thanks for the responses.

Also can or should I do pkg upgrades on a regular basis ?
Click to expand...
Opinions will vary, but if you are following quarterly (the default when you install a release), about every 3 months the package repos are rebuilt and update just about everything. Some packages will get security updates in between. I tend to run "pkg upgrade -n" every 2-3 weeks to see what has an update. Then I decide "should I?".

If one waits for quarterly, and you are using ZFS, I would make a new BE before actually doing the pkg upgrade command. Quick and easy rollback if there is a problem.
 
chrbr said:
Dear aji_pineapple,
I think it is a good practice to run pkg audit -F.That checks the packages against a database which lists vulnerable packages. With the option -F the database is fetched before the check. Please see pkg-audit(8) for dteails. I run the command after reboot using crontab(1). In case vulnerabilities are listed one should run pkg upgrade.
Click to expand...
That's exactly what I do. I made a custom XFCE genmon script for this:

Code: 
[18:46][fmc000@tu45b-freebsd][~/.local/bin]
 ╰─$ cat pkgaud.sh
#!/usr/local/bin/bash
PKGAUD=$(doas pkg audit -F|tail -1|awk '{print $1}')
OUTPUT=$(doas pkg audit -F|grep -v vulnxml)
ICO_OK=emblem-synchronized
ICO_AUD=emblem-important
if [ $PKGAUD -eq 0 ]; then
     ICO=$ICO_OK
else ICO=$ICO_AUD
     echo "<txt> ($PKGAUD)</txt>"
fi
echo "<icon>$ICO</icon>"
echo "<tool>$OUTPUT</tool>"
[18:46][fmc000@tu45b-freebsd][~/.local/bin]
 ╰─$

BTW, just a few minutes ago this script informed me about two vulnerabilities that were solved by the last updates batch.
 
Last edited:
mer said:
Opinions will vary, but if you are following quarterly (the default when you install a release), about every 3 months the package repos are rebuilt and update just about everything. Some packages will get security updates in between. I tend to run "pkg upgrade -n" every 2-3 weeks to see what has an update. Then I decide "should I?".

If one waits for quarterly, and you are using ZFS, I would make a new BE before actually doing the pkg upgrade command. Quick and easy rollback if there is a problem.
Click to expand...
Is BE the same as a snapshot ?

I like the idea of a regular quarterly cadence. guess i'll do the occasional pkg upgrade -n and if there is a huge list then do the upgrade.
 
BE is "Boot Environment". If you are using "root on ZFS" freebsd-update will automatically create one for you. The utility "bectl" can be used to manually create a new BE and to list existing ones.
 
SirDice said:
P6 fixed a couple of userland issues. The version of the kernel is baked in at compile time and because it hasn't been updated it should still show the 'old' version. If you (re)build the kernel it will show the 'new' version, but there will be no functional changes, it's merely cosmetic.
Click to expand...
There is definitely a problem.

U

Thread 'Update to 14.1-RELEASE-p6 Incomplete'

This is happening across all machines. After the usual freebsd-update fetch, freebsd-update install cycle, world/base looks like it updated correctly, but the kernel did not.

freebsd-version shows:
14.1-RELEASE-p6

freebsd-version -k shows:
14.1-RELEASE-p5

I noticed this this morning when the nightly check on vuxml reported:
FreeBSD-kernel-14.1_5 is vulnerable:
FreeBSD -- Unbounded allocation in ctl(4) CAM Target Layer
CVE: CVE-2024-39281
WWW: https://vuxml.freebsd.org/freebsd/8caa5d60-a174-11ef-9a62-002590c1f29c.html

I ran:
freebsd-update -r 14.1-RELEASE-p6 upgrade

It...
 
Exactly what is the "definite problem"? That an update not including a kernel rebuild shows a different patch level or that you believe a freebsd-update to cover -p6 should have included this CVE?

My reading of the CVE you need a VM running on a FreeBSD host and the guest needs to trigger that command.
A lot of times things kernel related will get patched on -STABLE first and then migrated (cherry picked or some other mechanism) to a -RELEASE branch that is used for freebsd-update. Not sure of quickly this happens. Why is this important? Perhaps the specific fix for that CVE was not pushed to a place and rebuilt where freebsd-update picks it up.
 
mer said:
Exactly what is the "definite problem"? That an update not including a kernel rebuild shows a different patch level or that you believe a freebsd-update to cover -p6 should have included this CVE?

My reading of the CVE you need a VM running on a FreeBSD host and the guest needs to trigger that command.
A lot of times things kernel related will get patched on -STABLE first and then migrated (cherry picked or some other mechanism) to a -RELEASE branch that is used for freebsd-update. Not sure of quickly this happens. Why is this important? Perhaps the specific fix for that CVE was not pushed to a place and rebuilt where freebsd-update picks it up.
Click to expand...

282755 – `pkg audit` reports kernel vulnerability that was 'fixed' in a userland update?

bugs.freebsd.org bugs.freebsd.org
 
The CVE refers to a kernel module (ctl(4)), the version is baked in the kernel itself, not its modules. GENERIC doesn't have this driver included, so the kernel doesn't need to be rebuilt, only this particular kernel module. Because the kernel wasn't rebuilt the version of the kernel doesn't change.
 
mer said:
Exactly what is the "definite problem"?
Click to expand...
utkonos said:

282755 – `pkg audit` reports kernel vulnerability that was 'fixed' in a userland update?

bugs.freebsd.org bugs.freebsd.org
Click to expand...

This:
Rich (BB code): 
[1](0) ~ # freebsd-version -kru
14.1-RELEASE-p5
14.1-RELEASE-p5
14.1-RELEASE-p6
[2](0) ~ # /usr/local/etc/periodic/security/405.pkg-base-audit

Checking for security vulnerabilities in base (userland & kernel):
Database fetched: 2024-11-14T20:15+01:00
FreeBSD-kernel-14.1_5 is vulnerable:
  FreeBSD -- Unbounded allocation in ctl(4) CAM Target Layer
  CVE: CVE-2024-39281
  WWW: https://vuxml.FreeBSD.org/freebsd/8caa5d60-a174-11ef-9a62-002590c1f29c.html

1 problem(s) in 1 installed package(s) found.
0 problem(s) in 0 installed package(s) found.
[3](3) ~ # echo $?
3
The periodic audit script is also called by pkg-audit(8).
AFAIK, this error does not go away until the running kernel* has its baked-in version number changed to satisfy the above audit script. This suggests (falsely) that the patch p6 resolving the vulnerability has not been correctly applied.

I think, this strict notion of how the kernel version number is determined (for example by freebsd-version(8)) by a specific boot file, "clashes" with the general understanding of what one thinks of "the kernel".

Figure 7.1, from The Design and Implementation of the FreeBSD Operating System, 2nd Edition (source: gunion - video):

Chapter 7. I/O System Overview​

Figure 7.1 shows an overview of the entire kernel. [...]
Click to expand...
kernel.png


From a user perpective this is what we think the kernel is, meaning: the kernel in a running system; even Kirk McKusick thinks so ;)
If we see changes anywhere in "the entire kernel", then an obvious conclusion is that the kernel (version number) must have changed.

___
* that is, the kernel file that the OS has booted from:
Code: 
# sysctl kern.bootfile
kern.bootfile: /boot/kernel/kernel
 
SirDice said:
The CVE refers to a kernel module (ctl(4)), the version is baked in the kernel itself, not its modules. GENERIC doesn't have this driver included, so the kernel doesn't need to be rebuilt, only this particular kernel module. Because the kernel wasn't rebuilt the version of the kernel doesn't change.
Click to expand...
Exactly. And if you don't use ctl(4) you're not affected by the vulnerability.
 
The problem is that something is out of kilter with the way pkg versions and vulnerabilities are identified. What, exactly, is considered the kernel from a packaging/versioning viewpoint and how are CVEs to be attributed to the correct component so the auditing system works correctly?

There's clearly an inconsistency preventing accurate monitoring and reporting which could lead to false positives and possibly, more worrying, potential false negatives. Suppose the kernel were upgraded but the module got missed for some reason. Then people would have no warning of a live vulnerability. This might not affect me since I don't run VMs on my BSD machines, but it would affect anyone using FreeBSD to host a virtual server farm, for instance.

It therefore undermines the robustness of FreeBSD as a secure platform to run such services by reducing the reliability of the security auditing system. For FreeBSD it's a reputational issue. For high-end users it's a security and trustworthiness issue.

I understand the developers discuss this when it becomes manifest but before a solution is found a further upgrade hides the problem again and it loses priority because it's no longer a visible problem.
 
fmc000 said:
Exactly. And if you don't use ctl(4) you're not affected by the vulnerability.
Click to expand...
Sorry, but this is not a good practice. If the warning system in FreeBSD is producing a false positive there is a problem. You and SirDice being dismissive is counterproductive and ignoring an area that definitely needs to be improved.
 
utkonos said:
Sorry, but this is not a good practice. If the warning system in FreeBSD is producing a false positive there is a problem. You and SirDice being dismissive is counterproductive and ignoring an area that definitely needs to be improved.
Click to expand...
I'm not dismissing anything, I'm just stating the obvious. I never implied that everything is fine in the process.
 
That said, see the daily periodic mail complains day after day about a patched vulnerability may be confusing and is for sure annoying.
 
I don't think it's a question of code. I think it's a management issue about having consistent component identification so the correct component can be identified. The problem is not that there is anything wrong with the code. The problem is that the CVE is attributed to the kernel when it's actually not the kernel but a kernel module which had the vulnerability. It's about aligning packages with the components they contain and ensuring faults can be attributed to the actual part which needs updating.

That's not a coding issue. It's a policy/implementation issue. It needs a management decision from the top, not necessarily more volunteers coding.

I understand the Security Team will discuss it today.
 
You must log in or register to reply here.
Back
Top