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

mm/vmscan: fix a bug calling wakeupkswapd() with a wrong zone index

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

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024040458-CVE-2024-26783-68c8@gregkh/T

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

wifi: iwlwifi: mvm: ensure offloading TID queue exists

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

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050115-CVE-2024-27056-98c0@gregkh/T

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

net: bridge: switchdev: Skip MDB replays of deferred events on offload

Before this change, generation of the list of MDB events to replay would race against the creation of new group memberships, either from the IGMP/MLD snooping logic or from user configuration.

While new memberships are immediately visible to walkers of br->mdblist, the notification of their existence to switchdev event subscribers is deferred until a later point in time. So if a replay list was generated during a time that overlapped with such a window, it would also contain a replay of the not-yet-delivered event.

The driver would thus receive two copies of what the bridge internally considered to be one single event. On destruction of the bridge, only a single membership deletion event was therefore sent. As a consequence of this, drivers which reference count memberships (at least DSA), would be left with orphan groups in their hardware database when the bridge was destroyed.

This is only an issue when replaying additions. While deletion events may still be pending on the deferred queue, they will already have been removed from br->mdblist, so no duplicates can be generated in that scenario.

To a user this meant that old group memberships, from a bridge in which a port was previously attached, could be reanimated (in hardware) when the port joined a new bridge, without the new bridge's knowledge.

For example, on an mv88e6xxx system, create a snooping bridge and immediately add a port to it:

root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcastsnooping 1 && \ > ip link set dev x3 up master br0

And then destroy the bridge:

root@infix-06-0b-00:~$ ip link del dev br0 root@infix-06-0b-00:~$ mvls atu ADDRESS FID STATE Q F 0 1 2 3 4 5 6 7 8 9 a DEV:0 Marvell 88E6393X 33:33:00:00:00:6a 1 static - - 0 . . . . . . . . . . 33:33:ff:87:e4:3f 1 static - - 0 . . . . . . . . . . ff:ff:ff:ff:ff:ff 1 static - - 0 1 2 3 4 5 6 7 8 9 a root@infix-06-0b-00:~$

The two IPv6 groups remain in the hardware database because the port (x3) is notified of the host's membership twice: once via the original event and once via a replay. Since only a single delete notification is sent, the count remains at 1 when the bridge is destroyed.

Then add the same port (or another port belonging to the same hardware domain) to a new bridge, this time with snooping disabled:

root@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcastsnooping 0 && \ > ip link set dev x3 up master br1

All multicast, including the two IPv6 groups from br0, should now be flooded, according to the policy of br1. But instead the old memberships are still active in the hardware database, causing the switch to only forward traffic to those groups towards the CPU (port 0).

Eliminate the race in two steps:

1. Grab the write-side lock of the MDB while generating the replay list.

This prevents new memberships from showing up while we are generating the replay list. But it leaves the scenario in which a deferred event was already generated, but not delivered, before we grabbed the lock. Therefore:

2. Make sure that no deferred version of a replay event is already enqueued to the switchdev deferred queue, before adding it to the replay list, when replaying additions.

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

tls: separate no-async decryption request handling from async

If we're not doing async, the handling is much simpler. There's no reference counting, we just need to wait for the completion to wake us up and return its result.

We should preferably also use a separate cryptowait. I'm not seeing a UAF as I did in the past, I think aec7961916f3 ("tls: fix race between async notify and socket close") took care of it.

This will make the next fix easier.

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:

net: mvpp2: clear BM pool before initialization

Register value persist after booting the kernel using kexec which results in kernel panic. Thus clear the BM pool registers before initialisation to fix the issue.

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:

net/mlx5e: fix a double-free in arfscreategroups

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

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051730-CVE-2024-35835-d75f@gregkh/T

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:

netfilter: bridge: confirm multicast packets before passing them up the stack

conntrack nfconfirm logic cannot handle cloned skbs referencing the same nfconn entry, which will happen for multicast (broadcast) frames on bridges.

Example: macvlan0 | br0 / \ ethX ethY

ethX (or Y) receives a L2 multicast or broadcast packet containing an IP packet, flow is not yet in conntrack table.

1. skb passes through bridge and fake-ip (brnetfilter)Prerouting. -> skb->nfct now references a unconfirmed entry 2. skb is broad/mcast packet. bridge now passes clones out on each bridge interface. 3. skb gets passed up the stack. 4. In macvlan case, macvlan driver retains clone(s) of the mcast skb and schedules a work queue to send them out on the lower devices.

The clone skb->nfct is not a copy, it is the same entry as the original skb. The macvlan rx handler then returns RXHANDLERPASS. 5. Normal conntrack hooks (in NFINETLOCALIN) confirm the orig skb.

The Macvlan broadcast worker and normal confirm path will race.

This race will not happen if step 2 already confirmed a clone. In that case later steps perform skbclone() with skb->nfct already confirmed (in hash table). This works fine.

But such confirmation won't happen when eb/ip/nftables rules dropped the packets before they reached the nfconfirm step in postrouting.

Pablo points out that nfconntrackbridge doesn't allow use of stateful nat, so we can safely discard the nfconn entry and let inet call conntrack again.

This doesn't work for bridge netfilter: skb could have a nat transformation. Also bridge nf prevents re-invocation of inet prerouting via 'sabotagein' hook.

Work around this problem by explicit confirmation of the entry at LOCALIN time, before upper layer has a chance to clone the unconfirmed entry.

The downside is that this disables NAT and conntrack helpers.

Alternative fix would be to add locking to all code parts that deal with unconfirmed packets, but even if that could be done in a sane way this opens up other problems, for example:

-m physdev --physdev-out eth0 -j SNAT --snat-to 1.2.3.4 -m physdev --physdev-out eth1 -j SNAT --snat-to 1.2.3.5

For multicast case, only one of such conflicting mappings will be created, conntrack only handles 1:1 NAT mappings.

Users should set create a setup that explicitly marks such traffic NOTRACK (conntrack bypass) to avoid this, but we cannot auto-bypass them, ruleset might have accept rules for untracked traffic already, so user-visible behaviour would change.

dmaengine: dw-edma: eDMA: Add sync read before starting the DMA transfer in remote setup

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:

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:

tracing/trigger: Fix to return error if failed to alloc snapshot

Fix registersnapshottrigger() to return error code if it failed to allocate a snapshot instead of 0 (success). Unless that, it will register snapshot trigger without an error.

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:

nouveau: lock the client object tree.

It appears the client object tree has no locking unless I've missed something else. Fix races around adding/removing client objects, mostly vram bar mappings.

4562.099306] general protection fault, probably for non-canonical address 0x6677ed422bceb80c: 0000 [#1] PREEMPT SMP PTI [ 4562.099314] CPU: 2 PID: 23171 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27 [ 4562.099324] Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021 [ 4562.099330] RIP: 0010:nvkmobjectsearch+0x1d/0x70 [nouveau] [ 4562.099503] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 48 89 f8 48 85 f6 74 39 48 8b 87 a0 00 00 00 48 85 c0 74 12 <48> 8b 48 f8 48 39 ce 73 15 48 8b 40 10 48 85 c0 75 ee 48 c7 c0 fe [ 4562.099506] RSP: 0000:ffffa94cc420bbf8 EFLAGS: 00010206 [ 4562.099512] RAX: 6677ed422bceb814 RBX: ffff98108791f400 RCX: ffff9810f26b8f58 [ 4562.099517] RDX: 0000000000000000 RSI: ffff9810f26b9158 RDI: ffff98108791f400 [ 4562.099519] RBP: ffff9810f26b9158 R08: 0000000000000000 R09: 0000000000000000 [ 4562.099521] R10: ffffa94cc420bc48 R11: 0000000000000001 R12: ffff9810f02a7cc0 [ 4562.099526] R13: 0000000000000000 R14: 00000000000000ff R15: 0000000000000007 [ 4562.099528] FS: 00007f629c5017c0(0000) GS:ffff98142c700000(0000) knlGS:0000000000000000 [ 4562.099534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4562.099536] CR2: 00007f629a882000 CR3: 000000017019e004 CR4: 00000000003706f0 [ 4562.099541] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4562.099542] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 4562.099544] Call Trace: [ 4562.099555] [ 4562.099573] ? dieaddr+0x36/0x90 [ 4562.099583] ? excgeneralprotection+0x246/0x4a0 [ 4562.099593] ? asmexcgeneralprotection+0x26/0x30 [ 4562.099600] ? nvkmobjectsearch+0x1d/0x70 [nouveau] [ 4562.099730] nvkmioctl+0xa1/0x250 [nouveau] [ 4562.099861] nvifobjectmaphandle+0xc8/0x180 [nouveau] [ 4562.099986] nouveauttmiomemreserve+0x122/0x270 [nouveau] [ 4562.100156] ? dmaresvtestsignaled+0x26/0xb0 [ 4562.100163] ttmbovmfaultreserved+0x97/0x3c0 [ttm] [ 4562.100182] ? mutexunlockslowpath+0x2a/0x270 [ 4562.100189] nouveauttmfault+0x69/0xb0 [nouveau] [ 4562.100356] dofault+0x32/0x150 [ 4562.100362] dofault+0x7c/0x560 [ 4562.100369] handlemmfault+0x800/0xc10 [ 4562.100382] handlemmfault+0x17c/0x3e0 [ 4562.100388] douseraddrfault+0x208/0x860 [ 4562.100395] excpagefault+0x7f/0x200 [ 4562.100402] asmexcpagefault+0x26/0x30 [ 4562.100412] RIP: 0033:0x9b9870 [ 4562.100419] Code: 85 a8 f7 ff ff 8b 8d 80 f7 ff ff 89 08 e9 18 f2 ff ff 0f 1f 84 00 00 00 00 00 44 89 32 e9 90 fa ff ff 0f 1f 84 00 00 00 00 00 <44> 89 32 e9 f8 f1 ff ff 0f 1f 84 00 00 00 00 00 66 44 89 32 e9 e7 [ 4562.100422] RSP: 002b:00007fff9ba2dc70 EFLAGS: 00010246 [ 4562.100426] RAX: 0000000000000004 RBX: 000000000dd65e10 RCX: 000000fff0000000 [ 4562.100428] RDX: 00007f629a882000 RSI: 00007f629a882000 RDI: 0000000000000066 [ 4562.100432] RBP: 00007fff9ba2e570 R08: 0000000000000000 R09: 0000000123ddf000 [ 4562.100434] R10: 0000000000000001 R11: 0000000000000246 R12: 000000007fffffff [ 4562.100436] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 4562.100446] [ 4562.100448] Modules linked in: nfconntracknetbiosns nfconntrackbroadcast nftfibinet nftfibipv4 nftfibipv6 nftfib nftrejectinet nfrejectipv4 nfrejectipv6 nftreject nftct nftchainnat nfnat nfconntrack nfdefragipv6 nfdefragipv4 ipset nftables libcrc32c nfnetlink cmac bnep sunrpc iwlmvm intelraplmsr intelraplcommon sndsofpciintelcnl x86pkgtempthermal intelpowerclamp sndsofintelhdacommon mac80211 coretemp sndsocacpiintelmatch kvmintel sndsocacpi sndsochdachda sndsofpci sndsofxtensadsp sndsofintelhdamlink ---truncated---

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

netfilter: nftflowoffload: reset dst in route object after setting up flow

dst is transferred to the flow object, route object does not own it anymore. Reset dst in route object, otherwise if flowoffloadadd() fails, error path releases dst twice, leading to a refcount underflow.

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

fs/ntfs3: Fixed overflow check in mienumattr()

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

usb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBs

It is observed sometimes when tethering is used over NCM with Windows 11 as host, at some instances, the gadgetgiveback has one byte appended at the end of a proper NTB. When the NTB is parsed, unwrap call looks for any leftover bytes in SKB provided by uether and if there are any pending bytes, it treats them as a separate NTB and parses it. But in case the second NTB (as per unwrap call) is faulty/corrupt, all the datagrams that were parsed properly in the first NTB and saved in rxlist are dropped.

Adding a few custom traces showed the following: [002] d..1 7828.532866: dwc3gadgetgiveback: ep1out: req 000000003868811a length 1025/16384 zsI ==> 0 [002] d..1 7828.532867: ncmunwrapntb: K: ncmunwrapntb toprocess: 1025 [002] d..1 7828.532867: ncmunwrapntb: K: ncmunwrapntb nth: 1751999342 [002] d..1 7828.532868: ncmunwrapntb: K: ncmunwrapntb seq: 0xce67 [002] d..1 7828.532868: ncmunwrapntb: K: ncmunwrapntb blklen: 0x400 [002] d..1 7828.532868: ncmunwrapntb: K: ncmunwrapntb ndplen: 0x10 [002] d..1 7828.532869: ncmunwrapntb: K: Parsed NTB with 1 frames

In this case, the giveback is of 1025 bytes and block length is 1024. The rest 1 byte (which is 0x00) won't be parsed resulting in drop of all datagrams in rxlist.

Same is case with packets of size 2048: [002] d..1 7828.557948: dwc3gadgetgiveback: ep1out: req 0000000011dfd96e length 2049/16384 zsI ==> 0 [002] d..1 7828.557949: ncmunwrapntb: K: ncmunwrapntb nth: 1751999342 [002] d..1 7828.557950: ncmunwrapntb: K: ncmunwrapntb blklen: 0x800

Lecroy shows one byte coming in extra confirming that the byte is coming in from PC:

Transfer 2959 - Bytes Transferred(1025) Timestamp((18.524 843 590) - Transaction 8391 - Data(1025 bytes) Timestamp(18.524 843 590) --- Packet 4063861 Data(1024 bytes) Duration(2.117us) Idle(14.700ns) Timestamp(18.524 843 590) --- Packet 4063863 Data(1 byte) Duration(66.160ns) Time(282.000ns) Timestamp(18.524 845 722)

According to Windows driver, no ZLP is needed if wBlockLength is non-zero, because the non-zero wBlockLength has already told the function side the size of transfer to be expected. However, there are in-market NCM devices that rely on ZLP as long as the wBlockLength is multiple of wMaxPacketSize. To deal with such devices, it pads an extra 0 at end so the transfer is no longer multiple of wMaxPacketSize.

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:

wifi: nl80211: reject iftype change with mesh ID change

It's currently possible to change the mesh ID when the interface isn't yet in mesh mode, at the same time as changing it into mesh mode. This leads to an overwrite of data in the wdev->u union for the interface type it currently has, causing cfg80211changeiface() to do wrong things when switching.

We could probably allow setting an interface to mesh while setting the mesh ID at the same time by doing a different order of operations here, but realistically there's no userspace that's going to do this, so just disallow changes in iftype when setting mesh ID.

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

rtnetlink: fix error logic of IFLABRIDGEFLAGS writing back

In the commit d73ef2d69c0d ("rtnetlink: let rtnlbridgesetlink checks IFLABRIDGEMODE length"), an adjustment was made to the old loop logic in the function rtnlbridgesetlink to enable the loop to also check the length of the IFLABRIDGEMODE attribute. However, this adjustment removed the break statement and led to an error logic of the flags writing back at the end of this function.

if (haveflags) memcpy(nladata(attr), &flags, sizeof(flags)); // attr should point to IFLABRIDGEFLAGS NLA !!!

Before the mentioned commit, the attr is granted to be IFLABRIDGEFLAGS. However, this is not necessarily true fow now as the updated loop will let the attr point to the last NLA, even an invalid NLA which could cause overflow writes.

This patch introduces a new variable brflag to save the NLA pointer that points to IFLABRIDGEFLAGS and uses it to resolve the mentioned error logic.

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:

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:

KVM: SVM: Flush pages under kvm->lock to fix UAF in svmregisterencregion()

Do the cache flush of converted pages in svmregisterencregion() before dropping kvm->lock to fix use-after-free issues where region and/or its array of pages could be freed by a different task, e.g. if userspace has unregisterencregionlocked() already queued up for the region.

Note, the "obvious" alternative of using local variables doesn't fully resolve the bug, as region->pages is also dynamically allocated. I.e. the region structure itself would be fine, but region->pages could be freed.

Flushing multiple pages under kvm->lock is unfortunate, but the entire flow is a rare slow path, and the manual flush is only needed on CPUs that lack coherency for encrypted memory.

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

KVM: x86: Mark target gfn of emulated atomic instruction as dirty

When emulating an atomic access on behalf of the guest, mark the target gfn dirty if the CMPXCHG by KVM is attempted and doesn't fault. This fixes a bug where KVM effectively corrupts guest memory during live migration by writing to guest memory without informing userspace that the page is dirty.

Marking the page dirty got unintentionally dropped when KVM's emulated CMPXCHG was converted to do a user access. Before that, KVM explicitly mapped the guest page into kernel memory, and marked the page dirty during the unmap phase.

Mark the page dirty even if the CMPXCHG fails, as the old data is written back on failure, i.e. the page is still written. The value written is guaranteed to be the same because the operation is atomic, but KVM's ABI is that all writes are dirty logged regardless of the value written. And more importantly, that's what KVM did before the buggy commit.

Huge kudos to the folks on the Cc list (and many others), who did all the actual work of triaging and debugging.

base-commit: 6769ea8da8a93ed4630f1ce64df6aafcaabfce64

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

dmaengine: ti: edma: Add some null pointer checks to the edmaprobe

devmkasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity.

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

nvmet-fc: avoid deadlock on delete association path

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

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024040307-CVE-2024-26769-e9cc@gregkh/T

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

fbdev: savage: Error out if pixclock equals zero

The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of pixclock, it may cause divide-by-zero error.

Although pixclock is checked in savagefbdecodevar(), but it is not checked properly in savagefbprobe(). Fix this by checking whether pixclock is zero in the function savagefbcheckvar() before info->var.pixclock is used as the divisor.

This is similar to CVE-2022-3061 in i740fb which was fixed by commit 15cf0b8.