In the Linux kernel, the following vulnerability has been resolved:

netfilter: nftables: reject immediate NFQUEUE verdict

nftqueue is always used from userspace nftables to deliver the NFQUEUE verdict. Immediately emitting an NFQUEUE verdict is never used by the userspace nft tools, so reject immediate NFQUEUE verdicts.

The arp family does not provide queue support, but such an immediate verdict is still reachable. Globally reject NFQUEUE immediate verdicts to address this issue.

In the Linux kernel, the following vulnerability has been resolved:

accel/ivpu: Fix general protection fault in ivpubolist()

Check if ctx is not NULL before accessing its fields.

In the Linux kernel, the following vulnerability has been resolved:

igb: Fix string truncation warnings in igbsetfwversion

Commit 1978d3ead82c ("intel: fix string truncation warnings") fixes '-Wformat-truncation=' warnings in igbmain.c by using kasprintf.

drivers/net/ethernet/intel/igb/igbmain.c:3092:53: warning：‘%d’ directive output may be truncated writing between 1 and 5 bytes into a region of size between 1 and 13 [-Wformat-truncation=] 3092 | "%d.%d, 0x%08x, %d.%d.%d", | ^~ drivers/net/ethernet/intel/igb/igbmain.c:3092:34: note：directive argument in the range [0, 65535] 3092 | "%d.%d, 0x%08x, %d.%d.%d", | ^~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/intel/igb/igbmain.c:3092:34: note：directive argument in the range [0, 65535] drivers/net/ethernet/intel/igb/igbmain.c:3090:25: note：‘snprintf’ output between 23 and 43 bytes into a destination of size 32

kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure.

Fix this warning by using a larger space for adapter->fwversion, and then fall back and continue to use snprintf.

In the Linux kernel, the following vulnerability has been resolved:

misc: lis3lv02di2c: Fix regulators getting en-/dis-abled twice on suspend/resume

The Linux kernel CVE team has assigned CVE-2024-35824 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051737-CVE-2024-35824-7302@gregkh/T

In the Linux kernel, the following vulnerability has been resolved:

firewire: ohci: prevent leak of left-over IRQ on unbind

Commit 5a95f1ded28691e6 ("firewire: ohci: use devres for requested IRQ") also removed the call to freeirq() in pciremove(), leading to a leftover irq of devmrequestirq() at pcidisablemsi() in pciremove() when unbinding the driver from the device

removeprocentry: removing non-empty directory 'irq/136', leaking at least 'firewireohci' Call Trace: ? removeprocentry+0x19c/0x1c0 ? warn+0x81/0x130 ? removeprocentry+0x19c/0x1c0 ? reportbug+0x171/0x1a0 ? consoleunlock+0x78/0x120 ? handlebug+0x3c/0x80 ? excinvalidop+0x17/0x70 ? asmexcinvalidop+0x1a/0x20 ? removeprocentry+0x19c/0x1c0 unregisterirqproc+0xf4/0x120 freedesc+0x3d/0xe0 ? kfree+0x29f/0x2f0 irqfreedescs+0x47/0x70 msidomainfreelocked.part.0+0x19d/0x1d0 msidomainfreeirqsalllocked+0x81/0xc0 pcifreemsiirqs+0x12/0x40 pcidisablemsi+0x4c/0x60 pciremove+0x9d/0xc0 [firewireohci 01b483699bebf9cb07a3d69df0aa2bee71db1b26] pcideviceremove+0x37/0xa0 devicereleasedriverinternal+0x19f/0x200 unbindstore+0xa1/0xb0

remove irq with devmfreeirq() before pcidisablemsi() also remove it in failmsi: of pciprobe() as this would lead to an identical leak

In the Linux kernel, the following vulnerability has been resolved:

usb: typec: altmodes/displayport: create sysfs nodes as driver's default device attribute group

The DisplayPort driver's sysfs nodes may be present to the userspace before typecaltmodesetdrvdata() completes in dpaltmodeprobe. This means that a sysfs read can trigger a NULL pointer error by deferencing dp->hpd in hpdshow or dp->lock in pinassignmentshow, as devgetdrvdata() returns NULL in those cases.

Remove manual sysfs node creation in favor of adding attribute group as default for devices bound to the driver. The ATTRIBUTEGROUPS() macro is not used here otherwise the path to the sysfs nodes is no longer compliant with the ABI.

In the Linux kernel, the following vulnerability has been resolved:

drm/nouveau: fix stale locked mutex in nouveaugemioctlpushbuf

If VMBIND is enabled on the client the legacy submission ioctl can't be used, however if a client tries to do so regardless it will return an error. In this case the clients mutex remained unlocked leading to a deadlock inside nouveaudrmpostclose or any other nouveau ioctl call.

In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix deadlock with fiemap and extent locking

While working on the patchset to remove extent locking I got a lockdep splat with fiemap and pagefaulting with my new extent lock replacement lock.

This deadlock exists with our normal code, we just don't have lockdep annotations with the extent locking so we've never noticed it.

Since we're copying the fiemap extent to user space on every iteration we have the chance of pagefaulting. Because we hold the extent lock for the entire range we could mkwrite into a range in the file that we have mmap'ed. This would deadlock with the following stack trace

[<0>] lockextent+0x28d/0x2f0 [<0>] btrfspagemkwrite+0x273/0x8a0 [<0>] dopagemkwrite+0x50/0xb0 [<0>] dofault+0xc1/0x7b0 [<0>] handlemmfault+0x2fa/0x460 [<0>] handlemmfault+0xa4/0x330 [<0>] douseraddrfault+0x1f4/0x800 [<0>] excpagefault+0x7c/0x1e0 [<0>] asmexcpagefault+0x26/0x30 [<0>] repmovsalternative+0x33/0x70 [<0>] copytouser+0x49/0x70 [<0>] fiemapfillnextextent+0xc8/0x120 [<0>] emitfiemapextent+0x4d/0xa0 [<0>] extentfiemap+0x7f8/0xad0 [<0>] btrfsfiemap+0x49/0x80 [<0>] x64sysioctl+0x3e1/0xb50 [<0>] dosyscall64+0x94/0x1a0 [<0>] entrySYSCALL64afterhwframe+0x6e/0x76

I wrote an fstest to reproduce this deadlock without my replacement lock and verified that the deadlock exists with our existing locking.

To fix this simply don't take the extent lock for the entire duration of the fiemap. This is safe in general because we keep track of where we are when we're searching the tree, so if an ordered extent updates in the middle of our fiemap call we'll still emit the correct extents because we know what offset we were on before.

The only place we maintain the lock is searching delalloc. Since the delalloc stuff can change during writeback we want to lock the extent range so we have a consistent view of delalloc at the time we're checking to see if we need to set the delalloc flag.

With this patch applied we no longer deadlock with my testcase.

In the Linux kernel, the following vulnerability has been resolved:

media: rkisp1: Fix IRQ handling due to shared interrupts

The driver requests the interrupts as IRQFSHARED, so the interrupt handlers can be called at any time. If such a call happens while the ISP is powered down, the SoC will hang as the driver tries to access the ISP registers.

This can be reproduced even without the platform sharing the IRQ line: Enable CONFIGDEBUGSHIRQ and unload the driver, and the board will hang.

Fix this by adding a new field, 'irqsenabled', which is used to bail out from the interrupt handler when the ISP is not operational.

In the Linux kernel, the following vulnerability has been resolved:

Revert "net/mlx5: Block entering switchdev mode with ns inconsistency"

This reverts commit 662404b24a4c4d839839ed25e3097571f5938b9b. The revert is required due to the suspicion it is not good for anything and cause crash.

In the Linux kernel, the following vulnerability has been resolved:

net: mctp: take ownership of skb in mctplocaloutput

Currently, mctplocaloutput only takes ownership of skb on success, and we may leak an skb if mctplocaloutput fails in specific states; the skb ownership isn't transferred until the actual output routing occurs.

Instead, make mctplocaloutput free the skb on all error paths up to the route action, so it always consumes the passed skb.

In the Linux kernel, the following vulnerability has been resolved:

Revert "drm/amd/pm: resolve reboot exception for si oland"

This reverts commit e490d60a2f76bff636c68ce4fe34c1b6c34bbd86.

This causes hangs on SI when DC is enabled and errors on driver reboot and power off cycles.

In the Linux kernel, the following vulnerability has been resolved:

lib/Kconfig.debug: TESTIOVITER depends on MMU

Trying to run the ioviter unit test on a nommu system such as the qemu kc705-nommu emulation results in a crash.

KTAP version 1 # Subtest: ioviter # module: kunitioviter 1..9 BUG: failure at mm/nommu.c:318/vmap()! Kernel panic - not syncing: BUG!

The test calls vmap() directly, but vmap() is not supported on nommu systems, causing the crash. TESTIOVITER therefore needs to depend on MMU.

In the Linux kernel, the following vulnerability has been resolved:

phonet/pep: fix racy skbqueueempty() use

The receive queues are protected by their respective spin-lock, not the socket lock. This could lead to skbpeek() unexpectedly returning NULL or a pointer to an already dequeued socket buffer.

In the Linux kernel, the following vulnerability has been resolved:

ipv6: fix potential "struct net" leak in inet6rtmgetaddr()

It seems that if userspace provides a correct IFATARGETNETNSID value but no IFAADDRESS and IFALOCAL attributes, inet6rtmgetaddr() returns -EINVAL with an elevated "struct net" refcount.

In the Linux kernel, the following vulnerability has been resolved:

power: supply: bq27xxx-i2c: Do not free non existing IRQ

The bq27xxx i2c-client may not have an IRQ, in which case client->irq will be 0. bq27xxxbatteryi2cprobe() already has an if (client->irq) check wrapping the requestthreadedirq().

But bq27xxxbatteryi2cremove() unconditionally calls freeirq(client->irq) leading to:

[ 190.310742] ------------[ cut here ]------------ [ 190.310843] Trying to free already-free IRQ 0 [ 190.310861] WARNING: CPU: 2 PID: 1304 at kernel/irq/manage.c:1893 freeirq+0x1b8/0x310

Followed by a backtrace when unbinding the driver. Add an if (client->irq) to bq27xxxbatteryi2cremove() mirroring probe() to fix this.

In the Linux kernel, the following vulnerability has been resolved:

efi/capsule-loader: fix incorrect allocation size

gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures is not enough for a 64-bit physaddrt:

drivers/firmware/efi/capsule-loader.c: In function 'eficapsuleopen': drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size '4' for type 'physaddrt' {aka 'long long unsigned int'} with size '8' [-Werror=alloc-size] 295 | capinfo->phys = kzalloc(sizeof(void ), GFPKERNEL); | ^

Use the correct type instead here.

In the Linux kernel, the following vulnerability has been resolved:

netrom: Fix data-races around sysctlnetbusyread

We need to protect the reader reading the sysctl value because the value can be changed concurrently.

In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: ncm: Fix handling of zero block length packets

While connecting to a Linux host with CDCNCMNTBDEFSIZETX set to 65536, it has been observed that we receive short packets, which come at interval of 5-10 seconds sometimes and have block length zero but still contain 1-2 valid datagrams present.

According to the NCM spec:

"If wBlockLength = 0x0000, the block is terminated by a short packet. In this case, the USB transfer must still be shorter than dwNtbInMaxSize or dwNtbOutMaxSize. If exactly dwNtbInMaxSize or dwNtbOutMaxSize bytes are sent, and the size is a multiple of wMaxPacketSize for the given pipe, then no ZLP shall be sent.

wBlockLength= 0x0000 must be used with extreme care, because of the possibility that the host and device may get out of sync, and because of test issues.

wBlockLength = 0x0000 allows the sender to reduce latency by starting to send a very large NTB, and then shortening it when the sender discovers that there’s not sufficient data to justify sending a large NTB"

However, there is a potential issue with the current implementation, as it checks for the occurrence of multiple NTBs in a single giveback by verifying if the leftover bytes to be processed is zero or not. If the block length reads zero, we would process the same NTB infintely because the leftover bytes is never zero and it leads to a crash. Fix this by bailing out if block length reads zero.

In the Linux kernel, the following vulnerability has been resolved:

vt: fix unicode buffer corruption when deleting characters

The Linux kernel CVE team has assigned CVE-2024-35823 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051745-CVE-2024-35823-1e69@gregkh/T

In the Linux kernel, the following vulnerability has been resolved:

dmaengine: fsl-qdma: Fix a memory leak related to the queue command DMA

This dmaalloccoherent() is undone neither in the remove function, nor in the error handling path of fslqdmaprobe().

Switch to the managed version to fix both issues.

In the Linux kernel, the following vulnerability has been resolved:

thunderbolt: Fix NULL pointer dereference in tbportupdatecredits()

Olliver reported that his system crashes when plugging in Thunderbolt 1 device:

BUG: kernel NULL pointer dereference, address: 0000000000000020 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:tbportdoupdatecredits+0x1b/0x130 [thunderbolt] Call Trace: <TASK> ? die+0x23/0x70 ? pagefaultoops+0x171/0x4e0 ? excpagefault+0x7f/0x180 ? asmexcpagefault+0x26/0x30 ? tbportdoupdatecredits+0x1b/0x130 ? tbswitchupdatelinkattributes+0x83/0xd0 tbswitchadd+0x7a2/0xfe0 tbscanport+0x236/0x6f0 tbhandlehotplug+0x6db/0x900 processonework+0x171/0x340 workerthread+0x27b/0x3a0 ? pfxworkerthread+0x10/0x10 kthread+0xe5/0x120 ? pfxkthread+0x10/0x10 retfromfork+0x31/0x50 ? pfxkthread+0x10/0x10 retfromforkasm+0x1b/0x30 </TASK>

This is due the fact that some Thunderbolt 1 devices only have one lane adapter. Fix this by checking for the lane 1 before we read its credits.

In the Linux kernel, the following vulnerability has been resolved:

ASoC: SOF: ipc4-pcm: Workaround for crashed firmware on system suspend

The Linux kernel CVE team has assigned CVE-2024-27057 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050116-CVE-2024-27057-c0fb@gregkh/T

In the Linux kernel, the following vulnerability has been resolved:

md: Fix missing release of 'activeio' for flush

submitflushes atomicset(&mddev->flushpending, 1); rdevforeachrcu(rdev, mddev) atomicinc(&mddev->flushpending); bi->biendio = mdendflush submitbio(bi); / flush io is done first / mdendflush if (atomicdecandtest(&mddev->flushpending)) percpurefput(&mddev->activeio) -> activeio is not released

if (atomicdecandtest(&mddev->flushpending)) -> missing release of activeio

For consequence, mddevsuspend() will wait for 'activeio' to be zero forever.

Fix this problem by releasing 'activeio' in submitflushes() if 'flushpending' is decreased to zero.

In the Linux kernel, the following vulnerability has been resolved:

USB: usb-storage: Prevent divide-by-0 error in isd200atacommand

The isd200 sub-driver in usb-storage uses the HEADS and SECTORS values in the ATA ID information to calculate cylinder and head values when creating a CDB for READ or WRITE commands. The calculation involves division and modulus operations, which will cause a crash if either of these values is 0. While this never happens with a genuine device, it could happen with a flawed or subversive emulation, as reported by the syzbot fuzzer.

Protect against this possibility by refusing to bind to the device if either the ATAIDHEADS or ATAIDSECTORS value in the device's ID information is 0. This requires isd200Initialization() to return a negative error code when initialization fails; currently it always returns 0 (even when there is an error).

In the Linux kernel, the following vulnerability has been resolved:

PCI: Fix active state requirement in PME polling

The commit noted in fixes added a bogus requirement that runtime PM managed devices need to be in the RPMACTIVE state for PME polling. In fact, only devices in low power states should be polled.

However there's still a requirement that the device config space must be accessible, which has implications for both the current state of the polled device and the parent bridge, when present. It's not sufficient to assume the bridge remains in D0 and cases have been observed where the bridge passes the D0 test, but the PM state indicates RPMSUSPENDING and config space of the polled device becomes inaccessible during pcipmewakeup().

Therefore, since the bridge is already effectively required to be in the RPMACTIVE state, formalize this in the code and elevate the PM usage count to maintain the state while polling the subordinate device.

This resolves a regression reported in the bugzilla below where a Thunderbolt/USB4 hierarchy fails to scan for an attached NVMe endpoint downstream of a bridge in a D3hot power state.

In the Linux kernel, the following vulnerability has been resolved:

comedi: comedi8255: Correct error in subdevice initialization

The refactoring done in commit 5c57b1ccecc7 ("comedi: comedi8255: Rework subdevice initialization functions") to the initialization of the io field of struct subdev8255private broke all cards using the drivers/comedi/drivers/comedi8255.c module.

Prior to 5c57b1ccecc7, subdev8255init() initialized the io field in the newly allocated struct subdev8255private to the non-NULL callback given to the function, otherwise it used a flag parameter to select between subdev8255mmio and subdev8255io. The refactoring removed that logic and the flag, as subdev8255mminit() and subdev8255ioinit() now explicitly pass subdev8255mmio and subdev8255io respectively to subdev8255init(), only subdev8255init() never sets spriv->io to the supplied callback. That spriv->io is NULL leads to a later BUG:

BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0010 [#1] SMP PTI CPU: 1 PID: 1210 Comm: systemd-udevd Not tainted 6.7.3-x8664 #1 Hardware name: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0018:ffffa3f1c02d7b78 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff91f847aefd00 RCX: 000000000000009b RDX: 0000000000000003 RSI: 0000000000000001 RDI: ffff91f840f6fc00 RBP: ffff91f840f6fc00 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 000000000000005f R12: 0000000000000000 R13: 0000000000000000 R14: ffffffffc0102498 R15: ffff91f847ce6ba8 FS: 00007f72f4e8f500(0000) GS:ffff91f8d5c80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 000000010540e000 CR4: 00000000000406f0 Call Trace: <TASK> ? diebody+0x15/0x57 ? pagefaultoops+0x2ef/0x33c ? insertvmaparea.constprop.0+0xb6/0xd5 ? allocvmaparea+0x529/0x5ee ? excpagefault+0x15a/0x489 ? asmexcpagefault+0x22/0x30 subdev8255init+0x79/0x8d [comedi8255] pci8255autoattach+0x11a/0x139 [8255pci] comediautoconfig+0xac/0x117 [comedi] ? pfxdriverattach+0x10/0x10 pcideviceprobe+0x88/0xf9 reallyprobe+0x101/0x248 driverprobedevice+0xbb/0xed driverprobedevice+0x1a/0x72 driverattach+0xd4/0xed busforeachdev+0x76/0xb8 busadddriver+0xbe/0x1be driverregister+0x9a/0xd8 comedipcidriverregister+0x28/0x48 [comedipci] ? pfxpci8255driverinit+0x10/0x10 [8255pci] dooneinitcall+0x72/0x183 doinitmodule+0x5b/0x1e8 initmodulefromfile+0x86/0xac dosysfinitmodule+0x151/0x218 dosyscall64+0x72/0xdb entrySYSCALL64afterhwframe+0x6e/0x76 RIP: 0033:0x7f72f50a0cb9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 47 71 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffd47e512d8 EFLAGS: 00000246 ORIGRAX: 0000000000000139 RAX: ffffffffffffffda RBX: 0000562dd06ae070 RCX: 00007f72f50a0cb9 RDX: 0000000000000000 RSI: 00007f72f52d32df RDI: 000000000000000e RBP: 0000000000000000 R08: 00007f72f5168b20 R09: 0000000000000000 R10: 0000000000000050 R11: 0000000000000246 R12: 00007f72f52d32df R13: 0000000000020000 R14: 0000562dd06785c0 R15: 0000562dcfd0e9a8 </TASK> Modules linked in: 8255pci(+) comedi8255 comedipci comedi intelgtt e100(+) acpicpufreq rtccmos usbhid CR2: 0000000000000000 ---[ end trace 0000000000000000 ]--- RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0018:ffffa3f1c02d7b78 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff91f847aefd00 RCX: 000000000000009b RDX: 0000000000000003 RSI: 0000000000000001 RDI: ffff91f840f6fc00 RBP: ffff91f840f6fc00 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 000000000000005f R12: 0000000000000000 R13: 0000000000000000 R14: ffffffffc0102498 R15: ffff91f847ce6ba8 FS: ---truncated---

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Use a memory barrier to enforce PTP WQ xmit submission tracking occurs after populating the metadatamap

Just simply reordering the functions mlx5eptpmetadatamapput and mlx5eptpsqtrackmetadata in the mlx5etxwqecomplete context is not good enough since both the compiler and CPU are free to reorder these two functions. If reordering does occur, the issue that was supposedly fixed by 7e3f3ba97e6c ("net/mlx5e: Track xmit submission to PTP WQ after populating metadata map") will be seen. This will lead to NULL pointer dereferences in mlx5eptpsqmarktscqesundelivered in the NAPI polling context due to the tracking list being populated before the metadata map.

In the Linux kernel, the following vulnerability has been resolved:

mm/debugvmpgtable: fix BUGON with pud advanced test

Architectures like powerpc add debug checks to ensure we find only devmap PUD pte entries. These debug checks are only done with CONFIGDEBUGVM. This patch marks the ptes used for PUD advanced test devmap pte entries so that we don't hit on debug checks on architecture like ppc64 as below.

WARNING: CPU: 2 PID: 1 at arch/powerpc/mm/book3s64/radixpgtable.c:1382 radixpudhugepageupdate+0x38/0x138 .... NIP [c0000000000a7004] radixpudhugepageupdate+0x38/0x138 LR [c0000000000a77a8] radixpudphugegetandclear+0x28/0x60 Call Trace: [c000000004a2f950] [c000000004a2f9a0] 0xc000000004a2f9a0 (unreliable) [c000000004a2f980] [000d34c100000000] 0xd34c100000000 [c000000004a2f9a0] [c00000000206ba98] pudadvancedtests+0x118/0x334 [c000000004a2fa40] [c00000000206db34] debugvmpgtable+0xcbc/0x1c48 [c000000004a2fc10] [c00000000000fd28] dooneinitcall+0x60/0x388

Also

kernel BUG at arch/powerpc/mm/book3s64/pgtable.c:202! ....

NIP [c000000000096510] pudphugegetandclearfull+0x98/0x174 LR [c00000000206bb34] pudadvancedtests+0x1b4/0x334 Call Trace: [c000000004a2f950] [000d34c100000000] 0xd34c100000000 (unreliable) [c000000004a2f9a0] [c00000000206bb34] pudadvancedtests+0x1b4/0x334 [c000000004a2fa40] [c00000000206db34] debugvmpgtable+0xcbc/0x1c48 [c000000004a2fc10] [c00000000000fd28] dooneinitcall+0x60/0x388

In the Linux kernel, the following vulnerability has been resolved:

netlink: add nla be16/32 types to minlen array

BUG: KMSAN: uninit-value in nlavalidaterangeunsigned lib/nlattr.c:222 [inline] BUG: KMSAN: uninit-value in nlavalidateintrange lib/nlattr.c:336 [inline] BUG: KMSAN: uninit-value in validatenla lib/nlattr.c:575 [inline] BUG: KMSAN: uninit-value in nlavalidateparse+0x2e20/0x45c0 lib/nlattr.c:631 nlavalidaterangeunsigned lib/nlattr.c:222 [inline] nlavalidateintrange lib/nlattr.c:336 [inline] validatenla lib/nlattr.c:575 [inline] ...

The message in question matches this policy:

[NFTATARGETREV] = NLAPOLICYMAX(NLABE32, 255),

but because NLABE32 size in minlen array is 0, the validation code will read past the malformed (too small) attribute.

Note: Other attributes, e.g. BITFIELD32, SINT, UINT.. are also missing: those likely should be added too.