OESA-2024-1395

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

ALSA: hda: intel-sdw-acpi: harden detection of controller

The existing code currently sets a pointer to an ACPI handle before checking that it's actually a SoundWire controller. This can lead to issues where the graph walk continues and eventually fails, but the pointer was set already.

This patch changes the logic so that the information provided to the caller is set when a controller is found.(CVE-2021-46926)

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

ASoC: q6afe-clocks: fix reprobing of the driver

Q6afe-clocks driver can get reprobed. For example if the APR services are restarted after the firmware crash. However currently Q6afe-clocks driver will oops because hw.init will get cleared during first _probe call. Rewrite the driver to fill the clock data at runtime rather than using big static array of clocks.(CVE-2021-47037)

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

apparmor: avoid crash when parsed profile name is empty

When processing a packed profile in unpack_profile() described like

"profile :ns::samba-dcerpcd /usr/lib*/samba/{,samba/}samba-dcerpcd {...}"

a string ":samba-dcerpcd" is unpacked as a fully-qualified name and then passed to aasplitnfqname().

aasplitnfqname() treats ":samba-dcerpcd" as only containing a namespace. Thus it returns NULL for tmpname, meanwhile tmpns is non-NULL. Later aaallocprofile() crashes as the new profile name is NULL now.

general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 6 PID: 1657 Comm: apparmorparser Not tainted 6.7.0-rc2-dirty #16 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 RIP: 0010:strlen+0x1e/0xa0 Call Trace: <TASK> ? strlen+0x1e/0xa0 aapolicyinit+0x1bb/0x230 aaallocprofile+0xb1/0x480 unpackprofile+0x3bc/0x4960 aaunpack+0x309/0x15e0 aareplaceprofiles+0x213/0x33c0 policyupdate+0x261/0x370 profilereplace+0x20e/0x2a0 vfswrite+0x2af/0xe00 ksyswrite+0x126/0x250 dosyscall64+0x46/0xf0 entrySYSCALL64after_hwframe+0x6e/0x76 </TASK> ---[ end trace 0000000000000000 ]--- RIP: 0010:strlen+0x1e/0xa0

It seems such behaviour of aasplitnfqname() is expected and checked in other places where it is called (e.g. aaremoveprofiles). Well, there is an explicit comment "a ns name without a following profile is allowed" inside.

AFAICS, nothing can prevent unpacked "name" to be in form like ":samba-dcerpcd" - it is passed from userspace.

Deny the whole profile set replacement in such case and inform user with EPROTO and an explaining message.

Found by Linux Verification Center (linuxtesting.org).(CVE-2023-52443)

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

nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length

If the host sends an H2CData command with an invalid DATAL, the kernel may crash in nvmettcpbuildpduiovec().

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 lr : nvmettcpiowork+0x6ac/0x718 [nvmettcp] Call trace: processonework+0x174/0x3c8 worker_thread+0x2d0/0x3e8 kthread+0x104/0x110

Fix the bug by raising a fatal error if DATAL isn't coherent with the packet size. Also, the PDU length should never exceed the MAXH2CDATA parameter which has been communicated to the host in nvmettcphandle_icreq().(CVE-2023-52454)

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

serial: imx: fix tx statemachine deadlock

When using the serial port as RS485 port, the tx statemachine is used to control the RTS pin to drive the RS485 transceiver TXEN pin. When the TTY port is closed in the middle of a transmission (for instance during userland application crash), imxuartshutdown disables the interface and disables the Transmission Complete interrupt. afer that, imxuartstoptx bails on an incomplete transmission, to be retriggered by the TC interrupt. This interrupt is disabled and therefore the tx statemachine never transitions out of SEND. The statemachine is in deadlock now, and the TX_EN remains low, making the interface useless.

imxuartstoptx now checks for incomplete transmission AND whether TC interrupts are enabled before bailing to be retriggered. This makes sure the state machine handling is reached, and is properly set to WAITAFTER_SEND.(CVE-2023-52456)

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

mfd: syscon: Fix null pointer dereference in ofsysconregister()

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

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

drivers/amd/pm: fix a use-after-free in kvparsepower_table

When ps allocated by kzalloc equals to NULL, kvparsepower_table frees adev->pm.dpm.ps that allocated before. However, after the control flow goes through the following call chains:

kvparsepowertable |-> kvdpminit |-> kvdpmswinit |-> kvdpmfini

The adev->pm.dpm.ps is used in the for loop of kvdpmfini after its first free in kvparsepower_table and causes a use-after-free bug.(CVE-2023-52469)

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

perf/x86/lbr: Filter vsyscall addresses

We found that a panic can occur when a vsyscall is made while LBR sampling is active. If the vsyscall is interrupted (NMI) for perf sampling, this call sequence can occur (most recent at top):

__insn_get_emulate_prefix()
insn_get_emulate_prefix()
insn_get_prefixes()
insn_get_opcode()
decode_branch_type()
get_branch_type()
intel_pmu_lbr_filter()
intel_pmu_handle_irq()
perf_event_nmi_handler()

Within _insngetemulateprefix() at frame 0, a macro is called:

peek_nbyte_next(insn_byte_t, insn, i)

Within this macro, this dereference occurs:

(insn)->next_byte

Inspecting registers at this point, the value of the next_byte field is the address of the vsyscall made, for example the location of the vsyscall version of gettimeofday() at 0xffffffffff600000. The access to an address in the vsyscall region will trigger an oops due to an unhandled page fault.

To fix the bug, filtering for vsyscalls can be done when determining the branch type. This patch will return a "none" branch if a kernel address if found to lie in the vsyscall region.(CVE-2023-52476)

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

ksmbd: fix uaf in smb20oplockbreak_ack

drop reference after use opinfo.(CVE-2023-52479)

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

iommu/arm-smmu-v3: Fix soft lockup triggered by armsmmumminvalidaterange

When running an SVA case, the following soft lockup is triggered:

watchdog: BUG: soft lockup - CPU#244 stuck for 26s! pstate: 83400009 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : armsmmucmdqissuecmdlist+0x178/0xa50 lr : armsmmucmdqissuecmdlist+0x150/0xa50 sp : ffff8000d83ef290 x29: ffff8000d83ef290 x28: 000000003b9aca00 x27: 0000000000000000 x26: ffff8000d83ef3c0 x25: da86c0812194a0e8 x24: 0000000000000000 x23: 0000000000000040 x22: ffff8000d83ef340 x21: ffff0000c63980c0 x20: 0000000000000001 x19: ffff0000c6398080 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: ffff3000b4a3bbb0 x14: ffff3000b4a30888 x13: ffff3000b4a3cf60 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc08120e4d6bc x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000048cfa x5 : 0000000000000000 x4 : 0000000000000001 x3 : 000000000000000a x2 : 0000000080000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: armsmmucmdqissuecmdlist+0x178/0xa50 _armsmmutlbinvrange+0x118/0x254 armsmmutlbinvrangeasid+0x6c/0x130 armsmmumminvalidaterange+0xa0/0xa4 _mmunotifierinvalidaterangeend+0x88/0x120 unmapvmas+0x194/0x1e0 unmapregion+0xb4/0x144 domasalignmunmap+0x290/0x490 domasmunmap+0xbc/0x124 _vmmunmap+0xa8/0x19c _arm64sysmunmap+0x28/0x50 invokesyscall+0x78/0x11c el0svccommon.constprop.0+0x58/0x1c0 doel0svc+0x34/0x60 el0svc+0x2c/0xd4 el0t64synchandler+0x114/0x140

el0t64sync+0x1a4/0x1a8

Note that since 6.6-rc1 the armsmmumminvalidaterange above is renamed to "armsmmummarchinvalidatesecondarytlbs", yet the problem remains.

The commit 06ff87bae8d3 ("arm64: mm: remove unused functions and variable protoypes") fixed a similar lockup on the CPU MMU side. Yet, it can occur to SMMU too, since armsmmummarchinvalidatesecondarytlbs() is called typically next to MMU tlb flush function, e.g. tlbflushmmutlbonly { tlbflush { _flushtlbrange { // check MAXTLBIOPS } } mmunotifierarchinvalidatesecondarytlbs { armsmmummarchinvalidatesecondarytlbs { // does not check MAXTLBIOPS } } }

Clone a CMDQMAXTLBIOPS from the MAXTLBI_OPS in tlbflush.h, since in an SVA case SMMU uses the CPU page table, so it makes sense to align with the tlbflush code. Then, replace per-page TLBI commands with a single per-asid TLBI command, if the request size hits this threshold.(CVE-2023-52484)

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

tls: fix race between tx work scheduling and socket close

Similarly to previous commit, the submitting thread (recvmsg/sendmsg) may exit as soon as the async crypto handler calls complete(). Reorder scheduling the work before calling complete(). This seems more logical in the first place, as it's the inverse order of what the submitting thread will do.(CVE-2024-26585)

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

bpf: Reject variable offset alu on PTRTOFLOW_KEYS

For PTRTOFLOWKEYS, checkflowkeysaccess() only uses fixed off for validation. However, variable offset ptr alu is not prohibited for this ptr kind. So the variable offset is not checked.

The following prog is accepted:

func#0 @0 0: R1=ctx() R10=fp0 0: (bf) r6 = r1 ; R1=ctx() R6w=ctx() 1: (79) r7 = *(u64 *)(r6 +144) ; R6w=ctx() R7w=flowkeys() 2: (b7) r8 = 1024 ; R8w=1024 3: (37) r8 /= 1 ; R8w=scalar() 4: (57) r8 &= 1024 ; R8w=scalar(smin=smin32=0, smax=umax=smax32=umax32=1024,varoff=(0x0; 0x400)) 5: (0f) r7 += r8 markprecise: frame0: lastidx 5 firstidx 0 subseqidx -1 markprecise: frame0: regs=r8 stack= before 4: (57) r8 &= 1024 markprecise: frame0: regs=r8 stack= before 3: (37) r8 /= 1 markprecise: frame0: regs=r8 stack= before 2: (b7) r8 = 1024 6: R7w=flowkeys(smin=smin32=0,smax=umax=smax32=umax32=1024,varoff =(0x0; 0x400)) R8w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024, varoff=(0x0; 0x400)) 6: (79) r0 = *(u64 *)(r7 +0) ; R0_w=scalar() 7: (95) exit

This prog loads flow_keys to r7, and adds the variable offset r8 to r7, and finally causes out-of-bounds access:

BUG: unable to handle page fault for address: ffffc90014c80038 [...] Call Trace: <TASK> bpfdispatchernopfunc include/linux/bpf.h:1231 [inline] _bpfprogrun include/linux/filter.h:651 [inline] bpfprogrun include/linux/filter.h:658 [inline] bpfprogrunpinoncpu include/linux/filter.h:675 [inline] bpfflowdissect+0x15f/0x350 net/core/flowdissector.c:991 bpfprogtestrunflowdissector+0x39d/0x620 net/bpf/testrun.c:1359 bpfprogtestrun kernel/bpf/syscall.c:4107 [inline] _sysbpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475 _dosysbpf kernel/bpf/syscall.c:5561 [inline] _sesysbpf kernel/bpf/syscall.c:5559 [inline] _x64sysbpf+0x73/0xb0 kernel/bpf/syscall.c:5559 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x3f/0x110 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b

Fix this by rejecting ptr alu with variable offset on flowkeys. Applying the patch rejects the program with "R7 pointer arithmetic on flowkeys prohibited".(CVE-2024-26589)

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

i2c: i801: Fix block process call transactions

According to the Intel datasheets, software must reset the block buffer index twice for block process call transactions: once before writing the outgoing data to the buffer, and once again before reading the incoming data from the buffer.

The driver is currently missing the second reset, causing the wrong portion of the block buffer to be read.(CVE-2024-26593)

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

net: qualcomm: rmnet: fix global oob in rmnet_policy

The variable rmnetlinkops assign a bigger maxtype which leads to a global out-of-bounds read when parsing the netlink attributes. See bug trace below:

================================================================== BUG: KASAN: global-out-of-bounds in validatenla lib/nlattr.c:386 [inline] BUG: KASAN: global-out-of-bounds in _nlavalidateparse+0x24af/0x2750 lib/nlattr.c:600 Read of size 1 at addr ffffffff92c438d0 by task syz-executor.6/84207

CPU: 0 PID: 84207 Comm: syz-executor.6 Tainted: G N 6.1.0 #3 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+0x8b/0xb3 lib/dumpstack.c:106 printaddressdescription mm/kasan/report.c:284 [inline] printreport+0x172/0x475 mm/kasan/report.c:395 kasanreport+0xbb/0x1c0 mm/kasan/report.c:495 validatenla lib/nlattr.c:386 [inline] _nlavalidateparse+0x24af/0x2750 lib/nlattr.c:600 _nlaparse+0x3e/0x50 lib/nlattr.c:697 nlaparsenesteddeprecated include/net/netlink.h:1248 [inline] _rtnlnewlink+0x50a/0x1880 net/core/rtnetlink.c:3485 rtnlnewlink+0x64/0xa0 net/core/rtnetlink.c:3594 rtnetlinkrcvmsg+0x43c/0xd70 net/core/rtnetlink.c:6091 netlinkrcvskb+0x14f/0x410 net/netlink/afnetlink.c:2540 netlinkunicastkernel net/netlink/afnetlink.c:1319 [inline] netlinkunicast+0x54e/0x800 net/netlink/afnetlink.c:1345 netlinksendmsg+0x930/0xe50 net/netlink/afnetlink.c:1921 socksendmsgnosec net/socket.c:714 [inline] socksendmsg+0x154/0x190 net/socket.c:734 syssendmsg+0x6df/0x840 net/socket.c:2482 _syssendmsg+0x110/0x1b0 net/socket.c:2536 _syssendmsg+0xf3/0x1c0 net/socket.c:2565 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x3b/0x90 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd RIP: 0033:0x7fdcf2072359 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 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:00007fdcf13e3168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007fdcf219ff80 RCX: 00007fdcf2072359 RDX: 0000000000000000 RSI: 0000000020000200 RDI: 0000000000000003 RBP: 00007fdcf20bd493 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fffbb8d7bdf R14: 00007fdcf13e3300 R15: 0000000000022000 </TASK>

The buggy address belongs to the variable: rmnet_policy+0x30/0xe0

The buggy address belongs to the physical page: page:0000000065bdeb3c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x155243 flags: 0x200000000001000(reserved|node=0|zone=2) raw: 0200000000001000 ffffea00055490c8 ffffea00055490c8 0000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffffffff92c43780: f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9 00 00 00 07 ffffffff92c43800: f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 06 f9 f9 f9 >ffffffff92c43880: f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 ^ ffffffff92c43900: 00 00 00 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9 f9 ffffffff92c43980: 00 00 00 07 f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9

According to the comment of nla_parse_nested_deprecated, the maxtype should be len(destination array) - 1. Hence use IFLA_RMNET_MAX here.(CVE-2024-26597)

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

phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP

If the external phy working together with phy-omap-usb2 does not implement send_srp(), we may still attempt to call it. This can happen on an idle Ethernet gadget triggering a wakeup for example:

configfs-gadget.g1 gadget.0: ECM Suspend configfs-gadget.g1 gadget.0: Port suspended. Triggering wakeup ... Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute ... PC is at 0x0 LR is at musbgadgetwakeup+0x1d4/0x254 [musbhdrc] ... musbgadgetwakeup [musbhdrc] from usbgadgetwakeup+0x1c/0x3c [udccore] usbgadgetwakeup [udccore] from ethstartxmit+0x3b0/0x3d4 [uether] ethstartxmit [uether] from devhardstartxmit+0x94/0x24c devhardstartxmit from schdirectxmit+0x104/0x2e4 schdirectxmit from _devqueuexmit+0x334/0xd88 _devqueuexmit from arpsolicit+0xf0/0x268 arpsolicit from neighprobe+0x54/0x7c neighprobe from _neigheventsend+0x22c/0x47c _neigheventsend from neighresolveoutput+0x14c/0x1c0 neighresolveoutput from ipfinishoutput2+0x1c8/0x628 ipfinishoutput2 from ipsendskb+0x40/0xd8 ipsendskb from udpsendskb+0x124/0x340 udpsendskb from udpsendmsg+0x780/0x984 udpsendmsg from _syssendto+0xd8/0x158 _syssendto from retfastsyscall+0x0/0x58

Let's fix the issue by checking for sendsrp() and setvbus() before calling them. For USB peripheral only cases these both could be NULL.(CVE-2024-26600)

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

x86/fpu: Stop relying on userspace for info to fault in xsave buffer

Before this change, the expected size of the user space buffer was taken from fxsw->xstatesize. fxsw->xstatesize can be changed from user-space, so it is possible construct a sigreturn frame where:

• fxsw->xstatesize is smaller than the size required by valid bits in fx_sw->xfeatures.
• user-space unmaps parts of the sigrame fpu buffer so that not all of the buffer required by xrstor is accessible.

In this case, xrstor tries to restore and accesses the unmapped area which results in a fault. But faultinreadable succeeds because buf + fxsw->xstatesize is within the still mapped area, so it goes back and tries xrstor again. It will spin in this loop forever.

Instead, fault in the maximum size which can be touched by XRSTOR (taken from fpstate->user_size).

dhansen: tweak subject / changelog

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

binder: signal epoll threads of self-work

In (e)poll mode, threads often depend on I/O events to determine when data is ready for consumption. Within binder, a thread may initiate a command via BINDERWRITEREAD without a read buffer and then make use of epoll_wait() or similar to consume any responses afterwards.

It is then crucial that epoll threads are signaled via wakeup when they queue their own work. Otherwise, they risk waiting indefinitely for an event leaving their work unhandled. What is worse, subsequent commands won't trigger a wakeup either as the thread has pending work.(CVE-2024-26606)