Update to 14.1-RELEASE-p6 Incomplete

U

utkonos

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 cycled through the mirrors fetching metadata signature and then failing on each. After that it said no mirrors remaining, giving up.

Any ideas what is happening?
 
hi mate

no error, nothing to worry about

the kernel didnt get an update thats why its listing 14.1-RELEASE-p5

on my system

Code: 
freebsd-version

Code: 
14.1-RELEASE-p6

Code: 
freebsd-version -k

Code: 
14.1-RELEASE-p5
 
NapoleonWils0n said:
hi mate

no error, nothing to worry about

the kernel didnt get an update thats why its listing 14.1-RELEASE-p5

on my system

Code: 
freebsd-version

Code: 
14.1-RELEASE-p6

Code: 
freebsd-version -k

Code: 
14.1-RELEASE-p5
Click to expand...
Thanks for the quick reply, but why is the nightly vuXML check failing and reporting the problem with the kernel version:

14.1<=<14.1_6
[td]FreeBSD-kernel[/td]

The entry was added yesterday:
2024-11-13
[td]Entry[/td]

Something is not correct at the moment.
 
Sorry cut and paste made that look all jacked up. Here is a screenshot:

1731595310797.png
 
NapoleonWils0n said:
not sure about that

i think there is another thread about updating to freebsd 14.1 p6
and the the kernel still being 14.1 p5

cant remember the link off hand
Click to expand...
Also, reading the advisory itself, there is no mention of fixed in p5, it says fixed in p6

FreeBSD-SA-24:18.ctl Security Advisory
The FreeBSD Project

Topic: Unbounded allocation in ctl(4) CAM Target Layer

Category: core
Module: ctl
Announced: 2024-10-29
Credits: Synacktiv
Sponsored by: The FreeBSD Foundation, The Alpha-Omega Project
Affects: All supported versions of FreeBSD.
Corrected: 2024-10-11 15:53:17 UTC (stable/14, 14.1-STABLE)
2024-10-29 18:45:37 UTC (releng/14.1, 14.1-RELEASE-p6)
 
Erichans said:
These are based on an actual build, i.e NOT a binary update as by freebsd-update(8).
If you were to update your 14.1-RELEASE-p5 to p6 by building it from source, you'd get 14.1-p6 for the kernel too.
Click to expand...
I see in this thread the explanation from another angle:
A

Thread 'Inconsistent version after upgrade ?'

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...

Everything understood. Perhaps there is a way to improve how the nightly vuXML check operates so that a false positive like this is not reported?
 
And just so we're all clear: I should ignore what vuXML is telling me. It will report this false positive every night for the next N days until the next update makes it go away, correct?

This doesn't sound like the best general course of action, and I think there is room for improvement.
 
I have the same problem with my 13.4-RELEASE:
Code: 
]# freebsd-update fetch
src component not installed, skipped
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching metadata signature for 13.4-RELEASE from update2.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.

No updates needed to update system to 13.4-RELEASE-p2.
]# uname -r
13.4-RELEASE-p1

This makes little sense. If it is a kernel vulnerability supposedly fixed in the update, why wasn't the kernel updated?
 
i just meant that its not unusual to to have a mismatch between the kernel and the base
happens sometimes when there is no change in the kernel

had me baffled for a while first time it happened to me
 
utkonos said:
I noticed this this morning when the nightly check on vuxml reported:
FreeBSD-kernel-14.1_5 is vulnerable:
Click to expand...
kjpetrie said:
If it is a kernel vulnerability supposedly fixed in the update, why wasn't the kernel updated?
Click to expand...
cracauer@ said:
You are right, something is off here.
Click to expand...

My guess is that only changes in /usr/src/sys/kern/ will trigger an "actual" kernel update, like from freebsd-version -r; although FreeBSD-SA-24:18.ctl affects a part that is part of the kernel, OS-wise. It seems that these changes are not publicly labelled as such.

From FreeBSD Security Advisories:

>> 2024-08-07 FreeBSD-SA-24:06.ktrace:
Rich (BB code): 
Topic:          ktrace(2) fails to detach when executing a setuid binary

Category:       core
Module:         ktrace
   [...]
# fetch https://security.FreeBSD.org/patches/SA-24:06/ktrace.patch
SA-24:06/ktrace.patch:
Rich (BB code): 
--- sys/kern/kern_ktrace.c.orig
+++ sys/kern/kern_ktrace.c
I can't remember if this patch indeed triggered a kernel version change after using freebsd-update(8)


>> 2024-10-29 FreeBSD-SA-24:18.ctl:
Rich (BB code): 
Topic:          Unbounded allocation in ctl(4) CAM Target Layer

Category:       core
Module:         ctl
   [...]
# fetch https://security.FreeBSD.org/patches/SA-24:18/ctl.patch
SA-24:18/ctl.patch:
Rich (BB code): 
--- sys/cam/ctl/ctl.c.orig
+++ sys/cam/ctl/ctl.c
Note: /usr/src/sys/cam/ctl/ctl.c is not in directory /usr/src/sys/kern/

These two advisories quoted above are both of Category: core. According to 16.16.1. Format of a Security Advisory:
The Category refers to the affected part of the system which may be one of core, contrib, or ports. The core category means that the vulnerability affects a core component of the FreeBSD operating system. The contrib category means that the vulnerability affects software included with FreeBSD, such as BIND. The ports category indicates that the vulnerability affects software available through the Ports Collection.
Click to expand...

If my guess is correct, then users would benefit from an "upgrade" with respect to the vulnerability text message.
 
False alarm.

I didn't realize that the changed code is in a module, not kernel/kernel. The module is identical to my newly built one.

The module got rebuilt for freebsd-update in p6, but that does not rebuild the kernel binary, which carries the version number.

I don't know why my kernel is different, though.
 
Erichans said:
Curious: I assume you did verify that the differences in binaries of the two kernels were not solely caused by the version number change?
Click to expand...

No, the freebsd-update kernel is a bit bigger in code size:
Code: 
      text      data       bss        dec         hex   filename
  19926792   1598205   4693632   26218629   0x1901085   kernel
  19927320   1598205   4693632   26219157   0x1901295n  /boot/kernel/kernel
 
You must log in or register to reply here.
Back
Top