The Linux Kernel, the operating system core itself.

Security Fix(es):

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

tcp: Use refcountincnotzero() in tcptwsk_unique().

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 sk_refcnt 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 tcptwsk_unique() for the TIME-WAIT socket with zero refcnt.

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

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

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 ORIG_RAX: 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>(CVE-2024-36904)

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

drm/amdgpu: change vm->task_info handling

This patch changes the handling and lifecycle of vm->taskinfo object. The major changes are: - vm->taskinfo is a dynamically allocated ptr now, and its uasge is reference counted. - introducing two new helper funcs for taskinfo lifecycle management - amdgpuvmgettaskinfo: reference counts up taskinfo before returning this info - amdgpuvmputtaskinfo: reference counts down taskinfo - last put to taskinfo() frees task_info from the vm.

This patch also does logistical changes required for existing usage of vm->task_info.

V2: Do not block all the prints when task_info not found (Felix)

V3: Fixed review comments from Felix - Fix wrong indentation - No debug message for -ENOMEM - Add NULL check for taskinfo - Do not duplicate the debug messages (ti vs no ti) - Get first reference of taskinfo in vminit(), put last in vmfini()

V4: Fixed review comments from Felix - fix double reference increment in createtaskinfo - change amdgpuvmgettaskinfopasid - additional changes in amdgpugem.c while porting(CVE-2024-41008)

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

drm/amd/display: Add null checks for 'stream' and 'plane' before dereferencing

This commit adds null checks for the 'stream' and 'plane' variables in the dcn30applyidlepoweroptimizations function. These variables were previously assumed to be null at line 922, but they were used later in the code without checking if they were null. This could potentially lead to a null pointer dereference, which would cause a crash.

The null checks ensure that 'stream' and 'plane' are not null before they are used, preventing potential crashes.

Fixes the below static smatch checker: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30hwseq.c:938 dcn30applyidlepoweroptimizations() error: we previously assumed 'stream' could be null (see line 922) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30hwseq.c:940 dcn30applyidlepoweroptimizations() error: we previously assumed 'plane' could be null (see line 922)(CVE-2024-43904)

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

ALSA: line6: Fix racy access to midibuf

There can be concurrent accesses to line6 midibuf from both the URB completion callback and the rawmidi API access. This could be a cause of KMSAN warning triggered by syzkaller below (so put as reported-by here).

This patch protects the midibuf call of the former code path with a spinlock for avoiding the possible races.(CVE-2024-44954)

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

tracefs: Use generic inode RCU for synchronizing freeing

With structure layout randomization enabled for 'struct inode' we need to avoid overlapping any of the RCU-used / initialized-only-once members, e.g. ilru or isblist to not corrupt related list traversals when making use of the rcuhead.

For an unlucky structure layout of 'struct inode' we may end up with the following splat when running the ftrace selftests:

[<...>] listdel corruption, ffff888103ee2cb0->next (tracefsinodecache+0x0/0x4e0 [slab object]) is NULL (prev is tracefsinodecache+0x78/0x4e0 [slab object]) [<...>] ------------[ cut here ]------------ [<...>] kernel BUG at lib/listdebug.c:54! [<...>] invalid opcode: 0000 [#1] PREEMPT SMP KASAN [<...>] CPU: 3 PID: 2550 Comm: mount Tainted: G N 6.8.12-grsec+ #122 ed2f536ca62f28b087b90e3cc906a8d25b3ddc65 [<...>] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 [<...>] RIP: 0010:[<ffffffff84656018>] listdelentryvalidorreport+0x138/0x3e0 [<...>] Code: 48 b8 99 fb 65 f2 ff ff ff ff e9 03 5c d9 fc cc 48 b8 99 fb 65 f2 ff ff ff ff e9 33 5a d9 fc cc 48 b8 99 fb 65 f2 ff ff ff ff <0f> 0b 4c 89 e9 48 89 ea 48 89 ee 48 c7 c7 60 8f dd 89 31 c0 e8 2f [<...>] RSP: 0018:fffffe80416afaf0 EFLAGS: 00010283 [<...>] RAX: 0000000000000098 RBX: ffff888103ee2cb0 RCX: 0000000000000000 [<...>] RDX: ffffffff84655fe8 RSI: ffffffff89dd8b60 RDI: 0000000000000001 [<...>] RBP: ffff888103ee2cb0 R08: 0000000000000001 R09: fffffbd0082d5f25 [<...>] R10: fffffe80416af92f R11: 0000000000000001 R12: fdf99c16731d9b6d [<...>] R13: 0000000000000000 R14: ffff88819ad4b8b8 R15: 0000000000000000 [<...>] RBX: tracefsinodecache+0x0/0x4e0 [slab object] [<...>] RDX: _listdelentryvalidorreport+0x108/0x3e0 [<...>] RSI: _func.47+0x4340/0x4400 [<...>] RBP: tracefsinodecache+0x0/0x4e0 [slab object] [<...>] RSP: process kstack fffffe80416afaf0+0x7af0/0x8000 [mount 2550 2550] [<...>] R09: kasan shadow of process kstack fffffe80416af928+0x7928/0x8000 [mount 2550 2550] [<...>] R10: process kstack fffffe80416af92f+0x792f/0x8000 [mount 2550 2550] [<...>] R14: tracefsinodecache+0x78/0x4e0 [slab object] [<...>] FS: 00006dcb380c1840(0000) GS:ffff8881e0600000(0000) knlGS:0000000000000000 [<...>] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [<...>] CR2: 000076ab72b30e84 CR3: 000000000b088004 CR4: 0000000000360ef0 shadow CR4: 0000000000360ef0 [<...>] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [<...>] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [<...>] ASID: 0003 [<...>] Stack: [<...>] ffffffff818a2315 00000000f5c856ee ffffffff896f1840 ffff888103ee2cb0 [<...>] ffff88812b6b9750 0000000079d714b6 fffffbfff1e9280b ffffffff8f49405f [<...>] 0000000000000001 0000000000000000 ffff888104457280 ffffffff8248b392 [<...>] Call Trace: [<...>] <TASK> [<...>] [<ffffffff818a2315>] ? lockrelease+0x175/0x380 fffffe80416afaf0 [<...>] [<ffffffff8248b392>] listlrudel+0x152/0x740 fffffe80416afb48 [<...>] [<ffffffff8248ba93>] listlrudelobj+0x113/0x280 fffffe80416afb88 [<...>] [<ffffffff8940fd19>] ? atomicdecandlock+0x119/0x200 fffffe80416afb90 [<...>] [<ffffffff8295b244>] iputfinal+0x1c4/0x9a0 fffffe80416afbb8 [<...>] [<ffffffff8293a52b>] dentryunlinkinode+0x44b/0xaa0 fffffe80416afbf8 [<...>] [<ffffffff8293fefc>] _dentrykill+0x23c/0xf00 fffffe80416afc40 [<...>] [<ffffffff8953a85f>] ? _thiscpupreemptcheck+0x1f/0xa0 fffffe80416afc48 [<...>] [<ffffffff82949ce5>] ? shrinkdentrylist+0x1c5/0x760 fffffe80416afc70 [<...>] [<ffffffff82949b71>] ? shrinkdentrylist+0x51/0x760 fffffe80416afc78 [<...>] [<ffffffff82949da8>] shrinkdentrylist+0x288/0x760 fffffe80416afc80 [<...>] [<ffffffff8294ae75>] shrinkdcachesb+0x155/0x420 fffffe80416afcc8 [<...>] [<ffffffff8953a7c3>] ? debugsmpprocessorid+0x23/0xa0 fffffe80416afce0 [<...>] [<ffffffff8294ad20>] ? doonetre ---truncated---(CVE-2024-44959)

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

Bluetooth: btnxpuart: Shutdown timer and prevent rearming when driver unloading

When unload the btnxpuart driver, its associated timer will be deleted. If the timer happens to be modified at this moment, it leads to the kernel call this timer even after the driver unloaded, resulting in kernel panic. Use timershutdownsync() instead of deltimersync() to prevent rearming.

panic log: Internal error: Oops: 0000000086000007 [#1] PREEMPT SMP Modules linked in: algifhash algifskcipher afalg moal(O) mlan(O) crct10difce polyvalce polyvalgeneric sndsocimxcard sndsocfslasoccard sndsocimxaudmux mxcjpegencdec v4l2jpeg sndsocwm8962 sndsocfslmicfil sndsocfslsai flexcan sndsocfslutils ap130x rpmsgctrl imxpcmdma candev rpmsgchar pwmfan fuse [last unloaded: btnxpuart] CPU: 5 PID: 723 Comm: memtester Tainted: G O 6.6.23-lts-next-06207-g4aef2658ac28 #1 Hardware name: NXP i.MX95 19X19 board (DT) pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0xffff80007a2cf464 lr : calltimerfn.isra.0+0x24/0x80 ... Call trace: 0xffff80007a2cf464 runtimers+0x234/0x280 runtimersoftirq+0x20/0x40 _dosoftirq+0x100/0x26c _dosoftirq+0x10/0x1c callonirqstack+0x24/0x4c dosoftirqownstack+0x1c/0x2c irqexitrcu+0xc0/0xdc el0interrupt+0x54/0xd8 _el0irqhandlercommon+0x18/0x24 el0t64irqhandler+0x10/0x1c el0t64_irq+0x190/0x194 Code: ???????? ???????? ???????? ???????? (????????) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt SMP: stopping secondary CPUs Kernel Offset: disabled CPU features: 0x0,c0000000,40028143,1000721b Memory Limit: none ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---(CVE-2024-44962)

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

x86/mm: Fix pticlonepgtable() alignment assumption

Guenter reported dodgy crashes on an i386-nosmp build using GCC-11 that had the form of endless traps until entry stack exhaust and then

DF from the stack guard.

It turned out that pticlonepgtable() had alignment assumptions on the start address, notably it hard assumes start is PMD aligned. This is true on x86_64, but very much not true on i386.

These assumptions can cause the end condition to malfunction, leading to a 'short' clone. Guess what happens when the user mapping has a short copy of the entry text?

Use the correct increment form for addr to avoid alignment assumptions.(CVE-2024-44965)

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

drm/mgag200: Bind I2C lifetime to DRM device

Managed cleanup with devmaddactionorreset() will release the I2C adapter when the underlying Linux device goes away. But the connector still refers to it, so this cleanup leaves behind a stale pointer in struct drm_connector.ddc.

Bind the lifetime of the I2C adapter to the connector's lifetime by using DRM's managed release. When the DRM device goes away (after the Linux device) DRM will first clean up the connector and then clean up the I2C adapter.(CVE-2024-44967)

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

s390/sclp: Prevent release of buffer in I/O

When a task waiting for completion of a Store Data operation is interrupted, an attempt is made to halt this operation. If this attempt fails due to a hardware or firmware problem, there is a chance that the SCLP facility might store data into buffers referenced by the original operation at a later time.

Handle this situation by not releasing the referenced data buffers if the halt attempt fails. For current use cases, this might result in a leak of few pages of memory in case of a rare hardware/firmware malfunction.(CVE-2024-44969)

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

mptcp: pm: avoid possible UaF when selecting endp

selectlocaladdress() and selectsignaladdress() both select an endpoint entry from the list inside an RCU protected section, but return a reference to it, to be read later on. If the entry is dereferenced after the RCU unlock, reading info could cause a Use-after-Free.

A simple solution is to copy the required info while inside the RCU protected section to avoid any risk of UaF later. The address ID might need to be modified later to handle the ID0 case later, so a copy seems OK to deal with.(CVE-2024-44974)

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

bnxten: Fix double DMA unmapping for XDPREDIRECT

Remove the dmaunmappageattrs() call in the driver's XDPREDIRECT code path. This should have been removed when we let the page pool handle the DMA mapping. This bug causes the warning:

WARNING: CPU: 7 PID: 59 at drivers/iommu/dma-iommu.c:1198 iommudmaunmappage+0xd5/0x100 CPU: 7 PID: 59 Comm: ksoftirqd/7 Tainted: G W 6.8.0-1010-gcp #11-Ubuntu Hardware name: Dell Inc. PowerEdge R7525/0PYVT1, BIOS 2.15.2 04/02/2024 RIP: 0010:iommudmaunmappage+0xd5/0x100 Code: 89 ee 48 89 df e8 cb f2 69 ff 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 31 f6 31 ff 45 31 c0 e9 ab 17 71 00 <0f> 0b 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 RSP: 0018:ffffab1fc0597a48 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff99ff838280c8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffab1fc0597a78 R08: 0000000000000002 R09: ffffab1fc0597c1c R10: ffffab1fc0597cd3 R11: ffff99ffe375acd8 R12: 00000000e65b9000 R13: 0000000000000050 R14: 0000000000001000 R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff9a06efb80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000565c34c37210 CR3: 00000005c7e3e000 CR4: 0000000000350ef0 ? showregs+0x6d/0x80 ? _warn+0x89/0x150 ? iommudmaunmappage+0xd5/0x100 ? reportbug+0x16a/0x190 ? handlebug+0x51/0xa0 ? excinvalidop+0x18/0x80 ? iommudmaunmappage+0xd5/0x100 ? iommudmaunmappage+0x35/0x100 dmaunmappageattrs+0x55/0x220 ? bpfprog4d7e87c0d30db711xdpdispatcher+0x64/0x9f bnxtrxxdp+0x237/0x520 [bnxten] bnxtrxpkt+0x640/0xdd0 [bnxten] _bnxtpollwork+0x1a1/0x3d0 [bnxten] bnxtpoll+0xaa/0x1e0 [bnxten] _napipoll+0x33/0x1e0 netrxaction+0x18a/0x2f0(CVE-2024-44984)

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

tcp: prevent concurrent execution of tcpskexit_batch

Its possible that two threads call tcpskexitbatch() concurrently, once from the cleanupnet workqueue, once from a task that failed to clone a new netns. In the latter case, error unwinding calls the exit handlers in reverse order for the 'failed' netns.

tcpskexitbatch() calls tcptwskpurge(). Problem is that since commit b099ce2602d8 ("net: Batch inettwskpurge"), this function picks up twsk in any dying netns, not just the one passed in via exitbatch list.

This means that the error unwind of setup_net() can "steal" and destroy timewait sockets belonging to the exiting netns.

This allows the netns exit worker to proceed to call

WARNONONCE(!refcountdecandtest(&net->ipv4.tcpdeathrow.twrefcount));

without the expected 1 -> 0 transition, which then splats.

At same time, error unwind path that is also running inettwskpurge() will splat as well:

WARNING: .. at lib/refcount.c:31 refcountwarnsaturate+0x1ed/0x210 ... refcountdec include/linux/refcount.h:351 [inline] inettwskkill+0x758/0x9c0 net/ipv4/inettimewaitsock.c:70 inettwskdescheduleput net/ipv4/inettimewaitsock.c:221 inettwskpurge+0x725/0x890 net/ipv4/inettimewaitsock.c:304 tcpskexitbatch+0x1c/0x170 net/ipv4/tcpipv4.c:3522 opsexitlist+0x128/0x180 net/core/netnamespace.c:178 setupnet+0x714/0xb40 net/core/netnamespace.c:375 copynetns+0x2f0/0x670 net/core/netnamespace.c:508 createnewnamespaces+0x3ea/0xb10 kernel/nsproxy.c:110

... because refcountdec() of twrefcount unexpectedly dropped to 0.

This doesn't seem like an actual bug (no tw sockets got lost and I don't see a use-after-free) but as erroneous trigger of debug check.

Add a mutex to force strict ordering: the task that calls tcptwskpurge() blocks other task from doing final decand_test before mutex-owner has removed all tw sockets of dying netns.(CVE-2024-44991)

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

iommu: Restore lost return in iommureportdevice_fault()

When iommureportdevice_fault gets called with a partial fault it is supposed to collect the fault into the group and then return.

Instead the return was accidently deleted which results in trying to process the fault and an eventual crash.

Deleting the return was a typo, put it back.(CVE-2024-44994)

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

net: hns3: fix a deadlock problem when config TC during resetting

When config TC during the reset process, may cause a deadlock, the flow is as below: pf reset start │ ▼ ...... setup tc │ │ ▼ ▼ DOWN: napidisable() napidisable()(skip) │ │ │ ▼ ▼ ...... ...... │ │ ▼ │ napienable() │ ▼ UINIT: netifnapidel() │ ▼ ...... │ ▼ INIT: netifnapiadd() │ ▼ ...... global reset start │ │ ▼ ▼ UP: napienable()(skip) ...... │ │ ▼ ▼ ...... napi_disable()

In reset process, the driver will DOWN the port and then UINIT, in this case, the setup tc process will UP the port before UINIT, so cause the problem. Adds a DOWN process in UINIT to fix it.(CVE-2024-44995)

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

vsock: fix recursive ->recvmsg calls

After a vsock socket has been added to a BPF sockmap, its prot->recvmsg has been replaced with vsockbpfrecvmsg(). Thus the following recursiion could happen:

vsockbpfrecvmsg() -> _vsockrecvmsg() -> vsockconnectiblerecvmsg() -> prot->recvmsg() -> vsockbpfrecvmsg() again

We need to fix it by calling the original ->recvmsg() without any BPF sockmap logic in _vsockrecvmsg().(CVE-2024-44996)

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

gtp: pull network headers in gtpdevxmit()

syzbot/KMSAN reported use of uninit-value in getdevxmit() [1]

We must make sure the IPv4 or Ipv6 header is pulled in skb->head before accessing fields in them.

Use pskbinetmay_pull() to fix this issue.

[1] BUG: KMSAN: uninit-value in ipv6pdpfind drivers/net/gtp.c:220 [inline] BUG: KMSAN: uninit-value in gtpbuildskbip6 drivers/net/gtp.c:1229 [inline] BUG: KMSAN: uninit-value in gtpdevxmit+0x1424/0x2540 drivers/net/gtp.c:1281 ipv6pdpfind drivers/net/gtp.c:220 [inline] gtpbuildskbip6 drivers/net/gtp.c:1229 [inline] gtpdevxmit+0x1424/0x2540 drivers/net/gtp.c:1281 _netdevstartxmit include/linux/netdevice.h:4913 [inline] netdevstartxmit include/linux/netdevice.h:4922 [inline] xmitone net/core/dev.c:3580 [inline] devhardstartxmit+0x247/0xa20 net/core/dev.c:3596 _devqueuexmit+0x358c/0x5610 net/core/dev.c:4423 devqueuexmit include/linux/netdevice.h:3105 [inline] packetxmit+0x9c/0x6c0 net/packet/afpacket.c:276 packetsnd net/packet/afpacket.c:3145 [inline] packetsendmsg+0x90e3/0xa3a0 net/packet/afpacket.c:3177 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg+0x30f/0x380 net/socket.c:745 _syssendto+0x685/0x830 net/socket.c:2204 _dosyssendto net/socket.c:2216 [inline] _sesyssendto net/socket.c:2212 [inline] _x64syssendto+0x125/0x1d0 net/socket.c:2212 x64syscall+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls64.h:45 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

Uninit was created at: slabpostallochook mm/slub.c:3994 [inline] slaballocnode mm/slub.c:4037 [inline] kmemcacheallocnodenoprof+0x6bf/0xb80 mm/slub.c:4080 kmallocreserve+0x13d/0x4a0 net/core/skbuff.c:583 _allocskb+0x363/0x7b0 net/core/skbuff.c:674 allocskb include/linux/skbuff.h:1320 [inline] allocskbwithfrags+0xc8/0xbf0 net/core/skbuff.c:6526 sockallocsendpskb+0xa81/0xbf0 net/core/sock.c:2815 packetallocskb net/packet/afpacket.c:2994 [inline] packetsnd net/packet/afpacket.c:3088 [inline] packetsendmsg+0x749c/0xa3a0 net/packet/afpacket.c:3177 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg+0x30f/0x380 net/socket.c:745 _syssendto+0x685/0x830 net/socket.c:2204 _dosyssendto net/socket.c:2216 [inline] _sesyssendto net/socket.c:2212 [inline] _x64syssendto+0x125/0x1d0 net/socket.c:2212 x64syscall+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls64.h:45 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

CPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024(CVE-2024-44999)

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

fs/netfs/fscachecookie: add missing "naccesses" check

This fixes a NULL pointer dereference bug due to a data race which looks like this:

BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 33 PID: 16573 Comm: kworker/u97:799 Not tainted 6.8.7-cm4all1-hp+ #43 Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018 Workqueue: eventsunbound netfsrreqwritetocachework RIP: 0010:cachefilespreparewrite+0x30/0xa0 Code: 57 41 56 45 89 ce 41 55 49 89 cd 41 54 49 89 d4 55 53 48 89 fb 48 83 ec 08 48 8b 47 08 48 83 7f 10 00 48 89 34 24 48 8b 68 20 <48> 8b 45 08 4c 8b 38 74 45 49 8b 7f 50 e8 4e a9 b0 ff 48 8b 73 10 RSP: 0018:ffffb4e78113bde0 EFLAGS: 00010286 RAX: ffff976126be6d10 RBX: ffff97615cdb8438 RCX: 0000000000020000 RDX: ffff97605e6c4c68 RSI: ffff97605e6c4c60 RDI: ffff97615cdb8438 RBP: 0000000000000000 R08: 0000000000278333 R09: 0000000000000001 R10: ffff97605e6c4600 R11: 0000000000000001 R12: ffff97605e6c4c68 R13: 0000000000020000 R14: 0000000000000001 R15: ffff976064fe2c00 FS: 0000000000000000(0000) GS:ffff9776dfd40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000005942c002 CR4: 00000000001706f0 Call Trace: <TASK> ? _die+0x1f/0x70 ? pagefaultoops+0x15d/0x440 ? searchmoduleextables+0xe/0x40 ? fixupexception+0x22/0x2f0 ? excpagefault+0x5f/0x100 ? asmexcpagefault+0x22/0x30 ? cachefilespreparewrite+0x30/0xa0 netfsrreqwritetocachework+0x135/0x2e0 processonework+0x137/0x2c0 workerthread+0x2e9/0x400 ? _pfxworkerthread+0x10/0x10 kthread+0xcc/0x100 ? _pfxkthread+0x10/0x10 retfromfork+0x30/0x50 ? _pfxkthread+0x10/0x10 retfromforkasm+0x1b/0x30 </TASK> Modules linked in: CR2: 0000000000000008 ---[ end trace 0000000000000000 ]---

This happened because fscachecookiestatemachine() was slow and was still running while another process invoked fscacheunusecookie(); this led to a fscachecookielrudoone() call, setting the FSCACHECOOKIEDOLRUDISCARD flag, which was picked up by fscachecookiestatemachine(), withdrawing the cookie via cachefileswithdrawcookie(), clearing cookie->cache_priv.

At the same time, yet another process invoked cachefilespreparewrite(), which found a NULL pointer in this code line:

struct cachefilesobject *object = cachefilescres_object(cres);

The next line crashes, obviously:

struct cachefiles_cache *cache = object->volume->cache;

During cachefilespreparewrite(), the "naccesses" counter is non-zero (via fscachebegin_operation()). The cookie must not be withdrawn until it drops to zero.

The counter is checked by fscachecookiestatemachine() before switching to FSCACHECOOKIESTATERELINQUISHING and FSCACHECOOKIESTATEWITHDRAWING (in "case FSCACHECOOKIESTATEFAILED"), but not for FSCACHECOOKIESTATELRUDISCARDING ("case FSCACHECOOKIESTATE_ACTIVE").

This patch adds the missing check. With a non-zero access counter, the function returns and the next fscacheendcookieaccess() call will queue another fscachecookiestatemachine() call to handle the still-pending FSCACHECOOKIEDOLRUDISCARD.(CVE-2024-45000)

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

rtla/osnoise: Prevent NULL dereference in error handling

If the "tool->data" allocation fails then there is no need to call osnoisefreetop() and, in fact, doing so will lead to a NULL dereference.(CVE-2024-45002)

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

vfs: Don't evict inode under the inode lru traversing context

The inode reclaiming process(See function pruneicachesb) collects all reclaimable inodes and mark them with IFREEING flag at first, at that time, other processes will be stuck if they try getting these inodes (See function findinodefast), then the reclaiming process destroy the inodes by function disposelist(). Some filesystems(eg. ext4 with ea_inode feature, ubifs with xattr) may do inode lookup in the inode evicting callback function, if the inode lookup is operated under the inode lru traversing context, deadlock problems may happen.

Case 1: In function ext4evictinode(), the ea inode lookup could happen if ea_inode feature is enabled, the lookup process will be stuck under the evicting context like this:

1. File A has inode ireg and an ea inode iea
2. getfattr(A, xattrbuf) // iea is added into lru // lru->i_ea

3. Then, following three processes running like this:

   PA PB echo 2 > /proc/sys/vm/dropcaches shrinkslab prunedcachesb // ireg is added into lru, lru->iea->ireg pruneicachesb listlruwalkone inodelruisolate iea->istate |= IFREEING // set inode state inodelruisolate _iget(ireg) spinunlock(&ireg->ilock) spinunlock(lrulock) rm file A ireg->nlink = 0 iput(ireg) // ireg->nlink is 0, do evict ext4evictinode ext4xattrdeleteinode ext4xattrinodedecrefall ext4xattrinodeiget ext4iget(iea->iino) igetlocked findinodefast _waitonfreeinginode(iea) ----→ AA deadlock disposelist // cannot be executed by pruneicachesb wakeupbit(&iea->istate)

Case 2: In deleted inode writing function ubifsjnlwriteinode(), file deleting process holds BASEHD's wbuf->iomutex while getting the xattr inode, which could race with inode reclaiming process(The reclaiming process could try locking BASEHD's wbuf->io_mutex in inode evicting function), then an ABBA deadlock problem would happen as following:

1. File A has inode ia and a xattr(with inode ixa), regular file B has inode ib and a xattr.
2. getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa

3. Then, following three processes running like this:

      PA                PB                        PC
              echo 2 > /proc/sys/vm/drop_caches
               shrink_slab
                prune_dcache_sb
                // ib and ia are added into lru, lru->ixa->ib->ia
                prune_icache_sb
                 list_lru_walk_one
                  inode_lru_isolate
                   ixa->i_state |= I_FREEING // set inode state
                  inode_lru_isolate
                   __iget(ib)
                   spin_unlock(&ib->i_lock)
                   spin_unlock(lru_lock)
                                                 rm file B
                                                  ib->nlink = 0
   

   rm file A iput(ia) ubifsevictinode(ia) ubifsjnldeleteinode(ia) ubifsjnlwriteinode(ia) makereservation(BASEHD) // Lock wbuf->iomutex ubifsiget(ixa->iino) igetlocked findinodefast _waitonfreeinginode(ixa) | iput(ib) // ib->nlink is 0, do evict | ubifsevictinode | ubifsjnldeleteinode(ib) ↓ ubifsjnlwriteinode ABBA deadlock ←-----makereservation(BASEHD) disposelist // cannot be executed by pruneicachesb wakeupbit(&ixa->istate)

Fix the possible deadlock by using new inode state flag ILRUISOLATING to pin the inode in memory while inodelruisolate( ---truncated---(CVE-2024-45003)

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

Input: MT - limit max slots

syzbot is reporting too large allocation at inputmtinitslots(), for numslots is supplied from userspace using ioctl(UIDEVCREATE).

Since nobody knows possible max slots, this patch chose 1024.(CVE-2024-45008)

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

net/mlx5e: Take state lock during tx timeout reporter

mlx5esafereopenchannels() requires the state lock taken. The referenced changed in the Fixes tag removed the lock to fix another issue. This patch adds it back but at a later point (when calling mlx5esafereopenchannels()) to avoid the deadlock referenced in the Fixes tag.(CVE-2024-45019)

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

fix bitmap corruption on closerange() with CLOSERANGE_UNSHARE

copyfdbitmaps(new, old, count) is expected to copy the first count/BITSPERLONG bits from old->fullfdsbits[] and fill the rest with zeroes. What it does is copying enough words (BITSTOLONGS(count/BITSPERLONG)), then memsets the rest. That works fine, if all bits past the cutoff point are clear. Otherwise we are risking garbage from the last word we'd copied.

For most of the callers that is true - expandfdtable() has count equal to old->maxfds, so there's no open descriptors past count, let alone fully occupied words in ->openfds[], which is what bits in ->fullfds_bits[] correspond to.

The other caller (dupfd()) passes sanefdtablesize(oldfdt, maxfds), which is the smallest multiple of BITSPERLONG that covers all opened descriptors below maxfds. In the common case (copying on fork()) maxfds is ~0U, so all opened descriptors will be below it and we are fine, by the same reasons why the call in expandfdtable() is safe.

Unfortunately, there is a case where maxfds is less than that and where we might, indeed, end up with junk in ->fullfdsbits[] - closerange(from, to, CLOSERANGEUNSHARE) with * descriptor table being currently shared * 'to' being above the current capacity of descriptor table * 'from' being just under some chunk of opened descriptors. In that case we end up with observably wrong behaviour - e.g. spawn a child with CLONEFILES, get all descriptors in range 0..127 open, then closerange(64, ~0U, CLOSERANGEUNSHARE) and watch dup(0) ending up with descriptor #128, despite #64 being observably not open.

The minimally invasive fix would be to deal with that in dupfd(). If this proves to add measurable overhead, we can go that way, but let's try to fix copyfd_bitmaps() first.

• new helper: bitmapcopyandexpand(to, from, bitsto_copy, size).
• make copyfdbitmaps() take the bitmap size in words, rather than bits; it's 'count' argument is always a multiple of BITSPERLONG, so we are not losing any information, and that way we can use the same helper for all three bitmaps - compiler will see that count is a multiple of BITSPERLONG for the large ones, so it'll generate plain memcpy()+memset().

Reproducer added to tools/testing/selftests/core/closerangetest.c(CVE-2024-45025)

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

btrfs: fix a use-after-free when hitting errors inside btrfssubmitchunk()

[BUG] There is an internal report that KASAN is reporting use-after-free, with the following backtrace:

BUG: KASAN: slab-use-after-free in btrfscheckreadbio+0xa68/0xb70 [btrfs] Read of size 4 at addr ffff8881117cec28 by task kworker/u16:2/45 CPU: 1 UID: 0 PID: 45 Comm: kworker/u16:2 Not tainted 6.11.0-rc2-next-20240805-default+ #76 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 Workqueue: btrfs-endio btrfsendbiowork [btrfs] Call Trace: dumpstacklvl+0x61/0x80 printaddressdescription.constprop.0+0x5e/0x2f0 printreport+0x118/0x216 kasanreport+0x11d/0x1f0 btrfscheckreadbio+0xa68/0xb70 [btrfs] processonework+0xce0/0x12a0 workerthread+0x717/0x1250 kthread+0x2e3/0x3c0 retfromfork+0x2d/0x70 retfromfork_asm+0x11/0x20

Allocated by task 20917: kasansavestack+0x37/0x60 kasansavetrack+0x10/0x30 _kasanslaballoc+0x7d/0x80 kmemcacheallocnoprof+0x16e/0x3e0 mempoolallocnoprof+0x12e/0x310 bioallocbioset+0x3f0/0x7a0 btrfsbioalloc+0x2e/0x50 [btrfs] submitextentpage+0x4d1/0xdb0 [btrfs] btrfsdoreadpage+0x8b4/0x12a0 [btrfs] btrfsreadahead+0x29a/0x430 [btrfs] readpages+0x1a7/0xc60 pagecacheraunbounded+0x2ad/0x560 filemapgetpages+0x629/0xa20 filemapread+0x335/0xbf0 vfsread+0x790/0xcb0 ksysread+0xfd/0x1d0 dosyscall64+0x6d/0x140 entrySYSCALL64afterhwframe+0x4b/0x53

Freed by task 20917: kasansavestack+0x37/0x60 kasansavetrack+0x10/0x30 kasansavefreeinfo+0x37/0x50 _kasanslabfree+0x4b/0x60 kmemcachefree+0x214/0x5d0 biofree+0xed/0x180 endbbiodataread+0x1cc/0x580 [btrfs] btrfssubmitchunk+0x98d/0x1880 [btrfs] btrfssubmitbio+0x33/0x70 [btrfs] submitonebio+0xd4/0x130 [btrfs] submitextentpage+0x3ea/0xdb0 [btrfs] btrfsdoreadpage+0x8b4/0x12a0 [btrfs] btrfsreadahead+0x29a/0x430 [btrfs] readpages+0x1a7/0xc60 pagecacheraunbounded+0x2ad/0x560 filemapgetpages+0x629/0xa20 filemapread+0x335/0xbf0 vfsread+0x790/0xcb0 ksysread+0xfd/0x1d0 dosyscall64+0x6d/0x140 entrySYSCALL64afterhwframe+0x4b/0x53

[CAUSE] Although I cannot reproduce the error, the report itself is good enough to pin down the cause.

The call trace is the regular endio workqueue context, but the free-by-task trace is showing that during btrfssubmitchunk() we already hit a critical error, and is calling btrfsbioendio() to error out. And the original endio function called bioput() to free the whole bio.

This means a double freeing thus causing use-after-free, e.g.:

1. Enter btrfssubmitbio() with a read bio The read bio length is 128K, crossing two 64K stripes.

2. The first run of btrfssubmitchunk()

2.1 Call btrfsmapblock(), which returns 64K 2.2 Call btrfssplitbio() Now there are two bios, one referring to the first 64K, the other referring to the second 64K. 2.3 The first half is submitted.

3. The second run of btrfssubmitchunk()

3.1 Call btrfsmapblock(), which by somehow failed Now we call btrfsbioend_io() to handle the error

3.2 btrfsbioendio() calls the original endio function Which is endbbiodataread(), and it calls bio_put() for the original bio.

Now the original bio is freed.

4. The submitted first 64K bio finished Now we call into btrfscheckread_bio() and tries to advance the bio iter. But since the original bio (thus its iter) is already freed, we trigger the above use-after free.

   And even if the memory is not poisoned/corrupted, we will later call the original endio function, causing a double freeing.

[FIX] Instead of calling btrfsbioendio(), call btrfsorigbbioend_io(), which has the extra check on split bios and do the pr ---truncated---(CVE-2024-46687)

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

tty: serial: fsllpuart: mark last busy before uartaddoneport

With "earlycon initcall_debug=1 loglevel=8" in bootargs, kernel sometimes boot hang. It is because normal console still is not ready, but runtime suspend is called, so early console putchar will hang in waiting TRDE set in UARTSTAT.

The lpuart driver has auto suspend delay set to 3000ms, but during uartaddoneport, a child device serial ctrl will added and probed with its pm runtime enabled(see serialctrl.c). The runtime suspend call path is: deviceadd |-> busprobedevice |->deviceinitialprobe |->deviceattach |-> pmruntimegetsync(dev->parent); |-> pmrequestidle(dev); |-> pmruntime_put(dev->parent);

So in the end, before normal console ready, the lpuart get runtime suspended. And earlycon putchar will hang.

To address the issue, mark last busy just after pmruntimeenable, three seconds is long enough to switch from bootconsole to normal console.(CVE-2024-46706)

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

drm/amd/display: Skip wbsclsetscaler_filter if filter is null

Callers can pass null in filter (i.e. from returned from the function wbsclgetfiltercoeffs16p) and a null check is added to ensure that is not the case.

This fixes 4 NULL_RETURNS issues reported by Coverity.(CVE-2024-46714)

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

drm/amdgpu: fix dereference after null check

check the pointer hive before use.(CVE-2024-46720)

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

drm/amdgpu: fix ucode out-of-bounds read warning

Clear warning that read ucode[] may out-of-bounds.(CVE-2024-46723)

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

drm/amd/pm: fix the Out-of-bounds read warning

using index i - 1U may beyond element index for mc_data[] when i = 0.(CVE-2024-46731)

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

btrfs: fix qgroup reserve leaks in cowfilerange

In the buffered write path, the dirty page owns the qgroup reserve until it creates an ordered_extent.

Therefore, any errors that occur before the orderedextent is created must free that reservation, or else the space is leaked. The fstest generic/475 exercises various IO error paths, and is able to trigger errors in cowfile_range where we fail to get to allocating the ordered extent. Note that because we do clear delalloc, we are likely to remove the inode from the delalloc list, so the inodes/pages to not have invalidate/launder called on them in the commit abort path.

This results in failures at the unmount stage of the test that look like:

BTRFS: error (device dm-8 state EA) in cleanuptransaction:2018: errno=-5 IO failure BTRFS: error (device dm-8 state EA) in btrfsreplacefileextents:2416: errno=-5 IO failure BTRFS warning (device dm-8 state EA): qgroup 0/5 has unreleased space, type 0 rsv 28672 ------------[ cut here ]------------ WARNING: CPU: 3 PID: 22588 at fs/btrfs/disk-io.c:4333 closectree+0x222/0x4d0 [btrfs] Modules linked in: btrfs blake2bgeneric libcrc32c xor zstdcompress raid6pq CPU: 3 PID: 22588 Comm: umount Kdump: loaded Tainted: G W 6.10.0-rc7-gab56fde445b8 #21 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 RIP: 0010:closectree+0x222/0x4d0 [btrfs] RSP: 0018:ffffb4465283be00 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffffa1a1818e1000 RCX: 0000000000000001 RDX: 0000000000000000 RSI: ffffb4465283bbe0 RDI: ffffa1a19374fcb8 RBP: ffffa1a1818e13c0 R08: 0000000100028b16 R09: 0000000000000000 R10: 0000000000000003 R11: 0000000000000003 R12: ffffa1a18ad7972c R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f9168312b80(0000) GS:ffffa1a4afcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f91683c9140 CR3: 000000010acaa000 CR4: 00000000000006f0 Call Trace: <TASK> ? closectree+0x222/0x4d0 [btrfs] ? _warn.cold+0x8e/0xea ? closectree+0x222/0x4d0 [btrfs] ? reportbug+0xff/0x140 ? handlebug+0x3b/0x70 ? excinvalidop+0x17/0x70 ? asmexcinvalidop+0x1a/0x20 ? closectree+0x222/0x4d0 [btrfs] genericshutdownsuper+0x70/0x160 killanonsuper+0x11/0x40 btrfskillsuper+0x11/0x20 [btrfs] deactivatelockedsuper+0x2e/0xa0 cleanupmnt+0xb5/0x150 taskworkrun+0x57/0x80 syscallexittousermode+0x121/0x130 dosyscall64+0xab/0x1a0 entrySYSCALL64after_hwframe+0x77/0x7f RIP: 0033:0x7f916847a887 ---[ end trace 0000000000000000 ]--- BTRFS error (device dm-8 state EA): qgroup reserved space leaked

Cases 2 and 3 in the outreserve path both pertain to this type of leak and must free the reserved qgroup data. Because it is already an error path, I opted not to handle the possible errors in btrfsfreeqgroupdata.(CVE-2024-46733)

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

smb/server: fix potential null-ptr-deref of leasectxinfo in smb2_open()

null-ptr-deref will occur when (reqoplevel == SMB2OPLOCKLEVELLEASE) and parselease_state() return NULL.

Fix this by check if 'leasectxinfo' is NULL.

Additionally, remove the redundant parentheses in parsedurablehandle_context().(CVE-2024-46742)

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

Squashfs: sanity check symbolic link size

Syzkiller reports a "KMSAN: uninit-value in pick_link" bug.

This is caused by an uninitialised page, which is ultimately caused by a corrupted symbolic link size read from disk.

The reason why the corrupted symlink size causes an uninitialised page is due to the following sequence of events:

1. squashfsreadinode() is called to read the symbolic link from disk. This assigns the corrupted value 3875536935 to inode->i_size.

2. Later squashfssymlinkread_folio() is called, which assigns this corrupted value to the length variable, which being a signed int, overflows producing a negative number.

3. The following loop that fills in the page contents checks that the copied bytes is less than length, which being negative means the loop is skipped, producing an uninitialised page.

This patch adds a sanity check which checks that the symbolic link size is not larger than expected.

--

V2: fix spelling mistake.(CVE-2024-46744)

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

Input: uinput - reject requests with unreasonable number of slots

When exercising uinput interface syzkaller may try setting up device with a really large number of slots, which causes memory allocation failure in inputmtinit_slots(). While this allocation failure is handled properly and request is rejected, it results in syzkaller reports. Additionally, such request may put undue burden on the system which will try to free a lot of memory for a bogus request.

Fix it by limiting allowed number of slots to 100. This can easily be extended if we see devices that can track more than 100 contacts.(CVE-2024-46745)

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

HID: cougar: fix slab-out-of-bounds Read in cougarreportfixup

report_fixup for the Cougar 500k Gaming Keyboard was not verifying that the report descriptor size was correct before accessing it(CVE-2024-46747)

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

btrfs: don't BUGON() when 0 reference count at btrfslookupextentinfo()

Instead of doing a BUG_ON() handle the error by returning -EUCLEAN, aborting the transaction and logging an error message.(CVE-2024-46751)

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

btrfs: replace BUGON() with error handling at updaterefforcow()

Instead of a BUG_ON() just return an error, log an error message and abort the transaction in case we find an extent buffer belonging to the relocation tree that doesn't have the full backref flag set. This is unexpected and should never happen (save for bugs or a potential bad memory).(CVE-2024-46752)

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

hwmon: (adc128d818) Fix underflows seen when writing limit attributes

DIVROUNDCLOSEST() after kstrtol() results in an underflow if a large negative number such as -9223372036854775808 is provided by the user. Fix it by reordering clampval() and DIVROUND_CLOSEST() operations.(CVE-2024-46759)

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

eventfs: Use listdelrcu() for SRCU protected list variable

Chi Zhiling reported:

We found a null pointer accessing in tracefs[1], the reason is that the variable 'eichild' is set to LISTPOISON1, that means the list was removed in eventfsremoverec. so when access the eichild->isfreed, the panic triggered.

by the way, the following script can reproduce this panic

loop1 (){ while true do echo "p:kp submitbio" > /sys/kernel/debug/tracing/kprobeevents echo "" > /sys/kernel/debug/tracing/kprobe_events done } loop2 (){ while true do tree /sys/kernel/debug/tracing/events/kprobes/ done } loop1 & loop2

[ 1147.968239][T17331] Mem abort info: [ 1147.971739][T17331] ESR = 0x0000000096000004 [ 1147.976172][T17331] EC = 0x25: DABT (current EL), IL = 32 bits [ 1147.982171][T17331] SET = 0, FnV = 0 [ 1147.985906][T17331] EA = 0, S1PTW = 0 [ 1147.989734][T17331] FSC = 0x04: level 0 translation fault [ 1147.995292][T17331] Data abort info: [ 1147.998858][T17331] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 1148.005023][T17331] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 1148.010759][T17331] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1148.016752][T17331] [dead000000000150] address between user and kernel address ranges [ 1148.024571][T17331] Internal error: Oops: 0000000096000004 [#1] SMP [ 1148.030825][T17331] Modules linked in: teammodeloadbalance team nlmon actgact clsflower schingress bonding tls macvlan dummy ibcore bridge stp llc veth amdgpu amdxcp mfdcore gpusched drmexec drmbuddy radeon crct10difce video drmsuballochelper ghashce drmttmhelper sha2ce ttm sha256arm64 i2calgobit sha1ce sbsagwdt cp210x drmdisplayhelper cec srmod cdrom drmkmshelper binfmtmisc sg loop fuse drm dmmod nfnetlink iptables autofs4 [last unloaded: tls] [ 1148.072808][T17331] CPU: 3 PID: 17331 Comm: ls Tainted: G W ------- ---- 6.6.43 #2 [ 1148.081751][T17331] Source Version: 21b3b386e948bedd29369af66f3e98ab01b1c650 [ 1148.088783][T17331] Hardware name: Greatwall GW-001M1A-FTF/GW-001M1A-FTF, BIOS KunLun BIOS V4.0 07/16/2020 [ 1148.098419][T17331] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1148.106060][T17331] pc : eventfsiterate+0x2c0/0x398 [ 1148.111017][T17331] lr : eventfsiterate+0x2fc/0x398 [ 1148.115969][T17331] sp : ffff80008d56bbd0 [ 1148.119964][T17331] x29: ffff80008d56bbf0 x28: ffff001ff5be2600 x27: 0000000000000000 [ 1148.127781][T17331] x26: ffff001ff52ca4e0 x25: 0000000000009977 x24: dead000000000100 [ 1148.135598][T17331] x23: 0000000000000000 x22: 000000000000000b x21: ffff800082645f10 [ 1148.143415][T17331] x20: ffff001fddf87c70 x19: ffff80008d56bc90 x18: 0000000000000000 [ 1148.151231][T17331] x17: 0000000000000000 x16: 0000000000000000 x15: ffff001ff52ca4e0 [ 1148.159048][T17331] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 1148.166864][T17331] x11: 0000000000000000 x10: 0000000000000000 x9 : ffff8000804391d0 [ 1148.174680][T17331] x8 : 0000000180000000 x7 : 0000000000000018 x6 : 0000aaab04b92862 [ 1148.182498][T17331] x5 : 0000aaab04b92862 x4 : 0000000080000000 x3 : 0000000000000068 [ 1148.190314][T17331] x2 : 000000000000000f x1 : 0000000000007ea8 x0 : 0000000000000001 [ 1148.198131][T17331] Call trace: [ 1148.201259][T17331] eventfsiterate+0x2c0/0x398 [ 1148.205864][T17331] iteratedir+0x98/0x188 [ 1148.210036][T17331] _arm64sysgetdents64+0x78/0x160 [ 1148.215161][T17331] invokesyscall+0x78/0x108 [ 1148.219593][T17331] el0svccommon.constprop.0+0x48/0xf0 [ 1148.224977][T17331] doel0svc+0x24/0x38 [ 1148.228974][T17331] el0_svc+0x40/0x168 [ 1148.232798][T17 ---truncated---(CVE-2024-46785)

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

fscache: delete fscachecookielru_timer when fscache exits to avoid UAF

The fscachecookielrutimer is initialized when the fscache module is inserted, but is not deleted when the fscache module is removed. If timerreduce() is called before removing the fscache module, the fscachecookielru_timer will be added to the timer list of the current cpu. Afterwards, a use-after-free will be triggered in the softIRQ after removing the fscache module, as follows:

================================================================== BUG: unable to handle page fault for address: fffffbfff803c9e9 PF: supervisor read access in kernel mode PF: errorcode(0x0000) - not-present page PGD 21ffea067 P4D 21ffea067 PUD 21ffe6067 PMD 110a7c067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Tainted: G W 6.11.0-rc3 #855 Tainted: [W]=WARN RIP: 0010:runtimerbase.part.0+0x254/0x8a0 Call Trace: <IRQ> tmigrhandleremoteup+0x627/0x810 _walkgroups.isra.0+0x47/0x140 tmigrhandleremote+0x1fa/0x2f0 handlesoftirqs+0x180/0x590 irqexitrcu+0x84/0xb0 sysvecapictimerinterrupt+0x6e/0x90 </IRQ> <TASK> asmsysvecapictimerinterrupt+0x1a/0x20 RIP: 0010:defaultidle+0xf/0x20 defaultidlecall+0x38/0x60 doidle+0x2b5/0x300 cpustartupentry+0x54/0x60 startsecondary+0x20d/0x280 commonstartup_64+0x13e/0x148 </TASK>

Modules linked in: [last unloaded: netfs]

Therefore delete fscachecookielru_timer when removing the fscahe module.(CVE-2024-46786)

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

sch/netem: fix use after free in netem_dequeue

If netemdequeue() enqueues packet to inner qdisc and that qdisc returns _NETXMITSTOLEN. The packet is dropped but qdisctreereduce_backlog() is not called to update the parent's q.qlen, leading to the similar use-after-free as Commit e04991a48dbaf382 ("netem: fix return value if duplicate enqueue fails")

Commands to trigger KASAN UaF:

ip link add type dummy ip link set lo up ip link set dummy0 up tc qdisc add dev lo parent root handle 1: drr tc filter add dev lo parent 1: basic classid 1:1 tc class add dev lo classid 1:1 drr tc qdisc add dev lo parent 1:1 handle 2: netem tc qdisc add dev lo parent 2: handle 3: drr tc filter add dev lo parent 3: basic classid 3:1 action mirred egress redirect dev dummy0 tc class add dev lo classid 3:1 drr ping -c1 -W0.01 localhost # Trigger bug tc class del dev lo classid 1:1 tc class add dev lo classid 1:1 drr ping -c1 -W0.01 localhost # UaF(CVE-2024-46800)