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

net: ks8851: Handle softirqs at the end of IRQ thread to fix hang

The ks8851irq() thread may call ks8851rxpkts() in case there are any packets in the MAC FIFO, which calls netifrx(). This netifrx() implementation is guarded by localbhdisable() and localbhenable(). The localbhenable() may call dosoftirq() to run softirqs in case any are pending. One of the softirqs is netrxaction, which ultimately reaches the driver .startxmit callback. If that happens, the system hangs. The entire call chain is below:

ks8851startxmitpar from netdevstartxmit netdevstartxmit from devhardstartxmit devhardstartxmit from schdirectxmit schdirectxmit from devqueuexmit devqueuexmit from neighupdate neighupdate from neighupdate neighupdate from arpprocess.constprop.0 arpprocess.constprop.0 from netifreceiveskbonecore netifreceiveskbonecore from processbacklog processbacklog from napipoll.constprop.0 napipoll.constprop.0 from netrxaction netrxaction from dosoftirq dosoftirq from callwithstack callwithstack from dosoftirq dosoftirq from localbhenableip localbhenableip from netifrx netifrx from ks8851irq ks8851irq from irqthreadfn irqthreadfn from irqthread irqthread from kthread kthread from retfromfork

The hang happens because ks8851irq() first locks a spinlock in ks8851par.c ks8851lockpar() spinlockirqsave(&ksp->lock, ...) and with that spinlock locked, calls netifrx(). Once the execution reaches ks8851startxmitpar(), it calls ks8851lockpar() again which attempts to claim the already locked spinlock again, and the hang happens.

Move the dosoftirq() call outside of the spinlock protected section of ks8851irq() by disabling BHs around the entire spinlock protected section of ks8851irq() handler. Place localbhenable() outside of the spinlock protected section, so that it can trigger dosoftirq() without the ks8851par.c ks8851lockpar() spinlock being held, and safely call ks8851startxmitpar() without attempting to lock the already locked spinlock.

Since ks8851irq() is protected by localbhdisable()/localbhenable() now, replace netifrx() with netifrx() which is not duplicating the localbhdisable()/localbhenable() calls.

drm/panfrost: Fix the error path in panfrostmmumapfaultaddr()

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

epoll: be better about file lifetimes

epoll can call out to vfspoll() with a file pointer that may race with the last 'fput()'. That would make fcount go down to zero, and while the ep->mtx locking means that the resulting file pointer tear-down will be blocked until the poll returns, it means that fcount is already dead, and any use of it won't actually get a reference to the file any more: it's dead regardless.

Make sure we have a valid ref on the file pointer before we call down to vfspoll() from the epoll routines.

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

drm/amdgpu/mes: fix use-after-free issue

Delete fence fallback timer to fix the ramdom use-after-free issue.

v2: move to amdgpumes.c

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

irqchip/gic-v3-its: Prevent double free on error

The error handling path in itsvpeirqdomainalloc() causes a double free when itsvpeinit() fails after successfully allocating at least one interrupt. This happens because itsvpeirqdomainfree() frees the interrupts along with the area bitmap and the vproppage and itsvpeirqdomainalloc() subsequently frees the area bitmap and the vproppage again.

Fix this by unconditionally invoking itsvpeirqdomainfree() which handles all cases correctly and by removing the bitmap/vproppage freeing from itsvpeirqdomainalloc().

[ tglx: Massaged change log ]

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

mlxsw: spectrumacltcam: Fix possible use-after-free during rehash

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

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051740-CVE-2024-35854-d17b@gregkh/T

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

mlxsw: spectrumacltcam: Fix possible use-after-free during activity update

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

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051741-CVE-2024-35855-c1fb@gregkh/T

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

netfilter: nftsetpipapo: walk over current view on netlink dump

The generation mask can be updated while netlink dump is in progress. The pipapo set backend walk iterator cannot rely on it to infer what view of the datastructure is to be used. Add notation to specify if user wants to read/update the set.

Based on patch from Florian Westphal.

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

netfilter: nftables: Fix potential data-race in nftobjtypeget()

nftunregisterobj() can concurrent with nftobjtypeget(), and there is not any protection when iterate over nftablesobjects list in nftobjtypeget(). Therefore, there is potential data-race of nftablesobjects list entry.

Use listforeachentryrcu() to iterate over nftablesobjects list in nftobjtypeget(), and use rcureadlock() in the caller nftobjtypeget() to protect the entire type query process.

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

netfilter: nftables: Fix potential data-race in nftexprtypeget()

nftunregisterexpr() can concurrent with nftexprtypeget(), and there is not any protection when iterate over nftablesexpressions list in nftexprtypeget(). Therefore, there is potential data-race of nftablesexpressions list entry.

Use listforeachentryrcu() to iterate over nftablesexpressions list in nftexprtypeget(), and use rcureadlock() in the caller nftexprtypeget() to protect the entire type query process.

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

Squashfs: check the inode number is not the invalid value of zero

Syskiller has produced an out of bounds access in fillmetaindex().

That out of bounds access is ultimately caused because the inode has an inode number with the invalid value of zero, which was not checked.

The reason this causes the out of bounds access is due to following sequence of events:

1. Fillmetaindex() is called to allocate (via emptymetaindex()) and fill a metadata index. It however suffers a data read error and aborts, invalidating the newly returned empty metadata index. It does this by setting the inode number of the index to zero, which means unused (zero is not a valid inode number).

2. When fillmetaindex() is subsequently called again on another read operation, locatemetaindex() returns the previous index because it matches the inode number of 0. Because this index has been returned it is expected to have been filled, and because it hasn't been, an out of bounds access is performed.

This patch adds a sanity check which checks that the inode number is not zero when the inode is created and returns -EINVAL if it is.

[phillip@squashfs.org.uk: whitespace fix]

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

Bluetooth: qca: add missing firmware sanity checks

Add the missing sanity checks when parsing the firmware files before downloading them to avoid accessing and corrupting memory beyond the vmalloced buffer.

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

interconnect: Don't access reqlist while it's being manipulated

The icclock mutex was split into separate icclock and iccbwlock mutexes in [1] to avoid lockdep splats. However, this didn't adequately protect access to iccnode::reqlist.

The iccsetbw() function will eventually iterate over reqlist while only holding iccbwlock, but reqlist can be modified while only holding icclock. This causes races between iccsetbw(), oficcget(), and iccput().

Example A:

CPU0 CPU1 ---- ---- iccsetbw(patha) mutexlock(&iccbwlock); iccput(pathb) mutexlock(&icclock); aggregaterequests() hlistforeachentry(r, ... hlistdel(... <r = invalid pointer>

Example B:

CPU0 CPU1 ---- ---- iccsetbw(patha) mutexlock(&iccbwlock); pathb = oficcget() oficcgetbyindex() mutexlock(&icclock); pathfind() pathinit() aggregaterequests() hlistforeachentry(r, ... hlistaddhead(... <r = invalid pointer>

Fix this by ensuring iccbwlock is always held before manipulating iccnode::reqlist. The additional places iccbwlock is held don't perform any memory allocations, so we should still be safe from the original lockdep splats that motivated the separate locks.

[1] commit af42269c3523 ("interconnect: Fix locking for runpm vs reclaim")

ax25: Fix netdev refcount issue

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

drm/amdkfd: don't allow mapping the MMIO HDP page with large pages

We don't get the right offset in that case. The GPU has an unused 4K area of the register BAR space into which you can remap registers. We remap the HDP flush registers into this space to allow userspace (CPU or GPU) to flush the HDP when it updates VRAM. However, on systems with >4K pages, we end up exposing PAGESIZE of MMIO space.

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

fs/9p: only translate RWX permissions for plain 9P2000

Garbage in plain 9P2000's perm bits is allowed through, which causes it to be able to set (among others) the suid bit. This was presumably not the intent since the unix extended bits are handled explicitly and conditionally on .u.

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

tracefs: Reset permissions on remount if permissions are options

There's an inconsistency with the way permissions are handled in tracefs. Because the permissions are generated when accessed, they default to the root inode's permission if they were never set by the user. If the user sets the permissions, then a flag is set and the permissions are saved via the inode (for tracefs files) or an internal attribute field (for eventfs).

But if a remount happens that specify the permissions, all the files that were not changed by the user gets updated, but the ones that were are not. If the user were to remount the file system with a given permission, then all files and directories within that file system should be updated.

This can cause security issues if a file's permission was updated but the admin forgot about it. They could incorrectly think that remounting with permissions set would update all files, but miss some.

For example:

# cd /sys/kernel/tracing # chgrp 1002 currenttracer # ls -l [..] -rw-r----- 1 root root 0 May 1 21:25 buffersizekb -rw-r----- 1 root root 0 May 1 21:25 buffersubbufsizekb -r--r----- 1 root root 0 May 1 21:25 buffertotalsizekb -rw-r----- 1 root lkp 0 May 1 21:25 currenttracer -rw-r----- 1 root root 0 May 1 21:25 dynamicevents -r--r----- 1 root root 0 May 1 21:25 dynftracetotalinfo -r--r----- 1 root root 0 May 1 21:25 enabledfunctions

Where currenttracer now has group "lkp".

# mount -o remount,gid=1001 . # ls -l -rw-r----- 1 root tracing 0 May 1 21:25 buffersizekb -rw-r----- 1 root tracing 0 May 1 21:25 buffersubbufsizekb -r--r----- 1 root tracing 0 May 1 21:25 buffertotalsizekb -rw-r----- 1 root lkp 0 May 1 21:25 currenttracer -rw-r----- 1 root tracing 0 May 1 21:25 dynamicevents -r--r----- 1 root tracing 0 May 1 21:25 dynftracetotalinfo -r--r----- 1 root tracing 0 May 1 21:25 enabledfunctions

Everything changed but the "currenttracer".

Add a new link list that keeps track of all the tracefsinodes which has the permission flags that tell if the file/dir should use the root inode's permission or not. Then on remount, clear all the flags so that the default behavior of using the root inode's permission is done for all files and directories.

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

thermal/debugfs: Fix two locking issues with thermal zone debug

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

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024060344-CVE-2024-36961-58bb@gregkh/T

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

drm/vmwgfx: Fix invalid reads in fence signaled events

Correctly set the length of the drmevent to the size of the structure that's actually used.

The length of the drmevent was set to the parent structure instead of to the drmvmweventfence which is supposed to be read. drmread uses the length parameter to copy the event to the user space thus resuling in oob reads.

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

net/smc: fix neighbour and rtable leak in smcibfindroute()

In smcibfindroute(), the neighbour found by neighlookup() and rtable resolved by iprouteoutputflow() are not released or put before return. It may cause the refcount leak, so fix it.

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

fs/proc/taskmmu: fix loss of young/dirty bits during pagemap scan

makeuffdwppte() was previously doing:

pte = ptepget(ptep); ptepmodifyprotstart(ptep); pte = ptemkuffdwp(pte); ptepmodifyprotcommit(ptep, pte);

But if another thread accessed or dirtied the pte between the first 2 calls, this could lead to loss of that information. Since ptepmodifyprotstart() gets and clears atomically, the following is the correct pattern and prevents any possible race. Any access after the first call would see an invalid pte and cause a fault:

pte = ptepmodifyprotstart(ptep); pte = ptemkuffdwp(pte); ptepmodifyprotcommit(ptep, pte);

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

pinctrl: core: delete incorrect free in pinctrlenable()

The "pctldev" struct is allocated in devmpinctrlregisterandinit(). It's a devm managed pointer that is freed by devmpinctrldevrelease(), so freeing it in pinctrlenable() will lead to a double free.

The devmpinctrldevrelease() function frees the pindescs and destroys the mutex as well.

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

nsh: Restore skb->{protocol,data,macheader} for outer header in nshgsosegment().

syzbot triggered various splats (see [0] and links) by a crafted GSO packet of VIRTIONETHDRGSOUDP layering the following protocols:

ETHP8021AD + ETHPNSH + ETHPIPV6 + IPPROTOUDP

NSH can encapsulate IPv4, IPv6, Ethernet, NSH, and MPLS. As the inner protocol can be Ethernet, NSH GSO handler, nshgsosegment(), calls skbmacgsosegment() to invoke inner protocol GSO handlers.

nshgsosegment() does the following for the original skb before calling skbmacgsosegment()

1. reset skb->networkheader 2. save the original skb->{macheaeder,maclen} in a local variable 3. pull the NSH header 4. resets skb->macheader 5. set up skb->maclen and skb->protocol for the inner protocol.

and does the following for the segmented skb

6. set ntohs(ETHPNSH) to skb->protocol 7. push the NSH header 8. restore skb->macheader 9. set skb->macheader + maclen to skb->networkheader 10. restore skb->maclen

There are two problems in 6-7 and 8-9.

(a) After 6 & 7, skb->data points to the NSH header, so the outer header (ETHP8021AD in this case) is stripped when skb is sent out of netdev.

Also, if NSH is encapsulated by NSH + Ethernet (so NSH-Ethernet-NSH), skbpull() in the first nshgsosegment() will make skb->data point to the middle of the outer NSH or Ethernet header because the Ethernet header is not pulled by the second nshgsosegment().

(b) While restoring skb->{macheader,networkheader} in 8 & 9, nshgsosegment() does not assume that the data in the linear buffer is shifted.

However, udp6ufofragment() could shift the data and change skb->macheader accordingly as demonstrated by syzbot.

If this happens, even the restored skb->macheader points to the middle of the outer header.

It seems nshgsosegment() has never worked with outer headers so far.

At the end of nshgsosegment(), the outer header must be restored for the segmented skb, instead of the NSH header.

To do that, let's calculate the outer header position relatively from the inner header and set skb->{data,macheader,protocol} properly.

[0]: BUG: KMSAN: uninit-value in ipvlanprocessoutbound drivers/net/ipvlan/ipvlancore.c:524 [inline] BUG: KMSAN: uninit-value in ipvlanxmitmodel3 drivers/net/ipvlan/ipvlancore.c:602 [inline] BUG: KMSAN: uninit-value in ipvlanqueuexmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlancore.c:668 ipvlanprocessoutbound drivers/net/ipvlan/ipvlancore.c:524 [inline] ipvlanxmitmodel3 drivers/net/ipvlan/ipvlancore.c:602 [inline] ipvlanqueuexmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlancore.c:668 ipvlanstartxmit+0x5c/0x1a0 drivers/net/ipvlan/ipvlanmain.c:222 netdevstartxmit include/linux/netdevice.h:4989 [inline] netdevstartxmit include/linux/netdevice.h:5003 [inline] xmitone net/core/dev.c:3547 [inline] devhardstartxmit+0x244/0xa10 net/core/dev.c:3563 devqueuexmit+0x33ed/0x51c0 net/core/dev.c:4351 devqueuexmit include/linux/netdevice.h:3171 [inline] packetxmit+0x9c/0x6b0 net/packet/afpacket.c:276 packetsnd net/packet/afpacket.c:3081 [inline] packetsendmsg+0x8aef/0x9f10 net/packet/afpacket.c:3113 socksendmsgnosec net/socket.c:730 [inline] socksendmsg net/socket.c:745 [inline] syssendto+0x735/0xa10 net/socket.c:2191 dosyssendto net/socket.c:2203 [inline] sesyssendto net/socket.c:2199 [inline] x64syssendto+0x125/0x1c0 net/socket.c:2199 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcf/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b

Uninit was created at: slabpostallochook mm/slub.c:3819 [inline] slaballocnode mm/slub.c:3860 [inline] dokmallocnode mm/slub.c:3980 [inline] kmallocnodetrackcaller+0x705/0x1000 mm/slub.c:4001 kmallocreserve+0x249/0x4a0 net/core/skbuff.c:582 ---truncated---

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

net: core: reject skbcopy(expand) for fraglist GSO skbs

SKBGSOFRAGLIST skbs must not be linearized, otherwise they become invalid. Return NULL if such an skb is passed to skbcopy or skbcopyexpand, in order to prevent a crash on a potential later call to skbgsosegment.

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

s390/qeth: Fix kernel panic after setting hsuid

Symptom: When the hsuid attribute is set for the first time on an IQD Layer3 device while the corresponding network interface is already UP, the kernel will try to execute a napi function pointer that is NULL.

Example: --------------------------------------------------------------------------- [ 2057.572696] illegal operation: 0001 ilc:1 [#1] SMP [ 2057.572702] Modules linked in: afiucv qethl3 zfcp scsitransportfc sunrpc nftfibinet nftfibipv4 nftfibipv6 nftfib nftrejectinet nfrejectipv4 nfrejectipv6 nftreject nftct nftablesset nftchainnat nfnat nfconntrack nfdefragipv6 nfdefragipv4 ipset nftables libcrc32c nfnetlink ghashs390 prng xts aess390 dess390 de sgeneric sha3512s390 sha3256s390 sha512s390 vfioccw vfiomdev mdev vfioiommutype1 eadmsch vfio ext4 mbcache jbd2 qethl2 bridge stp llc dasdeckdmod qeth dasdmod qdio ccwgroup pkey zcrypt [ 2057.572739] CPU: 6 PID: 60182 Comm: stressclient Kdump: loaded Not tainted 4.18.0-541.el8.s390x #1 [ 2057.572742] Hardware name: IBM 3931 A01 704 (LPAR) [ 2057.572744] Krnl PSW : 0704f00180000000 0000000000000002 (0x2) [ 2057.572748] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 2057.572751] Krnl GPRS: 0000000000000004 0000000000000000 00000000a3b008d8 0000000000000000 [ 2057.572754] 00000000a3b008d8 cb923a29c779abc5 0000000000000000 00000000814cfd80 [ 2057.572756] 000000000000012c 0000000000000000 00000000a3b008d8 00000000a3b008d8 [ 2057.572758] 00000000bab6d500 00000000814cfd80 0000000091317e46 00000000814cfc68 [ 2057.572762] Krnl Code:#0000000000000000: 0000 illegal >0000000000000002: 0000 illegal 0000000000000004: 0000 illegal 0000000000000006: 0000 illegal 0000000000000008: 0000 illegal 000000000000000a: 0000 illegal 000000000000000c: 0000 illegal 000000000000000e: 0000 illegal [ 2057.572800] Call Trace: [ 2057.572801] ([<00000000ec639700>] 0xec639700) [ 2057.572803] [<00000000913183e2>] netrxaction+0x2ba/0x398 [ 2057.572809] [<0000000091515f76>] dosoftirq+0x11e/0x3a0 [ 2057.572813] [<0000000090ce160c>] dosoftirqownstack+0x3c/0x58 [ 2057.572817] ([<0000000090d2cbd6>] dosoftirq.part.1+0x56/0x60) [ 2057.572822] [<0000000090d2cc60>] localbhenableip+0x80/0x98 [ 2057.572825] [<0000000091314706>] devqueuexmit+0x2be/0xd70 [ 2057.572827] [<000003ff803dd6d6>] afiucvhssend+0x24e/0x300 [afiucv] [ 2057.572830] [<000003ff803dd88a>] iucvsendctrl+0x102/0x138 [afiucv] [ 2057.572833] [<000003ff803de72a>] iucvsockconnect+0x37a/0x468 [afiucv] [ 2057.572835] [<00000000912e7e90>] sysconnect+0xa0/0xd8 [ 2057.572839] [<00000000912e9580>] syssocketcall+0x228/0x348 [ 2057.572841] [<0000000091514e1a>] systemcall+0x2a6/0x2c8 [ 2057.572843] Last Breaking-Event-Address: [ 2057.572844] [<0000000091317e44>] napipoll+0x4c/0x1d8 [ 2057.572846] [ 2057.572847] Kernel panic - not syncing: Fatal exception in interrupt -------------------------------------------------------------------------------------------

Analysis: There is one napi structure per outq: card->qdio.outqs[i].napi The napi.poll functions are set during qethopen().

Since commit 1cfef80d4c2b ("s390/qeth: Don't call devclose/devopen (DOWN/UP)") qethsetoffline()/qethsetonline() no longer call devclose()/ devopen(). So if qethfreeqdioqueues() cleared card->qdio.outqs[i].napi.poll while the network interface was UP and the card was offline, they are not set again.

Reproduction: chzdev -e $devno layer2=0 ip link set dev $networkinterface up echo 0 > /sys/bus/ccw ---truncated---

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

nfc: llcp: fix nfcllcpsetsockopt() unsafe copies

syzbot reported unsafe calls to copyfromsockptr() [1]

Use copysafefromsockptr() instead.

[1]

BUG: KASAN: slab-out-of-bounds in copyfromsockptroffset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copyfromsockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in nfcllcpsetsockopt+0x6c2/0x850 net/nfc/llcpsock.c:255 Read of size 4 at addr ffff88801caa1ec3 by task syz-executor459/5078

CPU: 0 PID: 5078 Comm: syz-executor459 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:114 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x169/0x550 mm/kasan/report.c:488 kasanreport+0x143/0x180 mm/kasan/report.c:601 copyfromsockptroffset include/linux/sockptr.h:49 [inline] copyfromsockptr include/linux/sockptr.h:55 [inline] nfcllcpsetsockopt+0x6c2/0x850 net/nfc/llcpsock.c:255 dosocksetsockopt+0x3b1/0x720 net/socket.c:2311 syssetsockopt+0x1ae/0x250 net/socket.c:2334 dosyssetsockopt net/socket.c:2343 [inline] sesyssetsockopt net/socket.c:2340 [inline] x64syssetsockopt+0xb5/0xd0 net/socket.c:2340 dosyscall64+0xfd/0x240 entrySYSCALL64afterhwframe+0x6d/0x75 RIP: 0033:0x7f7fac07fd89 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 18 00 00 90 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 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff660eb788 EFLAGS: 00000246 ORIGRAX: 0000000000000036 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f7fac07fd89 RDX: 0000000000000000 RSI: 0000000000000118 RDI: 0000000000000004 RBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000000000 R10: 0000000020000a80 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000

drm/amd/display: Skip on writeback when it's not applicable

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

uiohvgeneric: Don't free decrypted memory

In CoCo VMs it is possible for the untrusted host to cause setmemoryencrypted() or setmemorydecrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues.

The VMBus device UIO driver could free decrypted/shared pages if setmemorydecrypted() fails. Check the decrypted field in the gpadl to decide whether to free the memory.

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

tcp: Use refcountincnotzero() in tcptwskunique().

Anderson Nascimento reported a use-after-free splat in tcptwskunique() with nice analysis.

Since commit ec94c2696f0b ("tcp/dccp: avoid one atomic operation for timewait hashdance"), inettwskhashdance() sets TIME-WAIT socket's skrefcnt after putting it into ehash and releasing the bucket lock.

Thus, there is a small race window where other threads could try to reuse the port during connect() and call sockhold() in tcptwskunique() for the TIME-WAIT socket with zero refcnt.

If that happens, the refcnt taken by tcptwskunique() is overwritten and sockput() will cause underflow, triggering a real use-after-free somewhere else.

To avoid the use-after-free, we need to use refcountincnotzero() in tcptwskunique() and give up on reusing the port if it returns false.

[0]: refcountt: addition on 0; use-after-free. WARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcountwarnsaturate+0xe5/0x110 CPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x8664 #1 Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023 RIP: 0010:refcountwarnsaturate+0xe5/0x110 Code: 42 8e ff 0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea 01 01 e8 7b 42 8e ff <0f> 0b c3 cc cc cc cc 48 c7 c7 50 8f b7 82 c6 05 7a 13 ea 01 01 e8 RSP: 0018:ffffc90006b43b60 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027 RDX: ffff88807be218c8 RSI: 0000000000000001 RDI: ffff88807be218c0 RBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0 R10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84 R13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0 FS: 00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0 PKRU: 55555554 Call Trace: <TASK> ? refcountwarnsaturate+0xe5/0x110 ? warn+0x81/0x130 ? refcountwarnsaturate+0xe5/0x110 ? reportbug+0x171/0x1a0 ? refcountwarnsaturate+0xe5/0x110 ? handlebug+0x3c/0x80 ? excinvalidop+0x17/0x70 ? asmexcinvalidop+0x1a/0x20 ? refcountwarnsaturate+0xe5/0x110 tcptwskunique+0x186/0x190 inetcheckestablished+0x176/0x2d0 inethashconnect+0x74/0x7d0 ? pfxinetcheckestablished+0x10/0x10 tcpv4connect+0x278/0x530 inetstreamconnect+0x10f/0x3d0 inetstreamconnect+0x3a/0x60 sysconnect+0xa8/0xd0 x64sysconnect+0x18/0x20 dosyscall64+0x83/0x170 entrySYSCALL64afterhwframe+0x78/0x80 RIP: 0033:0x7f62c11a885d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 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 a3 45 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007f62c1091e58 EFLAGS: 00000296 ORIGRAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000020ccb004 RCX: 00007f62c11a885d RDX: 0000000000000010 RSI: 0000000020ccb000 RDI: 0000000000000003 RBP: 00007f62c1091e90 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 00007f62c10926c0 R13: ffffffffffffff88 R14: 0000000000000000 R15: 00007ffe237885b0 </TASK>

gpiolib: cdev: fix uninitialised kfifo