OESA-2024-2293

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

octeontx2-af: Use separate handlers for interrupts

For PF to AF interrupt vector and VF to AF vector same interrupt handler is registered which is causing race condition. When two interrupts are raised to two CPUs at same time then two cores serve same event corrupting the data.(CVE-2024-27030)

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

media: go7007: fix a memleak in go7007loadencoder

In go7007loadencoder, bounce(i.e. go->boot_fw), is allocated without a deallocation thereafter. After the following call chain:

saa7134go7007init |-> go7007bootencoder |-> go7007loadencoder |-> kfree(go)

go is freed and thus bounce is leaked.(CVE-2024-27074)

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

netfilter: nf_tables: use timestamp to check for set element timeout

Add a timestamp field at the beginning of the transaction, store it in the nftables per-netns area.

Update set backend .insert, .deactivate and sync gc path to use the timestamp, this avoids that an element expires while control plane transaction is still unfinished.

.lookup and .update, which are used from packet path, still use the current time to check if the element has expired. And .get path and dump also since this runs lockless under rcu read size lock. Then, there is async gc which also needs to check the current time since it runs asynchronously from a workqueue.(CVE-2024-27397)

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

tee: optee: Fix kernel panic caused by incorrect error handling

The error path while failing to register devices on the TEE bus has a bug leading to kernel panic as follows:

[ 15.398930] Unable to handle kernel paging request at virtual address ffff07ed00626d7c [ 15.406913] Mem abort info: [ 15.409722] ESR = 0x0000000096000005 [ 15.413490] EC = 0x25: DABT (current EL), IL = 32 bits [ 15.418814] SET = 0, FnV = 0 [ 15.421878] EA = 0, S1PTW = 0 [ 15.425031] FSC = 0x05: level 1 translation fault [ 15.429922] Data abort info: [ 15.432813] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 15.438310] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 15.443372] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 15.448697] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000d9e3e000 [ 15.455413] [ffff07ed00626d7c] pgd=1800000bffdf9003, p4d=1800000bffdf9003, pud=0000000000000000 [ 15.464146] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP

Commit 7269cba53d90 ("tee: optee: Fix supplicant based device enumeration") lead to the introduction of this bug. So fix it appropriately.(CVE-2024-35785)

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

drm/lima: fix a memleak in limaheapalloc

When limavmmap_bo fails, the resources need to be deallocated, or there will be memleaks.(CVE-2024-35829)

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

net/sched: taprio: extend minimum interval restriction to entire cycle too

It is possible for syzbot to side-step the restriction imposed by the blamed commit in the Fixes: tag, because the taprio UAPI permits a cycle-time different from (and potentially shorter than) the sum of entry intervals.

We need one more restriction, which is that the cycle time itself must be larger than N * ETHZLEN bit times, where N is the number of schedule entries. This restriction needs to apply regardless of whether the cycle time came from the user or was the implicit, auto-calculated value, so we move the existing "cycle == 0" check outside the "if "(!new->cycletime)" branch. This way covers both conditions and scenarios.

Add a selftest which illustrates the issue triggered by syzbot.(CVE-2024-36244)

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

ipv4: Fix uninit-value access in _ipmake_skb()

KMSAN reported uninit-value access in _ipmakeskb() [1]. _ipmakeskb() tests HDRINCL to know if the skb has icmphdr. However, HDRINCL can cause a race condition. If calling setsockopt(2) with IPHDRINCL changes HDRINCL while _ipmakeskb() is running, the function will access icmphdr in the skb even if it is not included. This causes the issue reported by KMSAN.

Check FLOWIFLAGKNOWNNH on fl4->flowi4flags instead of testing HDRINCL on the socket.

Also, fl4->fl4icmptype and fl4->fl4icmpcode are not initialized. These are union in struct flowi4 and are implicitly initialized by flowi4initoutput(), but we should not rely on specific union layout.

Initialize these explicitly in raw_sendmsg().

[1] BUG: KMSAN: uninit-value in _ipmakeskb+0x2b74/0x2d20 net/ipv4/ipoutput.c:1481 _ipmakeskb+0x2b74/0x2d20 net/ipv4/ipoutput.c:1481 ipfinishskb include/net/ip.h:243 [inline] ippushpendingframes+0x4c/0x5c0 net/ipv4/ipoutput.c:1508 rawsendmsg+0x2381/0x2690 net/ipv4/raw.c:654 inetsendmsg+0x27b/0x2a0 net/ipv4/afinet.c:851 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg+0x274/0x3c0 net/socket.c:745 _syssendto+0x62c/0x7b0 net/socket.c:2191 _dosyssendto net/socket.c:2203 [inline] _sesyssendto net/socket.c:2199 [inline] _x64syssendto+0x130/0x200 net/socket.c:2199 dosyscall64+0xd8/0x1f0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x6d/0x75

Uninit was created at: slabpostallochook mm/slub.c:3804 [inline] slaballocnode mm/slub.c:3845 [inline] kmemcacheallocnode+0x5f6/0xc50 mm/slub.c:3888 kmallocreserve+0x13c/0x4a0 net/core/skbuff.c:577 _allocskb+0x35a/0x7c0 net/core/skbuff.c:668 allocskb include/linux/skbuff.h:1318 [inline] _ipappenddata+0x49ab/0x68c0 net/ipv4/ipoutput.c:1128 ipappenddata+0x1e7/0x260 net/ipv4/ipoutput.c:1365 rawsendmsg+0x22b1/0x2690 net/ipv4/raw.c:648 inetsendmsg+0x27b/0x2a0 net/ipv4/afinet.c:851 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg+0x274/0x3c0 net/socket.c:745 _syssendto+0x62c/0x7b0 net/socket.c:2191 _dosyssendto net/socket.c:2203 [inline] _sesyssendto net/socket.c:2199 [inline] _x64syssendto+0x130/0x200 net/socket.c:2199 dosyscall64+0xd8/0x1f0 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x6d/0x75

CPU: 1 PID: 15709 Comm: syz-executor.7 Not tainted 6.8.0-11567-gb3603fcb79b1 #25 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014(CVE-2024-36927)

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

net/mlx5e: Fix netif state handling

mlx5esuspend cleans resources only if netifdevicepresent() returns true. However, mlx5eresume changes the state of netif, via mlx5enicenable, only if regstate == NETREGREGISTERED. In the below case, the above leads to NULL-ptr Oops[1] and memory leaks:

mlx5eprobe _mlx5eresume mlx5eattachnetdev mlx5enicenable <-- netdev not reg, not calling netifdeviceattach() registernetdev <-- failed for some reason. ERRORFLOW: mlx5esuspend <-- netifdevicepresent return false, resources aren't freed :(

Hence, clean resources in this case as well.

[1] BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0010 [#1] SMP CPU: 2 PID: 9345 Comm: test-ovs-ct-gen Not tainted 6.5.0forupstreammindebug202309051601 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:0x0 Code: Unable to access opcode bytes at0xffffffffffffffd6. RSP: 0018:ffff888178aaf758 EFLAGS: 00010246 Call Trace: <TASK> ? _die+0x20/0x60 ? pagefaultoops+0x14c/0x3c0 ? excpagefault+0x75/0x140 ? asmexcpagefault+0x22/0x30 notifiercallchain+0x35/0xb0 blockingnotifiercallchain+0x3d/0x60 mlx5blockingnotifiercallchain+0x22/0x30 [mlx5core] mlx5coreuplinknetdeveventreplay+0x3e/0x60 [mlx5core] mlx5mdevnetdevtrack+0x53/0x60 [mlx5ib] mlx5ibroceinit+0xc3/0x340 [mlx5ib] _mlx5ibadd+0x34/0xd0 [mlx5ib] mlx5rprobe+0xe1/0x210 [mlx5ib] ? auxiliarymatchid+0x6a/0x90 auxiliarybusprobe+0x38/0x80 ? driversysfsadd+0x51/0x80 reallyprobe+0xc9/0x3e0 ? driverprobedevice+0x90/0x90 _driverprobedevice+0x80/0x160 driverprobedevice+0x1e/0x90 _deviceattachdriver+0x7d/0x100 busforeachdrv+0x80/0xd0 _deviceattach+0xbc/0x1f0 busprobedevice+0x86/0xa0 deviceadd+0x637/0x840 _auxiliarydeviceadd+0x3b/0xa0 addadev+0xc9/0x140 [mlx5core] mlx5rescandriverslocked+0x22a/0x310 [mlx5core] mlx5registerdevice+0x53/0xa0 [mlx5core] mlx5initonedevllocked+0x5c4/0x9c0 [mlx5core] mlx5initone+0x3b/0x60 [mlx5core] probeone+0x44c/0x730 [mlx5core] localpciprobe+0x3e/0x90 pcideviceprobe+0xbf/0x210 ? kernfscreatelink+0x5d/0xa0 ? sysfsdocreatelinksd+0x60/0xc0 reallyprobe+0xc9/0x3e0 ? driverprobedevice+0x90/0x90 _driverprobedevice+0x80/0x160 driverprobedevice+0x1e/0x90 _deviceattachdriver+0x7d/0x100 busforeachdrv+0x80/0xd0 _deviceattach+0xbc/0x1f0 pcibusadddevice+0x54/0x80 pciiovaddvirtfn+0x2e6/0x320 sriovenable+0x208/0x420 mlx5coresriovconfigure+0x9e/0x200 [mlx5core] sriovnumvfsstore+0xae/0x1a0 kernfsfopwriteiter+0x10c/0x1a0 vfswrite+0x291/0x3c0 ksyswrite+0x5f/0xe0 dosyscall64+0x3d/0x90 entrySYSCALL64afterhwframe+0x46/0xb0 CR2: 0000000000000000 ---[ end trace 0000000000000000 ]---(CVE-2024-38608)

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

ipv6: sr: fix invalid unregister error path

The error path of seg6init() is wrong in case CONFIGIPV6SEG6LWTUNNEL is not defined. In that case if seg6hmacinit() fails, the genlunregisterfamily() isn't called.

This issue exist since commit 46738b1317e1 ("ipv6: sr: add option to control lwtunnel support"), and commit 5559cea2d5aa ("ipv6: sr: fix possible use-after-free and null-ptr-deref") replaced unregisterpernetsubsys() with genlunregisterfamily() in this error path.(CVE-2024-38612)

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

greybus: Fix use-after-free bug in gbinterfacerelease due to race condition.

In gbinterfacecreate, &intf->modeswitchcompletion is bound with gbinterfacemodeswitchwork. Then it will be started by gbinterfacerequestmodeswitch. Here is the relevant code. if (!queuework(systemlongwq, &intf->modeswitch_work)) { ... }

If we call gbinterfacerelease to make cleanup, there may be an unfinished work. This function will call kfree to free the object "intf". However, if gbinterfacemodeswitchwork is scheduled to run after kfree, it may cause use-after-free error as gbinterfacemodeswitchwork will use the object "intf". The possible execution flow that may lead to the issue is as follows:

CPU0 CPU1

                        |   gb_interface_create
                        |   gb_interface_request_mode_switch

gbinterfacerelease | kfree(intf) (free) | | gbinterfacemodeswitchwork | mutex_lock(&intf->mutex) (use)

Fix it by canceling the work before kfree.(CVE-2024-39495)

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

netns: Make getnetns() handle zero refcount net

Syzkaller hit a warning: refcountt: addition on 0; use-after-free. WARNING: CPU: 3 PID: 7890 at lib/refcount.c:25 refcountwarnsaturate+0xdf/0x1d0 Modules linked in: CPU: 3 PID: 7890 Comm: tun Not tainted 6.10.0-rc3-00100-gcaa4f9578aba-dirty #310 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:refcountwarnsaturate+0xdf/0x1d0 Code: 41 49 04 31 ff 89 de e8 9f 1e cd fe 84 db 75 9c e8 76 26 cd fe c6 05 b6 41 49 04 01 90 48 c7 c7 b8 8e 25 86 e8 d2 05 b5 fe 90 <0f> 0b 90 90 e9 79 ff ff ff e8 53 26 cd fe 0f b6 1 RSP: 0018:ffff8881067b7da0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c72ac RDX: ffff8881026a2140 RSI: ffffffff811c72b5 RDI: 0000000000000001 RBP: ffff8881067b7db0 R08: 0000000000000000 R09: 205b5d3730353139 R10: 0000000000000000 R11: 205d303938375420 R12: ffff8881086500c4 R13: ffff8881086500c4 R14: ffff8881086500b0 R15: ffff888108650040 FS: 00007f5b2961a4c0(0000) GS:ffff88823bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d7ed36fd18 CR3: 00000001482f6000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? showregs+0xa3/0xc0 ? _warn+0xa5/0x1c0 ? refcountwarnsaturate+0xdf/0x1d0 ? reportbug+0x1fc/0x2d0 ? refcountwarnsaturate+0xdf/0x1d0 ? handlebug+0xa1/0x110 ? excinvalidop+0x3c/0xb0 ? asmexcinvalidop+0x1f/0x30 ? _warnprintk+0xcc/0x140 ? _warnprintk+0xd5/0x140 ? refcountwarnsaturate+0xdf/0x1d0 getnetns+0xa4/0xc0 ? _pfxgetnetns+0x10/0x10 openrelatedns+0x5a/0x130 _tunchrioctl+0x1616/0x2370 ? _sanitizercovtraceswitch+0x58/0xa0 ? _sanitizercovtraceconstcmp2+0x1c/0x30 ? _pfxtunchrioctl+0x10/0x10 tunchrioctl+0x2f/0x40 _x64sysioctl+0x11b/0x160 x64syscall+0x1211/0x20d0 dosyscall64+0x9e/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f5b28f165d7 Code: b3 66 90 48 8b 05 b1 48 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 81 48 2d 00 8 RSP: 002b:00007ffc2b59c5e8 EFLAGS: 00000246 ORIGRAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5b28f165d7 RDX: 0000000000000000 RSI: 00000000000054e3 RDI: 0000000000000003 RBP: 00007ffc2b59c650 R08: 00007f5b291ed8c0 R09: 00007f5b2961a4c0 R10: 0000000029690010 R11: 0000000000000246 R12: 0000000000400730 R13: 00007ffc2b59cf40 R14: 0000000000000000 R15: 0000000000000000 </TASK> Kernel panic - not syncing: kernel: paniconwarn set ...

This is trigger as below: ns0 ns1 tunsetiff() //dev is tun0 tun->dev = dev //ip link set tun0 netns ns1 putnet() //ref is 0 _tunchrioctl() //TUNGETDEVNETNS net = devnet(tun->dev); openrelatedns(&net->ns, getnetns); //ns1 getnetns() getnet() //addition on 0

Use maybegetnet() in getnetns in case net's ref is zero to fix this(CVE-2024-40958)

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

scsi: qla2xxx: During vport delete send async logout explicitly

During vport delete, it is observed that during unload we hit a crash because of stale entries in outstanding command array. For all these stale I/O entries, ehabort was issued and aborted (fastfail_io = 2009h) but I/Os could not complete while vport delete is in process of deleting.

BUG: kernel NULL pointer dereference, address: 000000000000001c #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI Workqueue: qla2xxxwq qladowork [qla2xxx] RIP: 0010:dmadirectunmapsg+0x51/0x1e0 RSP: 0018:ffffa1e1e150fc68 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000001 RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8ce208a7a0d0 RBP: ffff8ce208a7a0d0 R08: 0000000000000000 R09: ffff8ce378aac9c8 R10: ffff8ce378aac8a0 R11: ffffa1e1e150f9d8 R12: 0000000000000000 R13: 0000000000000000 R14: ffff8ce378aac9c8 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8d217f000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000001c CR3: 0000002089acc000 CR4: 0000000000350ee0 Call Trace: <TASK> qla2xxxqpairspfreedma+0x417/0x4e0 ? qla2xxxqpairspcompl+0x10d/0x1a0 ? qla2x00statusentry+0x768/0x2830 ? newidlebalance+0x2f0/0x430 ? dequeueentity+0x100/0x3c0 ? qla24xxprocessresponsequeue+0x6a1/0x19e0 ? _schedule+0x2d5/0x1140 ? qladowork+0x47/0x60 ? processonework+0x267/0x440 ? processonework+0x440/0x440 ? workerthread+0x2d/0x3d0 ? processonework+0x440/0x440 ? kthread+0x156/0x180 ? setkthreadstruct+0x50/0x50 ? retfrom_fork+0x22/0x30 </TASK>

Send out async logout explicitly for all the ports during vport delete.(CVE-2024-42289)

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

net: flowdissector: use DEBUGNETWARNON_ONCE

The following splat is easy to reproduce upstream as well as in -stable kernels. Florian Westphal provided the following commit:

d1dab4f71d37 ("net: add and use _skbgethashsymmetric_net")

but this complementary fix has been also suggested by Willem de Bruijn and it can be easily backported to -stable kernel which consists in using DEBUGNETWARNONONCE instead to silence the following splat given _skbget_hash() is used by the nftables tracing infrastructure to to identify packets in traces.

[69133.561393] ------------[ cut here ]------------ [69133.561404] WARNING: CPU: 0 PID: 43576 at net/core/flowdissector.c:1104 skbflowdissect+0x134f/ [...] [69133.561944] CPU: 0 PID: 43576 Comm: socat Not tainted 6.10.0-rc7+ #379 [69133.561959] RIP: 0010:skbflowdissect+0x134f/0x2ad0 [69133.561970] Code: 83 f9 04 0f 84 b3 00 00 00 45 85 c9 0f 84 aa 00 00 00 41 83 f9 02 0f 84 81 fc ff ff 44 0f b7 b4 24 80 00 00 00 e9 8b f9 ff ff <0f> 0b e9 20 f3 ff ff 41 f6 c6 20 0f 84 e4 ef ff ff 48 8d 7b 12 e8 [69133.561979] RSP: 0018:ffffc90000006fc0 EFLAGS: 00010246 [69133.561988] RAX: 0000000000000000 RBX: ffffffff82f33e20 RCX: ffffffff81ab7e19 [69133.561994] RDX: dffffc0000000000 RSI: ffffc90000007388 RDI: ffff888103a1b418 [69133.562001] RBP: ffffc90000007310 R08: 0000000000000000 R09: 0000000000000000 [69133.562007] R10: ffffc90000007388 R11: ffffffff810cface R12: ffff888103a1b400 [69133.562013] R13: 0000000000000000 R14: ffffffff82f33e2a R15: ffffffff82f33e28 [69133.562020] FS: 00007f40f7131740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000 [69133.562027] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [69133.562033] CR2: 00007f40f7346ee0 CR3: 000000015d200001 CR4: 00000000001706f0 [69133.562040] Call Trace: [69133.562044] <IRQ> [69133.562049] ? _warn+0x9f/0x1a0 [ 1211.841384] ? _skbflowdissect+0x107e/0x2860 [...] [ 1211.841496] ? bpfflowdissect+0x160/0x160 [ 1211.841753] _skbgethash+0x97/0x280 [ 1211.841765] ? _skbgethashsymmetric+0x230/0x230 [ 1211.841776] ? modfind+0xbf/0xe0 [ 1211.841786] ? getstackinfonoinstr+0x12/0xe0 [ 1211.841798] ? bpfksymfind+0x56/0xe0 [ 1211.841807] ? _rcureadunlock+0x2a/0x70 [ 1211.841819] nfttraceinit+0x1b9/0x1c0 [nftables] [ 1211.841895] ? nfttracenotify+0x830/0x830 [nftables] [ 1211.841964] ? getstackinfo+0x2b/0x80 [ 1211.841975] ? nftdochainarp+0x80/0x80 [nftables] [ 1211.842044] nftdochain+0x79c/0x850 nftables

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

mlxsw: spectrumaclerp: Fix object nesting warning

ACLs in Spectrum-2 and newer ASICs can reside in the algorithmic TCAM (A-TCAM) or in the ordinary circuit TCAM (C-TCAM). The former can contain more ACLs (i.e., tc filters), but the number of masks in each region (i.e., tc chain) is limited.

In order to mitigate the effects of the above limitation, the device allows filters to share a single mask if their masks only differ in up to 8 consecutive bits. For example, dstip/25 can be represented using dstip/24 with a delta of 1 bit. The C-TCAM does not have a limit on the number of masks being used (and therefore does not support mask aggregation), but can contain a limited number of filters.

The driver uses the "objagg" library to perform the mask aggregation by passing it objects that consist of the filter's mask and whether the filter is to be inserted into the A-TCAM or the C-TCAM since filters in different TCAMs cannot share a mask.

The set of created objects is dependent on the insertion order of the filters and is not necessarily optimal. Therefore, the driver will periodically ask the library to compute a more optimal set ("hints") by looking at all the existing objects.

When the library asks the driver whether two objects can be aggregated the driver only compares the provided masks and ignores the A-TCAM / C-TCAM indication. This is the right thing to do since the goal is to move as many filters as possible to the A-TCAM. The driver also forbids two identical masks from being aggregated since this can only happen if one was intentionally put in the C-TCAM to avoid a conflict in the A-TCAM.

The above can result in the following set of hints:

H1: {mask X, A-TCAM} -> H2: {mask Y, A-TCAM} // X is Y + delta H3: {mask Y, C-TCAM} -> H4: {mask Z, A-TCAM} // Y is Z + delta

After getting the hints from the library the driver will start migrating filters from one region to another while consulting the computed hints and instructing the device to perform a lookup in both regions during the transition.

Assuming a filter with mask X is being migrated into the A-TCAM in the new region, the hints lookup will return H1. Since H2 is the parent of H1, the library will try to find the object associated with it and create it if necessary in which case another hints lookup (recursive) will be performed. This hints lookup for {mask Y, A-TCAM} will either return H2 or H3 since the driver passes the library an object comparison function that ignores the A-TCAM / C-TCAM indication.

This can eventually lead to nested objects which are not supported by the library [1].

Fix by removing the object comparison function from both the driver and the library as the driver was the only user. That way the lookup will only return exact matches.

I do not have a reliable reproducer that can reproduce the issue in a timely manner, but before the fix the issue would reproduce in several minutes and with the fix it does not reproduce in over an hour.

Note that the current usefulness of the hints is limited because they include the C-TCAM indication and represent aggregation that cannot actually happen. This will be addressed in net-next.

[1] WARNING: CPU: 0 PID: 153 at lib/objagg.c:170 objaggobjparentassign+0xb5/0xd0 Modules linked in: CPU: 0 PID: 153 Comm: kworker/0:18 Not tainted 6.9.0-rc6-custom-g70fbc2c1c38b #42 Hardware name: Mellanox Technologies Ltd. MSN3700C/VMOD0008, BIOS 5.11 10/10/2018 Workqueue: mlxswcore mlxswspacltcamvregionrehashwork RIP: 0010:objaggobjparentassign+0xb5/0xd0 [...] Call Trace: <TASK> _objaggobjget+0x2bb/0x580 objaggobjget+0xe/0x80 mlxswspaclerpmaskget+0xb5/0xf0 mlxswspaclatcamentryadd+0xe8/0x3c0 mlxswspacltcamentrycreate+0x5e/0xa0 mlxswspacltcamvchunkmigrateone+0x16b/0x270 mlxswspacltcamvregionrehashwork+0xbe/0x510 processone_work+0x151/0x370(CVE-2024-43880)

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

gpio: prevent potential speculation leaks in gpiodeviceget_desc()

Userspace may trigger a speculative read of an address outside the gpio descriptor array. Users can do that by calling gpioioctl() with an offset out of range. Offset is copied from user and then used as an array index to get the gpio descriptor without sanitization in gpiodevicegetdesc().

This change ensures that the offset is sanitized by using arrayindexnospec() to mitigate any possibility of speculative information leaks.

This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc.(CVE-2024-44931)

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

driver core: Fix uevent_show() vs driver detach race

ueventshow() wants to de-reference dev->driver->name. There is no clean way for a device attribute to de-reference dev->driver unless that attribute is defined via (struct devicedriver).devgroups. Instead, the anti-pattern of taking the devicelock() in the attribute handler risks deadlocks with code paths that remove device attributes while holding the lock.

This deadlock is typically invisible to lockdep given the devicelock() is marked lockdepsetnovalidateclass(), but some subsystems allocate a local lockdep key for @dev->mutex to reveal reports of the form:

====================================================== WARNING: possible circular locking dependency detected 6.10.0-rc7+ #275 Tainted: G OE N

modprobe/2374 is trying to acquire lock: ffff8c2270070de0 (kn->active#6){++++}-{0:0}, at: _kernfsremove+0xde/0x220

but task is already holding lock: ffff8c22016e88f8 (&cxlrootkey){+.+.}-{3:3}, at: devicereleasedriver_internal+0x39/0x210

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (&cxlrootkey){+.+.}-{3:3}: _mutexlock+0x99/0xc30 ueventshow+0xac/0x130 devattrshow+0x18/0x40 sysfskfseqshow+0xac/0xf0 seqreaditer+0x110/0x450 vfsread+0x25b/0x340 ksysread+0x67/0xf0 dosyscall64+0x75/0x190 entrySYSCALL64afterhwframe+0x76/0x7e

-> #0 (kn->active#6){++++}-{0:0}: _lockacquire+0x121a/0x1fa0 lockacquire+0xd6/0x2e0 kernfsdrain+0x1e9/0x200 _kernfsremove+0xde/0x220 kernfsremovebynamens+0x5e/0xa0 devicedel+0x168/0x410 deviceunregister+0x13/0x60 devresreleaseall+0xb8/0x110 deviceunbindcleanup+0xe/0x70 devicereleasedriverinternal+0x1c7/0x210 driverdetach+0x47/0x90 busremovedriver+0x6c/0xf0 cxlacpiexit+0xc/0x11 [cxlacpi] _dosysdeletemodule.isra.0+0x181/0x260 dosyscall64+0x75/0x190 entrySYSCALL64after_hwframe+0x76/0x7e

The observation though is that driver objects are typically much longer lived than device objects. It is reasonable to perform lockless de-reference of a @driver pointer even if it is racing detach from a device. Given the infrequency of driver unregistration, use synchronizercu() in moduleremovedriver() to close any potential races. It is potentially overkill to suffer synchronizercu() just to handle the rare module removal racing uevent_show() event.

Thanks to Tetsuo Handa for the debug analysis of the syzbot report [1].(CVE-2024-44952)

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

bonding: fix xfrm real_dev null pointer dereference

We shouldn't set realdev to NULL because packets can be in transit and xfrm might call xdodevoffloadok() in parallel. All callbacks assume real_dev is set.

Example trace: kernel: BUG: unable to handle page fault for address: 0000000000001030 kernel: bond0: (slave eni0np1): making interface the new active one kernel: #PF: supervisor write access in kernel mode kernel: #PF: errorcode(0x0002) - not-present page kernel: PGD 0 P4D 0 kernel: Oops: 0002 [#1] PREEMPT SMP kernel: CPU: 4 PID: 2237 Comm: ping Not tainted 6.7.7+ #12 kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 kernel: RIP: 0010:nsimipsecoffloadok+0xc/0x20 [netdevsim] kernel: bond0: (slave eni0np1): bondipsecaddsaall: failed to add SA kernel: Code: e0 0f 0b 48 83 7f 38 00 74 de 0f 0b 48 8b 47 08 48 8b 37 48 8b 78 40 e9 b2 e5 9a d7 66 90 0f 1f 44 00 00 48 8b 86 80 02 00 00 <83> 80 30 10 00 00 01 b8 01 00 00 00 c3 0f 1f 80 00 00 00 00 0f 1f kernel: bond0: (slave eni0np1): making interface the new active one kernel: RSP: 0018:ffffabde81553b98 EFLAGS: 00010246 kernel: bond0: (slave eni0np1): bondipsecaddsaall: failed to add SA kernel: kernel: RAX: 0000000000000000 RBX: ffff9eb404e74900 RCX: ffff9eb403d97c60 kernel: RDX: ffffffffc090de10 RSI: ffff9eb404e74900 RDI: ffff9eb3c5de9e00 kernel: RBP: ffff9eb3c0a42000 R08: 0000000000000010 R09: 0000000000000014 kernel: R10: 7974203030303030 R11: 3030303030303030 R12: 0000000000000000 kernel: R13: ffff9eb3c5de9e00 R14: ffffabde81553cc8 R15: ffff9eb404c53000 kernel: FS: 00007f2a77a3ad00(0000) GS:ffff9eb43bd00000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 0000000000001030 CR3: 00000001122ab000 CR4: 0000000000350ef0 kernel: bond0: (slave eni0np1): making interface the new active one kernel: Call Trace: kernel: <TASK> kernel: ? _die+0x1f/0x60 kernel: bond0: (slave eni0np1): bondipsecaddsaall: failed to add SA kernel: ? pagefaultoops+0x142/0x4c0 kernel: ? douseraddrfault+0x65/0x670 kernel: ? kvmreadandresetapfflags+0x3b/0x50 kernel: bond0: (slave eni0np1): making interface the new active one kernel: ? excpagefault+0x7b/0x180 kernel: ? asmexcpagefault+0x22/0x30 kernel: ? nsimbpfuninit+0x50/0x50 [netdevsim] kernel: bond0: (slave eni0np1): bondipsecaddsaall: failed to add SA kernel: ? nsimipsecoffloadok+0xc/0x20 [netdevsim] kernel: bond0: (slave eni0np1): making interface the new active one kernel: bondipsecoffloadok+0x7b/0x90 [bonding] kernel: xfrmoutput+0x61/0x3b0 kernel: bond0: (slave eni0np1): bondipsecaddsaall: failed to add SA kernel: ippushpendingframes+0x56/0x80(CVE-2024-44989)

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

bonding: fix null pointer deref in bondipsecoffload_ok

We must check if there is an active slave before dereferencing the pointer.(CVE-2024-44990)

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

dmaengine: altera-msgdma: properly free descriptor in msgdmafreedescriptor

Remove listdel call in msgdmachandesccleanup, this should be the role of msgdmafreedescriptor. In consequence replace listaddtail with listmovetail in msgdmafreedescriptor.

This fixes the path: msgdmafreechanresources -> msgdmafreedescriptors -> msgdmafreedesclist -> msgdmafreedescriptor

which does not correctly free the descriptors as first nodes were not removed from the list.(CVE-2024-46716)

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

drm/amd/display: Stop amdgpu_dm initialize when stream nums greater than 6

[Why] Coverity reports OVERRUN warning. Should abort amdgpu_dm initialize.

[How] Return failure to amdgpudminit.(CVE-2024-46817)

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

arm64: acpi: Harden getcpuforacpiid() against missing CPU entry

In a review discussion of the changes to support vCPU hotplug where a check was added on the GICC being enabled if was online, it was noted that there is need to map back to the cpu and use that to index into a cpumask. As such, a valid ID is needed.

If an MPIDR check fails in acpimapgiccpuinterface() it is possible for the entry in cpumadtgicc[cpu] == NULL. This function would then cause a NULL pointer dereference. Whilst a path to trigger this has not been established, harden this caller against the possibility.(CVE-2024-46822)

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

platform/x86: panasonic-laptop: Fix SINF array out of bounds accesses

The panasonic laptop code in various places uses the SINF array with index values of 0 - SINFCURBRIGHT(0x0d) without checking that the SINF array is big enough.

Not all panasonic laptops have this many SINF array entries, for example the Toughbook CF-18 model only has 10 SINF array entries. So it only supports the AC+DC brightness entries and mute.

Check that the SINF array has a minimum size which covers all AC+DC brightness entries and refuse to load if the SINF array is smaller.

For higher SINF indexes hide the sysfs attributes when the SINF array does not contain an entry for that attribute, avoiding show()/store() accessing the array out of bounds and add bounds checking to the probe() and resume() code accessing these.(CVE-2024-46859)

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

drm/amd/display: Avoid overflow from uint32t to uint8t

[WHAT & HOW] dmubrbcmd's rampingboundary has size of uint8t and it is assigned 0xFFFF. Fix it by changing it to uint8_t with value of 0xFF.

This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.(CVE-2024-47661)