Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Winston <wbe@UBEBLOCK.psr.com.invalid>
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: 14.1-RELEASE-p6 kernel same as -p5?
Date: Mon, 25 Nov 2024 12:21:12 -0500
Organization: A noiseless patient Spider
Lines: 25
Message-ID: <ydcyij44c7.fsf@UBEblock.psr.com>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Mon, 25 Nov 2024 18:21:17 +0100 (CET)
Injection-Info: dont-email.me; posting-host="56ba57182ebe4698d8e2bac0d91b0c03";
	logging-data="3041910"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19wIhdp82xVGOudFXGnOO9G"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:Rf2UUScDzk+X7nkCjmy60X7um8Q=
	sha1:H+toOpo7t/CabPB6gZkNxuvlZ7c=
Mail-Copies-To: never
Bytes: 1891

I used freebsd-update to binary upgrade an amd64 system running
14.1-RELEASE-p5 GENERIC to -p6.  Doing so observably updated
/boot/kernel/ctl.ko, presumably fixing CVE-2024-45289 (the ctl
unbounded allocation problem).

However, I see that /boot/kernel/kernel itself did not change:
it is the same as /boot/kernel.old/kernel in both content and date
and thus contains the string 14.1-RELEASE-p5.

The system has been rebooted.

Despite the upgrade and reboot, and likely because 'kernel' itself is
unchanged, the nightly pkg audit test of the kernel still reports:

FreeBSD-kernel-14.1_5 is vulnerable:
  FreeBSD -- Unbounded allocation in ctl(4) CAM Target Layer

So, my question is: Should the kernel have changed?

'freebsd-update IDS' says the SHA256 hash is wrong, but that's maybe to
be expected when comparing a built-from-scratch -p6 kernel with the -p5
kernel if freebsd-update figured it didn't need to be updated.

TIA,
 -WBE