OESA-2024-1796

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

ubifs: Set page uptodate in the correct place

Page cache reads are lockless, so setting the freshly allocated page uptodate before we've overwritten it with the data it's supposed to have in it will allow a simultaneous reader to see old data. Move the call to SetPageUptodate into ubifswriteend(), which is after we copied the new data into the page.(CVE-2024-35821)

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

kprobes: Fix possible use-after-free issue on kprobe registration

When unloading a module, its state is changing MODULESTATELIVE -> MODULESTATEGOING -> MODULESTATEUNFORMED. Each change will take a time. is_module_text_address() and __module_text_address() works with MODULESTATELIVE and MODULESTATEGOING. If we use is_module_text_address() and __module_text_address() separately, there is a chance that the first one is succeeded but the next one is failed because module->state becomes MODULESTATEUNFORMED between those operations.

In check_kprobe_address_safe(), if the second __module_text_address() is failed, that is ignored because it expected a kerneltext address. But it may have failed simply because module->state has been changed to MODULESTATEUNFORMED. In this case, armkprobe() will try to modify non-exist module text address (use-after-free).

To fix this problem, we should not use separated is_module_text_address() and __module_text_address(), but use only __module_text_address() once and do try_module_get(module) which is only available with MODULESTATELIVE.(CVE-2024-35955)

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

net/sched: taprio: always validate TCATAPRIOATTR_PRIOMAP

If one TCATAPRIOATTRPRIOMAP attribute has been provided, taprioparsemqprioopt() must validate it, or userspace can inject arbitrary data to the kernel, the second time taprio_change() is called.

First call (with valid attributes) sets dev->num_tc to a non zero value.

Second call (with arbitrary mqprio attributes) returns early from taprioparsemqprio_opt() and bad things can happen.(CVE-2024-36974)

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

tcp: Fix shift-out-of-bounds in dctcpupdatealpha().

In dctcpupdatealpha(), we use a module parameter dctcpshiftg as follows:

alpha -= minnotzero(alpha, alpha >> dctcpshiftg); ... deliveredce <<= (10 - dctcpshift_g);

It seems syzkaller started fuzzing module parameters and triggered shift-out-of-bounds [0] by setting 100 to dctcpshiftg:

memcpy((void)0x20000080, "/sys/module/tcp_dctcp/parameters/dctcp_shift_g\000", 47); res = syscall(NR_openat, /fd=/0xffffffffffffff9cul, /file=/0x20000080ul, /flags=/2ul, /mode=/0ul); memcpy((void)0x20000000, "100\000", 4); syscall(NR_write, /fd=/r[0], /val=/0x20000000ul, /len=/4ul);

Let's limit the max value of dctcpshiftg by paramsetuint_minmax().

With this patch:

# echo 10 > /sys/module/tcpdctcp/parameters/dctcpshiftg # cat /sys/module/tcpdctcp/parameters/dctcpshiftg 10 # echo 11 > /sys/module/tcpdctcp/parameters/dctcpshift_g -bash: echo: write error: Invalid argument

shift exponent 100 is too large for 32-bit type 'u32' (aka 'unsigned int') CPU: 0 PID: 8083 Comm: syz-executor345 Not tainted 6.9.0-05151-g1b294a1f3561 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x201/0x300 lib/dumpstack.c:114 ubsanepilogue lib/ubsan.c:231 [inline] _ubsanhandleshiftoutofbounds+0x346/0x3a0 lib/ubsan.c:468 dctcpupdatealpha+0x540/0x570 net/ipv4/tcpdctcp.c:143 tcpinackevent net/ipv4/tcpinput.c:3802 [inline] tcpack+0x17b1/0x3bc0 net/ipv4/tcpinput.c:3948 tcprcvstateprocess+0x57a/0x2290 net/ipv4/tcpinput.c:6711 tcpv4dorcv+0x764/0xc40 net/ipv4/tcpipv4.c:1937 skbacklogrcv include/net/sock.h:1106 [inline] _releasesock+0x20f/0x350 net/core/sock.c:2983 releasesock+0x61/0x1f0 net/core/sock.c:3549 mptcpsubflowshutdown+0x3d0/0x620 net/mptcp/protocol.c:2907 mptcpchecksenddatafin+0x225/0x410 net/mptcp/protocol.c:2976 _mptcpclose+0x238/0xad0 net/mptcp/protocol.c:3072 mptcpclose+0x2a/0x1a0 net/mptcp/protocol.c:3127 inetrelease+0x190/0x1f0 net/ipv4/afinet.c:437 _sockrelease net/socket.c:659 [inline] sockclose+0xc0/0x240 net/socket.c:1421 _fput+0x41b/0x890 fs/filetable.c:422 taskworkrun+0x23b/0x300 kernel/taskwork.c:180 exittaskwork include/linux/taskwork.h:38 [inline] doexit+0x9c8/0x2540 kernel/exit.c:878 dogroupexit+0x201/0x2b0 kernel/exit.c:1027 _dosysexitgroup kernel/exit.c:1038 [inline] _sesysexitgroup kernel/exit.c:1036 [inline] _x64sysexitgroup+0x3f/0x40 kernel/exit.c:1036 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xe4/0x240 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x67/0x6f RIP: 0033:0x7f6c2b5005b6 Code: Unable to access opcode bytes at 0x7f6c2b50058c. RSP: 002b:00007ffe883eb948 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00007f6c2b5862f0 RCX: 00007f6c2b5005b6 RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001 RBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0 R10: 0000000000000006 R11: 0000000000000246 R12: 00007f6c2b5862f0 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001 </TASK>(CVE-2024-37356)

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

of: module: add buffer overflow check in of_modalias()

In of_modalias(), if the buffer happens to be too small even for the 1st snprintf() call, the len parameter will become negative and str parameter (if not NULL initially) will point beyond the buffer's end. Add the buffer overflow check after the 1st snprintf() call and fix such check after the strlen() call (accounting for the terminating NUL char).(CVE-2024-38541)

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

net/mlx5: Add a timeout to acquire the command queue semaphore

Prevent forced completion handling on an entry that has not yet been assigned an index, causing an out of bounds access on idx = -22. Instead of waiting indefinitely for the sem, blocking flow now waits for index to be allocated or a sem acquisition timeout before beginning the timer for FW completion.

Kernel log example: mlx5core 0000:06:00.0: waitfunchandleexectimeout:1128:(pid 185911): cmd[-22]: CREATEUCTX(0xa04) No done completion(CVE-2024-38556)

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

bpf: Add BPFPROGTYPECGROUPSKB attach type enforcement in BPFLINKCREATE

bpfprogattach uses attachtypetoprogtype to enforce proper attach type for BPFPROGTYPECGROUPSKB. linkcreate uses bpfprogget and relies on bpfprogattachcheckattachtype to properly verify progtype <> attachtype association.

Add missing attachtype enforcement for the linkcreate case. Otherwise, it's currently possible to attach cgroup_skb prog types to other cgroup hooks.(CVE-2024-38564)

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

ftrace: Fix possible use-after-free issue in ftrace_location()

KASAN reports a bug:

BUG: KASAN: use-after-free in ftracelocation+0x90/0x120 Read of size 8 at addr ffff888141d40010 by task insmod/424 CPU: 8 PID: 424 Comm: insmod Tainted: G W 6.9.0-rc2+ [...] Call Trace: <TASK> dumpstacklvl+0x68/0xa0 printreport+0xcf/0x610 kasanreport+0xb5/0xe0 ftracelocation+0x90/0x120 registerkprobe+0x14b/0xa40 kprobeinit+0x2d/0xff0 [kprobeexample] dooneinitcall+0x8f/0x2d0 doinitmodule+0x13a/0x3c0 loadmodule+0x3082/0x33d0 initmodulefromfile+0xd2/0x130 _x64sysfinitmodule+0x306/0x440 dosyscall64+0x68/0x140 entrySYSCALL64after_hwframe+0x71/0x79

The root cause is that, in lookuprec(), ftrace record of some address is being searched in ftrace pages of some module, but those ftrace pages at the same time is being freed in ftracerelease_mod() as the corresponding module is being deleted:

       CPU1                       |      CPU2

registerkprobes() { | deletemodule() { checkkprobeaddresssafe() { | archcheckftracelocation() { | ftracelocation() { | lookuprec() // USE! | ftracereleasemod() // Free!

To fix this issue: 1. Hold rcu lock as accessing ftrace pages in ftracelocationrange(); 2. Use ftracelocationrange() instead of lookuprec() in ftracelocation(); 3. Call synchronizercu() before freeing any ftrace pages both in ftraceprocesslocs()/ftracereleasemod()/ftracefree_mem().(CVE-2024-38588)

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

jffs2: prevent xattr node from overflowing the eraseblock

Add a check to make sure that the requested xattr node size is no larger than the eraseblock minus the cleanmarker.

Unlike the usual inode nodes, the xattr nodes aren't split into parts and spread across multiple eraseblocks, which means that a xattr node must not occupy more than one eraseblock. If the requested xattr value is too large, the xattr node can spill onto the next eraseblock, overwriting the nodes and causing errors such as:

jffs2: argh. node added in wrong place at 0x0000b050(2) jffs2: nextblock 0x0000a000, expected at 0000b00c jffs2: error: (823) doverifyxattrdatum: node CRC failed at 0x01e050, read=0xfc892c93, calc=0x000000 jffs2: notice: (823) jffs2getinodenodes: Node header CRC failed at 0x01e00c. {848f,2fc4,0fef511f,59a3d171} jffs2: Node at 0x0000000c with length 0x00001044 would run over the end of the erase block jffs2: Perhaps the file system was created with the wrong erase size? jffs2: jffs2scaneraseblock(): Magic bitmask 0x1985 not found at 0x00000010: 0x1044 instead

This breaks the filesystem and can lead to KASAN crashes such as:

BUG: KASAN: slab-out-of-bounds in jffs2sumaddkvec+0x125e/0x15d0 Read of size 4 at addr ffff88802c31e914 by task repro/830 CPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 Call Trace: <TASK> dumpstacklvl+0xc6/0x120 printreport+0xc4/0x620 ? _virtaddrvalid+0x308/0x5b0 kasanreport+0xc1/0xf0 ? jffs2sumaddkvec+0x125e/0x15d0 ? jffs2sumaddkvec+0x125e/0x15d0 jffs2sumaddkvec+0x125e/0x15d0 jffs2flashdirectwritev+0xa8/0xd0 jffs2flashwritev+0x9c9/0xef0 ? _x64syssetxattr+0xc4/0x160 ? dosyscall64+0x69/0x140 ? entrySYSCALL64after_hwframe+0x76/0x7e [...]

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2024-38599)

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

fs/ntfs3: Use variable length array instead of fixed size

Should fix smatch warning: ntfssetlabel() error: _builtinmemcpy() 'uni->name' too small (20 vs 256)(CVE-2024-38623)

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

fs/ntfs3: Use 64 bit variable to avoid 32 bit overflow

For example, in the expression: vbo = 2 * vbo + skip(CVE-2024-38624)

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

watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger

When the cpu5wdt module is removing, the origin code uses deltimer() to de-activate the timer. If the timer handler is running, deltimer() could not stop it and will return directly. If the port region is released by releaseregion() and then the timer handler cpu5wdttrigger() calls outb() to write into the region that is released, the use-after-free bug will happen.

Change deltimer() to timershutdown_sync() in order that the timer handler could be finished before the port region is released.(CVE-2024-38630)

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

s390/ap: Fix crash in AP internal function modify_bitmap()

A system crash like this

Failing address: 200000cb7df6f000 TEID: 200000cb7df6f403 Fault in home space mode while using kernel ASCE. AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d Oops: 0038 ilc:3 [#1] PREEMPT SMP Modules linked in: mlx5ib ... CPU: 8 PID: 7556 Comm: bash Not tainted 6.9.0-rc7 #8 Hardware name: IBM 3931 A01 704 (LPAR) Krnl PSW : 0704e00180000000 0000014b75e7b606 (apparsebitmapstr+0x10e/0x1f8) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 0000000000000001 ffffffffffffffc0 0000000000000001 00000048f96b75d3 000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7df6fce0 000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff 000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8 Krnl Code: 0000014b75e7b5fc: a7840047 brc 8,0000014b75e7b68a 0000014b75e7b600: 18b2 lr %r11,%r2 #0000014b75e7b602: a7f4000a brc 15,0000014b75e7b616 >0000014b75e7b606: eb22d00000e6 laog %r2,%r2,0(%r13) 0000014b75e7b60c: a7680001 lhi %r6,1 0000014b75e7b610: 187b lr %r7,%r11 0000014b75e7b612: 84960021 brxh %r9,%r6,0000014b75e7b654 0000014b75e7b616: 18e9 lr %r14,%r9 Call Trace: [<0000014b75e7b606>] apparsebitmapstr+0x10e/0x1f8 ([<0000014b75e7b5dc>] apparsebitmapstr+0xe4/0x1f8) [<0000014b75e7b758>] apmaskstore+0x68/0x140 [<0000014b75679196>] kernfsfopwriteiter+0x14e/0x1e8 [<0000014b75598524>] vfswrite+0x1b4/0x448 [<0000014b7559894c>] ksyswrite+0x74/0x100 [<0000014b7618a440>] _dosyscall+0x268/0x328 [<0000014b761a3558>] systemcall+0x70/0x98 INFO: lockdep is turned off. Last Breaking-Event-Address: [<0000014b75e7b636>] apparsebitmapstr+0x13e/0x1f8 Kernel panic - not syncing: Fatal exception: paniconoops

occured when /sys/bus/ap/a[pq]mask was updated with a relative mask value (like +0x10-0x12,+60,-90) with one of the numeric values exceeding INT_MAX.

The fix is simple: use unsigned long values for the internal variables. The correct checks are already in place in the function but a simple int for the internal variables was used with the possibility to overflow.(CVE-2024-38661)

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

um: Add winch to winch_handlers before registering winch IRQ

Registering a winch IRQ is racy, an interrupt may occur before the winch is added to the winch_handlers list.

If that happens, registerwinchirq() adds to that list a winch that is scheduled to be (or has already been) freed, causing a panic later in winch_cleanup().

Avoid the race by adding the winch to the winchhandlers list before registering the IRQ, and rolling back if umrequest_irq() fails.(CVE-2024-39292)