Hi. 
It looks like 6.5.3 addresses CVE-2023-25775, 6.5.0 addresses CVE-2023-4155, CVE-2023-1076, and more might be at stake.
6.4 branch ended at 6.4.16.
Don't we have a gap to close here?

TJ - looks like a rebuild of the nvidia 470 driver might be in order.   Who from build team does that one?

I believe TMB used to do it, but he has recently left Mageia. I don't know at this point who will be picking up the slack.

CC for comment/action on rebuilding nvidia470 for kernel 6.5.3

CC: (none) => ghibomgx, kernel

(In reply to christian barranco from comment #18)
> Hi. 
> It looks like 6.5.3 addresses CVE-2023-25775, 6.5.0 addresses CVE-2023-4155,
> CVE-2023-1076, and more might be at stake.
> 6.4 branch ended at 6.4.16.
> Don't we have a gap to close here?

IMHO 6.5.3 is too early, we might wait it stabilizes a bit (and there is already 6.5.5 out).

For the CVE-2023-25775, CVE-2023-4155, CVE-2023-1076, they were fixed in 6.4.16. Are there others?

For nvidia470, yes it won't work yet with 6.5.x.

So maybe a new 6.4 in a separate bug for now,
and continue with 6.5.5+ later (possibly in backport if useful until nvidia470 works with it.)

(In reply to Morgan Leijström from comment #23)
> So maybe a new 6.4 in a separate bug for now,
> and continue with 6.5.5+ later (possibly in backport if useful until
> nvidia470 works with it.)

6.4.16 seems the way to go, short term, indeed. Who will take care of it?

(In reply to christian barranco from comment #24)

> (In reply to Morgan Leijström from comment #23)
> > So maybe a new 6.4 in a separate bug for now,
> > and continue with 6.5.5+ later (possibly in backport if useful until
> > nvidia470 works with it.)
> 
> 6.4.16 seems the way to go, short term, indeed. Who will take care of it?

I might have a look at it during this weekend.

But before, we need to move current 6.5.3 to backport_testing otherwise 6.4.16 can't be built in updates_testing, because it will be rejected by the BS as an older release.

Hi,

According to the following link, Ubuntu was able to fix the problem between nvidia 470 and kernel 6.5: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-390/+bug/2028165

Moreover, I found that link: https://gist.github.com/joanbm/dfe8dc59af1c83e2530a1376b77be8ba

Best regards,

Nico.

CC: (none) => nicolas.salguero

Fixing the driver would definitely be the best solution. Anything else is just delaying the inevitable.

True, but the fact that the 6.5.3 is too early and even without nvidia I got for instance weird Oops.

We might get 6.4.16 now, then switch to 6.5.x later, once stabilized a bit, around 6.5.6 or there. Just two smaller steps instead of one. 6.4.16 would also stabilize the 6.4.9. We had 6.4.15 in updates_testing, but then vanished with 6.5.3.

To my knowledge the kernel 6.5.x for Ubuntu is for distro 23.10 which is not yet out, though closer. Stable release 23.04 is for instance with kernel 6.2, for which they use their own tree (+backported patches).

Sounds like a good plan.

Actually I think we can put current 6.5.3 in *backport* directly, skipping _testing, because it is already tested OK above and "only" have problem with nvidia470 which IMO we can live with until nvidia470 is fixed.

People trying backport should be prepared for such thing and this bug is easily found by searching here.

Hi Giuseppe

I am trying to build 6.4.16 (locally first) to support you.
I have successfully patched the kernel spec for my Surface Pro, so, I am giving it a try.

For patches, it is said to download the content of the 6.4 queue at https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree

However, there is no queue-6.4 (anymore?). Does it mean there is no patch to apply or does it mean this folder has been removed, to keep only the stable and LTS branches?

Thanks

Hi Giuseppe

I am trying to build 6.4.16 (locally first) to support you.
I have successfully patched the kernel spec for my Surface Pro, so, I am giving it a try.

For patches, it is said to download the content of the 6.4 queue at https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree

However, there is no queue-6.4 (anymore?). Does it mean there is no patch to apply or does it mean this folder has been removed, to keep only the stable and LTS branches?

Thanks

Created attachment 14010 [details]
spec file for 6.4.16

based on 6.4.15 that tmb had built, removing a few deprecated patches and assuming the patch queue for 6.4.16 is now empty

Created attachment 14011 [details]
Update of disable-mrproper-in-devel-rpms.patch

Update of disable-mrproper-in-devel-rpms.patch to build 6.4.16

Hi Giuseppe, the kernel 6.4.16 builds (at least for x86_64) with attachments 14010 and 14011.
I had saved locally the 6.4.15 src rpm that tmb had submitted; I used it as the starting point.
I assumed queue-6.4 is now empty; please, confirm my understanding.

Of course, I have run defconfig-updater.sh to update the defconfig files. I have not attached them here; too many.

(In reply to christian barranco from comment #35)

> Of course, I have run defconfig-updater.sh to update the defconfig files. I
> have not attached them here; too many.

(In reply to christian barranco from comment #34)
> Hi Giuseppe, the kernel 6.4.16 builds (at least for x86_64) with attachments
> 14010 and 14011.
> I had saved locally the 6.4.15 src rpm that tmb had submitted; I used it as
> the starting point.
> I assumed queue-6.4 is now empty; please, confirm my understanding.

Thanks for the attach.

The 6.4.16 gone EOL (end of life), which means that upstream tree branch for it won't receive extra patches. However before going EOL it still included the fixes for the vulnerabilities CVE-2023-25775, CVE-2023-4155, CVE-2023-1076.

Of course there might be other CVEs beyond that. AFAIK (if you know of other CVEs then post here), there were only two others CVE-2023-4921 and CVE-2023-5197 which AFAIK are still under investigation. Anyway those were already fixed in git upstream. Apparently even 6.5.3 should be vulnerable to them too. I've looked and we might backport that two fixes to 6.4 too (e.g. "net: sched: sch_qfq: Fix UAF in qfq_dequeue") from upstream. Quickly tried and applies.

There is also a new key to add with the new 6.4.16 patchset CONFIG_VIDEO_CAMERA_SENSOR=y, the defconfig-update.sh should add it automatically to the default new value.

As example (I'm not saing we should do it) of course a kernel major release tree could also be supported ad libitum, even outside official upstream, even beyond official EOL. E.g. some distro is still using this approach, using their own kernel tree. E.g. for kernel 6.2, backporting patches to it. Of course that's more expensive and those distro are commercial, so may pay many devs for this task.

(In reply to Morgan Leijström from comment #29)
> Sounds like a good plan.
> 
> Actually I think we can put current 6.5.3 in *backport* directly, skipping
> _testing, because it is already tested OK above and "only" have problem with
> nvidia470 which IMO we can live with until nvidia470 is fixed.
> 
> People trying backport should be prepared for such thing and this bug is
> easily found by searching here.

Only problem in moving to backport directly is that once we'll jump to 6.5.x, there will be a 6.5.x in core/updates|updates_testing, and an older 6.5.3 floating in core/backports.

Anyway the important is that it will be moved elsewhere so the other package can be issued.

(In reply to Giuseppe Ghibò from comment #36)
> There is also a new key to add with the new 6.4.16 patchset
> CONFIG_VIDEO_CAMERA_SENSOR=y, the defconfig-update.sh should add it
> automatically to the default new value.
> 
> 
Hi again. Yes, I have it!

Thanks for educating me ;)

Whatever kernel you settle on building, when you get to the i586 kernels, be aware that starting several kernels ago (Mageia 7?) TMB had to do something to them so that they would work with the Radeon RV200 graphics of my Dell Inspiron 5100. I don't know what it was, but I know that without the change the Xfce desktop was completely unusable. I also know he did not make the change to kernel-linus, which meant that I have been unable to test kernel-linus on real 32-bit hardware.

While we are on the subject, as you build your kernels, don't forget kernel-linus...

(In reply to Giuseppe Ghibò from comment #36)
> Of course there might be other CVEs beyond that. AFAIK (if you know of other
> CVEs then post here), there were only two others CVE-2023-4921 and
> CVE-2023-5197 which AFAIK are still under investigation. Anyway those were
> already fixed in git upstream. Apparently even 6.5.3 should be vulnerable to
> them too. I've looked and we might backport that two fixes to 6.4 too (e.g.
> "net: sched: sch_qfq: Fix UAF in qfq_dequeue") from upstream. Quickly tried
> and applies.

There is also CVE-2023-42756:
https://www.openwall.com/lists/oss-security/2023/09/27/2

The fix is here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7433b6d2afd512d04398c73aa984d1e285be125b

(In reply to Nicolas Salguero from comment #40)
> (In reply to Giuseppe Ghibò from comment #36)
> > Of course there might be other CVEs beyond that. AFAIK (if you know of other
> > CVEs then post here), there were only two others CVE-2023-4921 and
> > CVE-2023-5197 which AFAIK are still under investigation. Anyway those were
> > already fixed in git upstream. Apparently even 6.5.3 should be vulnerable to
> > them too. I've looked and we might backport that two fixes to 6.4 too (e.g.
> > "net: sched: sch_qfq: Fix UAF in qfq_dequeue") from upstream. Quickly tried
> > and applies.
> 
> There is also CVE-2023-42756:
> https://www.openwall.com/lists/oss-security/2023/09/27/2
> 
> The fix is here:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/
> ?id=7433b6d2afd512d04398c73aa984d1e285be125b


Thanks.

Hi.

6.4.16 built locally with CVE-2023-42756 patch.
It runs smoothly on a Surface Pro 9 (with additional linux-surface patches, as usual).

Giuseppe, would you need any support to submit it to our Mageia BS, just ask.

Created attachment 14019 [details]
CVE-2023-42756 patch

Created attachment 14020 [details]
spec file update

Attachment 14010 is obsolete: 0 => 1

(In reply to christian barranco from comment #42)
> Hi.
> 
> 6.4.16 built locally with CVE-2023-42756 patch.
> It runs smoothly on a Surface Pro 9 (with additional linux-surface patches,
> as usual).
> 
> Giuseppe, would you need any support to submit it to our Mageia BS, just ask.

The kernel 6.4.16 with the merged CVE's patches is ready on the mga9's svn. What I need is that the mirrors are cleaned in the updates_testing from kernel 6.5.3-1 otherwise the building system refuse it, because there are newer package in the same repo. I also asked again on sysadmin list yesterday.

In the meanwhile, waiting for the cleanup, a build is available here:

https://download.copr.fedorainfracloud.org/results/ghibo/mageia9-bonus/mageia-9-x86_64/06451500-kernel/

to test or rebuild from src.rpm locally, who wants.

Hi.
neoclust just told me that everything is cleared out and 6.4.16 can be pushed

(In reply to christian barranco from comment #46)
> Hi.
> neoclust just told me that everything is cleared out and 6.4.16 can be pushed

actually under building

Yes. Updates aren't "pushed" until they have been tested and validated by QA, and the advisory uploaded to SVN.

Just as a reminder, it has been customary for kernel updates to include pre-built kernel modules for our VirtualBox, so don't forget those. If you don't include them, users who have installed our VirtualBox without dkms (perfectly possible) will suddenly see it cease to function.

See the list in Comment 0 to see what TMB always included, and what our users will expect.

(In reply to Thomas Andrews from comment #48)
> Yes. Updates aren't "pushed" until they have been tested and validated by
> QA, and the advisory uploaded to SVN.
> 
> Just as a reminder, it has been customary for kernel updates to include
> pre-built kernel modules for our VirtualBox, so don't forget those. If you
> don't include them, users who have installed our VirtualBox without dkms
> (perfectly possible) will suddenly see it cease to function.
> 
> See the list in Comment 0 to see what TMB always included, and what our
> users will expect.

Thanks for remind.

So in todo list we have:

- kmod-virtualbox
- kmod-xtables-addons
- kernel-linus-6.4.16-1 with the same CVEs.

(In reply to Thomas Andrews from comment #48)
> Yes. Updates aren't "pushed" until they have been tested and validated by
> QA, and the advisory uploaded to SVN.
> 
Indeed and I meant submitted, not pushed, from a BS terminology. Sorry for the confusion.

mga9-64 OK here

HW: Intel i7-870, P55 chipset, AMD Radeon RX6400

SW: Plasma X11, Normal desktop apps

VirtualBox: MSW7 guest OK: internet videos, USB2 flashstick, host folder sharing, bidirectional clipboard, and drag file from Dolphin to Explorer (the reverse fail as usual - may be operator error regarding security configuring?).

suspend-resume not tested, not reliable with any other kernel yet on this system
(even got worse changing from nvidia to AMD)


$ uname -a
Linux svarten.tribun 6.4.16-desktop-1.mga9 #1 SMP PREEMPT_DYNAMIC Sat Sep 30 10:14:58 UTC 2023 x86_64 GNU/Linux

$ rpm -qa | grep 6.4.16-1
kernel-desktop-6.4.16-1.mga9
kernel-userspace-headers-6.4.16-1.mga9
lib64bpf1-6.4.16-1.mga9
cpupower-6.4.16-1.mga9

$ rpm -qa | grep virtualbox-ker
virtualbox-kernel-6.1.45-desktop-1.mga8-7.0.10-2.5.mga8
virtualbox-kernel-6.4.16-desktop-1.mga9-7.0.10-32.mga9

If no one else try nvidia470, I can change back to my old GTX750 and test.

I dont have any package at all containing "-latest".
Do we still need them?
Needed so updates works on systems that have them?

(In reply to Morgan Leijström from comment #51)

> I dont have any package at all containing "-latest".

> Do we still need them?

The -latest are still there, see on mirrors:

https://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/9/x86_64/media/core/updates_testing/

it's on cauldron that was removed. Indeed I've a vague idea that we could roll back (for next kernel releases) to the old kernel naming scheme (those of mga8), where the version is within the package name; we tried this new scheme, and at the beginning I was for it, but in current scheme multiple versioning within the same name doesn't work much good with urpmi when you have to move fast to older or any other versions; with older scheme instead is blazingly faster.

(In reply to Giuseppe Ghibò from comment #52)
> The -latest are still there

I mean, with the new naming scheme, I guess it does not matter if users have installed the "-latest" packages; the kernel packages will get updated anyway because of "newer" name?

(In reply to Morgan Leijström from comment #53)
> (In reply to Giuseppe Ghibò from comment #52)
> > The -latest are still there
> 
> I mean, with the new naming scheme, I guess it does not matter if users have
> installed the "-latest" packages; the kernel packages will get updated
> anyway because of "newer" name?

In theory yes it shouldn't make difference (though there could be some package requiring -latest somewhere...), because the system sees just "kernel-desktop" as package name installed, so any release newer should be automatically updated (like for any other package).

(In reply to Giuseppe Ghibò from comment #54)
> In theory yes

Theory acknowledged: on my laptop i removed -latest packages, enabled updates testing as updates media, and drakrpm listed the kernel when I told it to list updates. (which i will also test on that laptop)

(In reply to Morgan Leijström from comment #51)
> If no one else try nvidia470, I can change back to my old GTX750 and test.

Nvidia470 builds and runs fine with my Nvidia GTX750 card :)

I also verified that dkms-built virtualbox module works.
( I removed virtualbox-kernel-* and at next boot autorebuild built the module as system have dkms-virtualbox-7.0.10-3.mga9 installed )

mga9-64 OK on my laptop Dell Precision M6300;
CPU: Intel(R) Core(TM)2 Duo CPU  T7500
GPU: G84GLM [Quadro FX 1600M], using kernel modesetting
Wifi: PRO/Wireless 3945ABG [Golan]

Plasma, desktop apps, firefox internet video, suspend-resume

MGA9-32 on Foolishness, my ancient Dell Inspiron 5100. P4 processor, Radeon RV200 graphics, old Atheros-based wifi, 32-bit Xfce system using the desktop kernel.

Booted into the 6.4.9-4 kernel. Removed the 6.5.3 kernel-desktop, kernel-desktop-latest, and cpupower. Installed kernel-dektop-latest and cpupower for the 6.4.9-4 kernel.

With no current rpm list, I used kernel* and cpupower* in qarepo to get the i586 packages. Updated with MCC, with no issues.

Rebooted to a working desktop, tried a few common apps, and all worked.

Hello,

Tested on real Mageia Plasma x86_64 installation, I still have sleep problems on my computer reported here: https://bugs.mageia.org/show_bug.cgi?id=32082

MGA9-64 Plasma system on an i5-2500, Intel graphics, wired Internet. This is my production system. 

Reluctantly removed the 6.5.3 kernel, as it had been functioning perfectly. Installed the appropriate "latest" packages for kernel 6.4.9-4. Used qarepo to download kernel, virtualbox, and cpupower packages with wild cards.

No installation issues. After the reboot tried this and that, including virtualbox, with no apparent issues so far.

MGA9-64 Plasma on a HP Probook 6550b, i3 M350, Intel graphics, Broadcom wifi.

Procedure the same as with other hardware already using the 6.5.3 kernel. No installation issues. Broadcom-wl module built and installed successfully.

After the reboot, no issues to report. Wifi working with Network Manager, including a Surfshark VPN. Firefox, Thunderbird, vlc all OK.

Looks good on this hardware. I also have a MGA9-32 install on this machine, using the server kernel. Will test that this evening, after work.

Hi,

CVE-2023-42754 was announced here:
https://www.openwall.com/lists/oss-security/2023/10/02/8
It is fixed by:
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=0113d9c9d1cc

Best regards,

Nico.

The advisory from comment 0 is no longer valid. I don't see a new advisory for the 6.4.16 kernel.

CC: (none) => marja11

I see version update in progress:
6.4.16-1 is no longer, -2 is in updates testing, -3 is building

In Mageia 9 Stable with 6.4.9??? Or do I have the update repos wrong? I don't think so, I've reinstalled them twice...

Installed 6.14.16-2 in Vbox. Works fine for the moment.

In my laptop the sleep no work still, reported in bug 32082

(In reply to Nicolas Salguero from comment #62)

> Hi,
> 
> CVE-2023-42754 was announced here:
> https://www.openwall.com/lists/oss-security/2023/10/02/8
> It is fixed by:
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/
> ?id=0113d9c9d1cc
> 
> Best regards,
> 
> Nico.

That is actually included in kernel-6.4.16-3.mga9 in updates_testing.

If 6.4.16-3 is ready for testing, please publish a full list of the packages involved, so that we can be sure we don't miss any when using qarepo. You should have one anyway, for the advisory.

lscpu
~
Model name:            AMD E1-6010 APU with AMD Radeon R2 Graphics

uname -a
Linux localhost.localdomain 6.4.9-desktop-4.mga9 #1 SMP PREEMPT_DYNAMIC Sat Aug 19 15:07:44 UTC 2023 x86_64 GNU/Linux


To satisfy dependencies, the following packages are going to be installed:
  Package                        Version      Release       Arch
(medium "QA Testing (64-bit)")
  kernel-desktop                 6.4.16       3.mga9        x86_64
  kernel-desktop-devel           6.4.16       3.mga9        x86_64
  kernel-desktop-devel-latest    6.4.16       3.mga9        x86_64
  kernel-userspace-headers       6.4.16       3.mga9        x86_64
144MB of additional disk space will be used.
94MB of packages will be retrieved.
Proceed with the installation of the 4 packages? (Y/n) y

~
virtualbox (7.0.10-3.mga9): Installing module.

reboot
~
uname -a
Linux localhost.localdomain 6.4.16-desktop-3.mga9 #1 SMP PREEMPT_DYNAMIC Tue Oct 10 16:51:28 UTC 2023 x86_64 GNU/Linux

Firefox -ok
Kwrite -ok
VirtualBox - booted up Mga9 Live Xfce i586 to desktop - ok
played some multimedia files - sound & video ok

CC: (none) => westel

mga9-64 OK here, 6.4.16-desktop-3.mga9

HW: Intel i7-870, P55 chipset, Nvidia GTX750

SW: Plasma X11, Normal desktop apps

DKMS builds nvidia470 and VirtualBox modules.

VirtualBox: MSW7 guest OK: internet videos, USB2 flashstick, host folder sharing, bidirectional clipboard, dynamic window resizing.

suspend-resume works, only tested a couple cycles, not reliable with any other kernel yet on this system.

Summary: Update request: kernel-6.4.16-1.mga9 => Update request: kernel-6.4.16-3.mga9

Files list for x86_64 is this:

bpftool-6.4.16-3.mga9.x86_64.rpm
cpupower-6.4.16-3.mga9.x86_64.rpm
cpupower-devel-6.4.16-3.mga9.x86_64.rpm
kernel-desktop-6.4.16-3.mga9.x86_64.rpm
kernel-desktop-devel-6.4.16-3.mga9.x86_64.rpm
kernel-desktop-devel-latest-6.4.16-3.mga9.x86_64.rpm
kernel-desktop-latest-6.4.16-3.mga9.x86_64.rpm
kernel-doc-6.4.16-3.mga9.noarch.rpm
kernel-server-6.4.16-3.mga9.x86_64.rpm
kernel-server-devel-6.4.16-3.mga9.x86_64.rpm
kernel-server-devel-latest-6.4.16-3.mga9.x86_64.rpm
kernel-server-latest-6.4.16-3.mga9.x86_64.rpm
kernel-source-6.4.16-3.mga9.noarch.rpm
kernel-userspace-headers-6.4.16-3.mga9.x86_64.rpm
lib64bpf-devel-6.4.16-3.mga9.x86_64.rpm
lib64bpf1-6.4.16-3.mga9.x86_64.rpm
perf-6.4.16-3.mga9.x86_64.rpm
virtualbox-kernel-6.4.16-desktop-3.mga9-7.0.10-33.mga9.x86_64.rpm
virtualbox-kernel-6.4.16-server-3.mga9-7.0.10-33.mga9.x86_64.rpm
xtables-addons-kernel-6.4.16-desktop-3.mga9-3.24-48.mga9.x86_64.rpm
xtables-addons-kernel-6.4.16-server-3.mga9-3.24-48.mga9.x86_64.rpm

still missed the newer kernel-linus, coming soon.

Can someone please create an advisory with:

Fixed CVEs

Summary line

Description

SRPMs

links to listed CVEs are not needed, our script adds them automatically. Other links about the update are welcome, though (e.g. when a patch was taken from a different distribution)

MGA9-64 Xfce on Acer Aspire 5253
No installation issues0
No problems with wifi, internet  access, access to NFS shares, LO file types.
Isn't there something like xtables-addons-kernel-server-latest missing from the list in Comment 71?

CC: (none) => herman.viaene

MGA9-64, GNOME, AMD Ryzen 5600, Nvidia GT1050


The following 5 packages are going to be installed:

- cpupower-6.4.16-3.mga9.x86_64
- kernel-desktop-6.4.16-3.mga9.x86_64
- kernel-desktop-latest-6.4.16-3.mga9.x86_64
- kernel-userspace-headers-6.4.16-3.mga9.x86_64
- lib64bpf1-6.4.16-3.mga9.x86_64

89MB of additional disk space will be used.

Also added the desktop-devel kernel objects for nvidia linking.

----rebooted

system relinked to driver properly

- Nvidia working
- Bluetooth functioning
- system behaving as expected.

mga9-64 OK on my laptop Dell Precision M6300;
CPU: Intel(R) Core(TM)2 Duo CPU  T7500
GPU: G84GLM [Quadro FX 1600M], using kernel modesetting
Wifi: PRO/Wireless 3945ABG [Golan]

Plasma, desktop apps, firefox internet video, suspend-resume

This is with all other updates incl testing; i.e x11 and mesa.

MGA9-64

Several Platforms
- Plasma installation (AMD Ryzen 2600) - Nouveau working
- Basic Nextcloud, Samba server (Intel) - server kernel - working
- Intel Laptop - working as expected

server, desktop kernels validated.

(In reply to Marja Van Waes from comment #72)
> Can someone please create an advisory with:

Or please tell me whether this is correct:
> 
> Fixed CVEs
CVE-2023-1076
CVE-2023-4155
CVE-2023-4921
CVE-2023-5197
CVE-2023-25775
CVE-2023-42754
CVE-2023-42756
> 
> Summary line
Updated kernel packages fix security vulnerabilities
> 
> Description

This kernel update is based on upstream 6.4.16 and fixes or
adds mitigations for atleast the following security issues:

A flaw was found in the Linux Kernel. The tun/tap sockets have their socket UID hardcoded to 0 due to a type confusion in their initialization function. While it will be often correct, as tuntap devices require CAP_NET_ADMIN, it may not always be the case, e.g., a non-root user only having that capability. This would make tun/tap sockets being incorrectly treated in filtering/routing decisions, possibly bypassing network filters. CVE-2023-1076

A flaw was found in KVM AMD Secure Encrypted Virtualization (SEV) in the Linux kernel. A KVM guest using SEV-ES or SEV-SNP with multiple vCPUs can trigger a double fetch race condition vulnerability and invoke the `VMGEXIT` handler recursively. If an attacker manages to call the handler multiple times, they can trigger a stack overflow and cause a denial of service or potentially guest-to-host escape in kernel configurations without stack guard pages (`CONFIG_VMAP_STACK`). CVE-2023-4155

A use-after-free vulnerability in the Linux kernel's net/sched: sch_qfq component can be exploited to achieve local privilege escalation. When the plug qdisc is used as a class of the qfq qdisc, sending network packets triggers use-after-free in qfq_dequeue() due to the incorrect .peek handler of sch_plug and lack of error checking in agg_dequeue(). We recommend upgrading past commit 8fc134fee27f2263988ae38920bc03da416b03d8. CVE-2023-4921

A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation. Addition and removal of rules from chain bindings within the same transaction causes leads to use-after-free. We recommend upgrading past commit f15f29fd4779be8a418b66e9d52979bb6d6c2325. CVE-2023-5197

Improper access control in the Intel(R) Ethernet Controller RDMA driver for linux before version 1.9.30 may allow an unauthenticated user to potentially enable escalation of privilege via network access. CVE-2023-25775

A NULL pointer dereference flaw was found in the Linux kernel ipv4 stack. The socket buffer (skb) was assumed to be associated with a device before calling __ip_options_compile, which is not always the case if the skb is re-routed by ipvs. This issue may allow a local user with CAP_NET_ADMIN privileges to crash the system. CVE-2023-42754

A flaw was found in the Netfilter subsystem of the Linux kernel. A race condition between IPSET_CMD_ADD and IPSET_CMD_SWAP can lead to a kernel panic due to the invocation of `__ip_set_put` on a wrong `set`. This issue may allow a local user to crash the system. CVE-2023-42756
> 
> SRPMs

kernel-6.4.16-3.mga9
kmod-virtualbox-7.0.10-33.mga9
kmod-xtables-addons-3.24-48.mga9


> 
> links to listed CVEs are not needed, our script adds them automatically.
> Other links about the update are welcome, though (e.g. when a patch was
> taken from a different distribution)

Mageia9, x86_64

 Type: Mini-pc System: Entroware product: Aura ED02R5 v: 1A
 Mobo: Intel model: NUC12WSBi7
 12-core (4-mt/8-st) 12th Gen Intel Core i7-1260P 
 Intel Alder Lake-P Integrated Graphics driver: i915
 Intel Alder Lake-P PCH CNVi WiFi driver: iwlwifi

Installed all the packages and rebooted to the desktop kernel.  No problems.  Installed VirtualBox and launched a 32-bit Mageia client (mageia10 !).  Huge scheduled update of ~1250 packages.

Desktop running fine for an hour or so already.

MGA9-32bit, Xfce, Ryzen 2600, Nouveau

- cpupower-6.4.16-3.mga9.i586
- kernel-desktop-6.4.16-3.mga9.i586
- kernel-desktop-latest-6.4.16-3.mga9.i586
- kernel-userspace-headers-6.4.16-3.mga9.i586
- libbpf1-6.4.16-3.mga9.i586

---rebooted

$ uname -a
Linux localhost 6.4.16-desktop-3.mga9 #1 SMP PREEMPT_DYNAMIC Tue Oct 10 18:35:41 UTC 2023 i686 GNU/Linux


- sound is working
- video is working
- browser is working
- libreoffice is working

Whiteboard: (none) => MGA9-32-OK

CPU: dual core Intel Pentium Dual T2370 (-MCP-)

Mageia 9 i586 plasma

Install
cpupower-6.4.16-3.mga9.i586.rpm
kernel-desktop-6.4.16-3.mga9.i586.rpm
kernel-desktop-devel-6.4.16-3.mga9.i586.rpm
kernel-server-6.4.16-3.mga9.i586.rpm
kernel-server-devel-6.4.16-3.mga9.i586.rpm
kernel-userspace-headers-6.4.16-3.mga9.i586.rpm
libbpf-devel-6.4.16-3.mga9.i586.rpm
libbpf1-6.4.16-3.mga9.i586.rpm

Reboot, test kernel desktop
Audio & Video works
Wifi works
Youtube on firefox works


Reboot, test kernel server
Audio & Video works
Wifi works
Youtube on firefox works

MGA9-32 Xfce on Foolishness, my Dell Inspiron 5100, 32-bit P4, Radeon RV200 graphics, using kernel-desktop.

Everything looks good here, too.

MGA9-64 Plasma on an HP Pavilion 15, AMD A8-4555, AMD HD 7600G graphics. Looks good here, too.

So is this ready to go out? Any more tests needed?

I too think it looks good.
Same for linus variant, BTW.
I think we let the kernel maintainer make the final decision like tmb used to.

Hi Morgan,
No worries, just wanted to flag i586 is now tested.  The maintainer can flag the rest.

(In reply to Marja Van Waes from comment #77)
> (In reply to Marja Van Waes from comment #72)
> > Can someone please create an advisory with:
> 
> Or please tell me whether this is correct:
<snip>

Not good enough, in several previous kernel advisories, I see this added:

"For other upstream fixes in this update, see the referenced changelogs."
+ several links to pages on https://cdn.kernel.org/pub/linux/kernel/

Yes, TMB always did the kernel advisories. 

Sigh. I miss him, probably not for the last time.

Testers, be aware that the list in comment 71 is missing the "latest" packages for the virtualbox modules. If you use it verbatim in qarepo, and you don't have dkms-virtualbox installed, the prebuilt virtualbox modules will NOT be updated. 

The packages are there, they were just left off the published list. This happened to me on one install, and virtualbox wouldn't work. If it happens to you, run qarepo with "virtualbox*" in the rpm list. That will get them, and then you can update them. That's what I did, and now virtualbox works OK.

(In reply to Thomas Andrews from comment #87)
> Testers, be aware that the list in comment 71 is missing the "latest"
> packages for the virtualbox modules. If you use it verbatim in qarepo, and
> you don't have dkms-virtualbox installed, the prebuilt virtualbox modules
> will NOT be updated. 
> 
> The packages are there, they were just left off the published list. This
> happened to me on one install, and virtualbox wouldn't work. If it happens
> to you, run qarepo with "virtualbox*" in the rpm list. That will get them,
> and then you can update them. That's what I did, and now virtualbox works OK.

You're right, I missed those two packages from the list:

virtualbox-kernel-desktop-latest-7.0.10-33.mga9.x86_64.rpm
virtualbox-kernel-server-latest-7.0.10-33.mga9.x86_64.rpm

Good find TJ.

I tested the DKMS local automatic building of nvidia470 and virtualbox modules, then the modules packages are not needed.

IMO we can ship this, as well as the linus kernel, if devs agree.
...and when advisory is put in place - note add in comment 88.

(In reply to Morgan Leijström from comment #90)

> IMO we can ship this, as well as the linus kernel, if devs agree.
> ...and when advisory is put in place - note add in comment 88.

IMHO we can ship too, if there aren't further report.

Hi,

CVE-2023-5178 (Linux NVMe-oF/TCP Driver - UAF in `nvmet_tcp_free_crypto`) was announced here:
https://www.openwall.com/lists/oss-security/2023/10/15/1

Best regards,

Nico.

(In reply to Nicolas Salguero from comment #92)

> Hi,
> 
> CVE-2023-5178 (Linux NVMe-oF/TCP Driver - UAF in `nvmet_tcp_free_crypto`)
> was announced here:
> https://www.openwall.com/lists/oss-security/2023/10/15/1
> 
> Best regards,
> 
> Nico.

I think we can exit with the current 6.4.16-3.mga9 for now and then add the one for 2023-5178 later. BTW, is there are patch available for it?

(In reply to Giuseppe Ghibò from comment #93)
> (In reply to Nicolas Salguero from comment #92)
> 
> > Hi,
> > 
> > CVE-2023-5178 (Linux NVMe-oF/TCP Driver - UAF in `nvmet_tcp_free_crypto`)
> > was announced here:
> > https://www.openwall.com/lists/oss-security/2023/10/15/1
> > 
> > Best regards,
> > 
> > Nico.
> 
> I think we can exit with the current 6.4.16-3.mga9 for now and then add the
> one for 2023-5178 later. BTW, is there are patch available for it?

Quoting myself... according to https://lore.kernel.org/all/20231004173226.5992-1-sj@kernel.org/T/, patch is still in progress.

What about what was seen in bug 32082?
Greetings!

(In reply to Jose Manuel López from comment #95)

> What about what was seen in bug 32082?
> Greetings!

The patch 1050 will be tried to be disabled in a next build (6.4.16-4.mga9), and probaly 1030 too, but first we need to release with -3.mga9, otherwise -4.mga9 would discard the previous one, as updates_testing doesn't keep multiple versions.

@ Giuseppe 

can you please add an advisory?

My attempt in comment 77 wasn't good enough, as explained in comment 85

Besides, creating advisories is the task of packagers, I only upload them to SVN ;-)

An example of an uploaded kernel advisory, can be found here:
https://svnweb.mageia.org/advisories/32168.adv?revision=14921&view=markup

All that information is needed, except the last line (ID:MGA*) which is created later.

(In reply to Marja Van Waes from comment #97)
> @ Giuseppe 
> 
> can you please add an advisory?
> 
> My attempt in comment 77 wasn't good enough, as explained in comment 85
> 
> Besides, creating advisories is the task of packagers, I only upload them to
> SVN ;-)
> 
> An example of an uploaded kernel advisory, can be found here:
> https://svnweb.mageia.org/advisories/32168.adv?revision=14921&view=markup
> 
> All that information is needed, except the last line (ID:MGA*) which is
> created later.

Actually I'm busy on another thing, so if you can help with this stuff it would be of helpful. The package list is the same as of comment #71, plus virtualbox-kernel-desktop-latest-7.0.10-33.mga9.x86_64.rpm and virtualbox-kernel-server-latest-7.0.10-33.mga9.x86_64.rpm that was spotted in comment #87 and #88.

Need to improve, please give a check

Advisory
Updates to kernel 6.4 series fix vulnerabilities

References:


Packages in 9/Core Updates Testing

i586:
bpftool-6.4.16-3.mga9
cpupower-6.4.16-3.mga9
cpupower-devel-6.4.16-3.mga9
kernel-desktop586-6.4.16-3.mga9
kernel-desktop586-devel-6.4.16-3.mga9
kernel-desktop586-devel-latest-6.4.16-3.mga9
kernel-desktop586-latest-6.4.16-3.mga9
kernel-desktop-6.4.16-3.mga9
kernel-desktop-devel-6.4.16-3.mga9
kernel-desktop-devel-latest-6.4.16-3.mga9
kernel-desktop-latest-6.4.16-3.mga9
kernel-doc-6.4.16-3.mga9.noarch.rpm
kernel-server-6.4.16-3.mga9
kernel-server-devel-6.4.16-3.mga9
kernel-server-devel-latest-6.4.16-3.mga9
kernel-server-latest-6.4.16-3.mga9
kernel-source-6.4.16-3.mga9.noarch.rpm
kernel-userspace-headers-6.4.16-3.mga9
libbpf1-6.4.16-3.mga9
libbpf-devel-6.4.16-3.mga9
perf-6.4.16-3.mga9

xtables-addons-kernel-6.4.16-desktop-3.mga9-3.24-48.mga9
xtables-addons-kernel-6.4.16-desktop586-4.mga9-3.24-48.mga9
xtables-addons-kernel-6.4.16-server-1.mga9-3.24-48.mga9
xtables-addons-kernel-desktop586-latest-3.24-48.mga9
xtables-addons-kernel-desktop-latest-3.24-48.mga9
xtables-addons-kernel-server-latest-3.24-48.mga9

x86_64:
bpftool-6.4.16-3.mga9
cpupower-6.4.16-3.mga9
cpupower-devel-6.4.16-3.mga9
kernel-desktop-6.4.16-3.mga9
kernel-desktop-devel-6.4.16-3.mga9
kernel-desktop-devel-latest-6.4.16-3.mga9
kernel-desktop-latest-6.4.16-3.mga9
kernel-doc-6.4.16-3.mga9.noarch.rpm
kernel-server-6.4.16-3.mga9
kernel-server-devel-6.4.16-3.mga9
kernel-server-devel-latest-6.4.16-3.mga9
kernel-server-latest-6.4.16-3.mga9
kernel-source-6.4.16-3.mga9.noarch.rpm
kernel-userspace-headers-6.4.16-3.mga9
lib64bpf1-6.4.16-3.mga9
lib64bpf-devel-6.4.16-3.mga9
perf-6.4.16-3.mga9

virtualbox-kernel-6.4.16-desktop-3.mga9-7.0.10-33.mga9
virtualbox-kernel-6.4.16-server-3.mga9-7.0.10-33.mga9
virtualbox-kernel-desktop-latest-7.0.10-33.mga9
virtualbox-kernel-server-latest-7.0.10-33.mga9

xtables-addons-kernel-6.4.16-desktop-3.mga9-3.24-48.mga9
xtables-addons-kernel-6.4.16-server-3.mga9-3.24-48.mga9
xtables-addons-kernel-desktop-latest-3.24-48.mga9
xtables-addons-kernel-server-latest-3.24-48.mga9

SRPMs

kernel-6.4.16-3.mga9
kmod-virtualbox-7.0.10-33.mga9
kmod-xtables-addons-3.24-48.mga9

Status comment: Updated Advisory in Comment#99 => Updated Advisory in Comment#100

(In reply to Giuseppe Ghibò from comment #98)
> (In reply to Marja Van Waes from comment #97)
> > @ Giuseppe 
> > 
> > can you please add an advisory?
> > 

> 
> Actually I'm busy on another thing, so if you can help with this stuff it
> would be of helpful. The package list is the same as of comment #71, plus
> virtualbox-kernel-desktop-latest-7.0.10-33.mga9.x86_64.rpm and
> virtualbox-kernel-server-latest-7.0.10-33.mga9.x86_64.rpm that was spotted
> in comment #87 and #88.

Advisory from comment 77 added to SVN, with the addition to the description of:

  For other upstream fixes in this update, see the referenced changelogs.

and to the references of:

 - https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.4.10
 - https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.4.11
 - https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.4.12
 - https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.4.13
 - https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.4.14
 - https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.4.15
 - https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.4.16

Current Mageia 9 version is 6.4.9, right? I didn't find a newer version in updates.
Please remove the "advisory" keyword if it needs to be changed. It also helps when obsolete advisories are tagged as "obsolete"

Status comment: Updated Advisory in Comment#100 => (none)
Keywords: (none) => advisory

The uploaded advisory can be seen here:

https://svnweb.mageia.org/advisories/32296.adv?revision=15124&view=markup

Please tell me and remove the advisory keyword, when there is something wrong with it.

(In reply to katnatek from comment #100)
> Need to improve, please give a check
> 
> Advisory
> Updates to kernel 6.4 series fix vulnerabilities
<snip>
Thanks for your help :-)

In the uploaded advisories, only the SRPMs are mentioned, but not the RPMs.

The reason we ask packagers to put the RPMs in the suggested advisory, is that QA testers need to know exactly which packages need to be tested.

(In reply to Marja Van Waes from comment #101)
> Current Mageia 9 version is 6.4.9, right? I didn't find a newer version in
> updates.
> Please remove the "advisory" keyword if it needs to be changed. It also
> helps when obsolete advisories are tagged as "obsolete"

Yes it's the same I have

I'm going to say that Marja's advisory (https://svnweb.mageia.org/advisories/32296.adv?revision=15124&view=markup) look good to me, but wait to others give a check

MGA9-64, Cinnnamon, AMD A6-3420M APU 


The following 5 packages are going to be installed:

- cpupower-6.4.16-3.mga9.x86_64
- kernel-desktop-6.4.16-3.mga9.x86_64
- kernel-desktop-latest-6.4.16-3.mga9.x86_64
- kernel-userspace-headers-6.4.16-3.mga9.x86_64
- lib64bpf1-6.4.16-3.mga9.x86_64

95MB of additional disk space will be used.

rebooted, also installed a backlog of updates

machine is behaving correctly with browswer, etc.

I think testing is enough, and advisory looks good in structure, and all CVE numbers listed are mentioned in this bug as patched (i have not verified they are in, nor the description texts)

Approving by the sum of positive indications from all, and no negative.

Whiteboard: MGA9-32-OK => MGA9-64-OK MGA9-32-OK
Keywords: (none) => validated_update

(In reply to Morgan Leijström from comment #106)
> I think testing is enough, and advisory looks good in structure, and all CVE
> numbers listed are mentioned in this bug as patched (i have not verified
> they are in, nor the description texts)
> 
> Approving by the sum of positive indications from all, and no negative.

I think it's ok.

Good. (please also check linus)

I just realised we have not tested the desktop586 variant, (the one for eldest hardware we support) but we seldom do.

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2023-0295.html

Resolution: (none) => FIXED
Status: NEW => RESOLVED

(In reply to Nicolas Salguero from comment #92)
> Hi,
> 
> CVE-2023-5178 (Linux NVMe-oF/TCP Driver - UAF in `nvmet_tcp_free_crypto`)
> was announced here:
> https://www.openwall.com/lists/oss-security/2023/10/15/1
> 
> Best regards,
> 
> Nico.

Version with fixes for CVE-2023-5178 is kernel-6.4.16-5.mga9 (and kernel-linus-6.5.16-5.mga9), among others such as CVE-2023-39189, CVE-2023-5345, CVE-2023-5633, CVE-2023-5717, CVE-2023-46813, as well as bug #32082.

I think we could open a new bug for tracking it.

(In reply to Giuseppe Ghibò from comment #110)

> [...]
> Version with fixes for CVE-2023-5178 is kernel-6.4.16-5.mga9 (and
> kernel-linus-6.5.16-5.mga9), among others such as CVE-2023-39189,
> [...]

of course actually in updates_testing.

With this update having been pushed, and with now 112 comments, yes, a new bug is the way to go.

@ Guiseppe: if ready for testing please open
"Update request: kernel-6.4.16-5.mga9" and assign to QA

And ditto for Linus kernel.

That said I have already been using desktop-5 a couple hours no problem on my main system.

(In reply to Morgan Leijström from comment #113)
> @ Guiseppe: if ready for testing please open
> "Update request: kernel-6.4.16-5.mga9" and assign to QA
> 
> And ditto for Linus kernel.
> 
> That said I have already been using desktop-5 a couple hours no problem on
> my main system.

https://bugs.mageia.org/show_bug.cgi?id=32482 for the request, not yet for kernel linus.

Please be sure to run this up as a new bug and document ready for QA testing since the bug version has been released.

As I mentioned in another related bug, the latest version 6.4.16-5 works fine for me. Video, internet, apps, audio, everything seems fine.

I no longer have suspension problems on my computer.