Where
AND
-Infinity
0
Severity
5.5
Null Pointer Dereference
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

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

netsched: Flush gsoskb list too during ->change()

Previously, when reducing a qdisc's limit via the ->change() operation, only the main skb queue was trimmed, potentially leaving packets in the gsoskb list. This could result in NULL pointer dereference when we only check sch->limit against sch->q.qlen.

This patch introduces a new helper, qdiscdequeueinternal(), which ensures both the gsoskb list and the main queue are properly flushed when trimming excess packets. All relevant qdiscs (codel, fq, fqcodel, fqpie, hhf, pie) are updated to use this helper in their ->change() routines.

1 / 2
Source: MITRE
First published (updated )
Severity
4.7
Race Condition
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H

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

USB: wdm: close race between wdmopen and wdmwwanportstop

Clearing WDMWWANINUSE must be the last action or we can open a chardev whose URBs are still poisoned

1 / 2
Source: MITRE
First published (updated )
Severity
5.5
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

block: fix resource leak in blkregisterqueue() error path

1 / 2
Source: Microsoft
First published (updated )
Severity
5.5
Null Pointer Dereference
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

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

Input: mtk-pmic-keys - fix possible null pointer dereference

In mtkpmickeysprobe, the regs parameter is only set if the button is parsed in the device tree. However, on hardware where the button is left floating, that node will most likely be removed not to enable that input. In that case the code will try to dereference a null pointer.

Let's use the regs struct instead as it is defined for all supported platforms. Note that it is ok setting the key reg even if that latter is disabled as the interrupt won't be enabled anyway.

1 / 2
Source: MITRE
First published (updated )
Severity
6.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

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

ipvs: fix uninit-value for saddr in dooutputroute4

syzbot reports for uninit-value for the saddr argument [1]. commit 4754957f04f5 ("ipvs: do not use random local source address for tunnels") already implies that the input value of saddr should be ignored but the code is still reading it which can prevent to connect the route. Fix it by changing the argument to retsaddr.

[1] BUG: KMSAN: uninit-value in dooutputroute4+0x42c/0x4d0 net/netfilter/ipvs/ipvsxmit.c:147 dooutputroute4+0x42c/0x4d0 net/netfilter/ipvs/ipvsxmit.c:147 ipvsgetoutrt+0x403/0x21d0 net/netfilter/ipvs/ipvsxmit.c:330 ipvstunnelxmit+0x205/0x2380 net/netfilter/ipvs/ipvsxmit.c:1136 ipvsinhook+0x1aa5/0x35b0 net/netfilter/ipvs/ipvscore.c:2063 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xf7/0x400 net/netfilter/core.c:626 nfhook include/linux/netfilter.h:269 [inline] iplocalout+0x758/0x7e0 net/ipv4/ipoutput.c:118 iplocalout net/ipv4/ipoutput.c:127 [inline] ipsendskb+0x6a/0x3c0 net/ipv4/ipoutput.c:1501 udpsendskb+0xfda/0x1b70 net/ipv4/udp.c:1195 udpsendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inetsendmsg+0x1fc/0x280 net/ipv4/afinet.c:851 socksendmsgnosec net/socket.c:712 [inline] socksendmsg+0x267/0x380 net/socket.c:727 syssendmsg+0x91b/0xda0 net/socket.c:2566 syssendmsg+0x28d/0x3c0 net/socket.c:2620 syssendmmsg+0x41d/0x880 net/socket.c:2702 compatsyssendmmsg net/compat.c:360 [inline] docompatsyssendmmsg net/compat.c:367 [inline] secompatsyssendmmsg net/compat.c:364 [inline] ia32compatsyssendmmsg+0xc8/0x140 net/compat.c:364 ia32syscall+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls32.h:346 dosyscall32irqson arch/x86/entry/syscall32.c:83 [inline] dofastsyscall32+0xb0/0x110 arch/x86/entry/syscall32.c:306 dofastsyscall32+0x38/0x80 arch/x86/entry/syscall32.c:331 doSYSENTER32+0x1f/0x30 arch/x86/entry/syscall32.c:369 entrySYSENTERcompatafterhwframe+0x84/0x8e

Uninit was created at: slabpostallochook mm/slub.c:4167 [inline] slaballocnode mm/slub.c:4210 [inline] kmalloccachenoprof+0x8fa/0xe00 mm/slub.c:4367 kmallocnoprof include/linux/slab.h:905 [inline] ipvsdestdstalloc net/netfilter/ipvs/ipvsxmit.c:61 [inline] ipvsgetoutrt+0x35d/0x21d0 net/netfilter/ipvs/ipvsxmit.c:323 ipvstunnelxmit+0x205/0x2380 net/netfilter/ipvs/ipvsxmit.c:1136 ipvsinhook+0x1aa5/0x35b0 net/netfilter/ipvs/ipvscore.c:2063 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xf7/0x400 net/netfilter/core.c:626 nfhook include/linux/netfilter.h:269 [inline] iplocalout+0x758/0x7e0 net/ipv4/ipoutput.c:118 iplocalout net/ipv4/ipoutput.c:127 [inline] ipsendskb+0x6a/0x3c0 net/ipv4/ipoutput.c:1501 udpsendskb+0xfda/0x1b70 net/ipv4/udp.c:1195 udpsendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inetsendmsg+0x1fc/0x280 net/ipv4/afinet.c:851 socksendmsgnosec net/socket.c:712 [inline] socksendmsg+0x267/0x380 net/socket.c:727 syssendmsg+0x91b/0xda0 net/socket.c:2566 syssendmsg+0x28d/0x3c0 net/socket.c:2620 syssendmmsg+0x41d/0x880 net/socket.c:2702 compatsyssendmmsg net/compat.c:360 [inline] docompatsyssendmmsg net/compat.c:367 [inline] secompatsyssendmmsg net/compat.c:364 [inline] ia32compatsyssendmmsg+0xc8/0x140 net/compat.c:364 ia32syscall+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls32.h:346 dosyscall32irqson arch/x86/entry/syscall32.c:83 [inline] dofastsyscall32+0xb0/0x110 arch/x86/entry/syscall32.c:306 dofastsyscall32+0x38/0x80 arch/x86/entry/syscall32.c:331 doSYSENTER32+0x1f/0x30 arch/x86/entry/syscall32.c:369 entrySYSENTERcompatafterhwframe+0x84/0x8e

CPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef) Hardware name: Google Google Compute Engi ---truncated---

1 / 2
Source: MITRE
First published (updated )
Severity
5.6
Double Free
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

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

octeonep: Fix host hang issue during device reboot

When the host loses heartbeat messages from the device, the driver calls the device-specific ndostop function, which frees the resources. If the driver is unloaded in this scenario, it calls ndostop again, attempting to free resources that have already been freed, leading to a host hang issue. To resolve this, devclose should be called instead of the device-specific stop function.devclose internally calls ndostop to stop the network interface and performs additional cleanup tasks. During the driver unload process, if the device is already down, ndostop is not called.

1 / 2
Source: MITRE
First published (updated )
Severity
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

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

schhtb: make htbqlennotify() idempotent

htbqlennotify() always deactivates the HTB class and in fact could trigger a warning if it is already deactivated. Therefore, it is not idempotent and not friendly to its callers, like fqcodeldequeue().

Let's make it idempotent to ease qdisctreereducebacklog() callers' life.

1 / 2
Source: MITRE
First published (updated )
Severity
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

drm/nouveau: Fix WARNON in nouveaufencecontextkill()

1 / 2
Source: Microsoft
First published (updated )
Severity
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

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

net: lan743x: Fix memleak issue when GSO enabled

Always map the skb to the LS descriptor. Previously skb was mapped to EXT descriptor when the number of fragments is zero with GSO enabled. Mapping the skb to EXT descriptor prevents it from being freed, leading to a memory leak

1 / 2
Source: MITRE
First published (updated )
Severity
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

firmware: armscmi: Balance device refcount when destroying devices

1 / 2
Source: Microsoft
First published (updated )
Severity
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

bpf: Fix deadlock between rcutaskstrace and eventmutex.

1 / 2
Source: Microsoft
First published (updated )
Severity
5.5
Null Pointer Dereference
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

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

s390/sclp: Add check for getzeroedpage()

Add check for the return value of getzeroedpage() in sclpconsoleinit() to prevent null pointer dereference. Furthermore, to solve the memory leak caused by the loop allocation, add a free helper to do the free job.

1 / 2
Source: NVD
First published (updated )
Severity
5.5
Null Pointer Dereference
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

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

usb: gadget: aspeed: Add NULL pointer check in astvhubinitdev()

The variable d->name, returned by devmkasprintf(), could be NULL. A pointer check is added to prevent potential NULL pointer dereference. This is similar to the fix in commit 3027e7b15b02 ("ice: Fix some null pointer dereference issues in iceptp.c").

This issue is found by our static analysis tool

1 / 2
Source: MITRE
First published (updated )
Severity
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

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

perf/core: Fix WARNON(!ctx) in freeevent() for partial init

Move the getctx(childctx) call and the childevent->ctx assignment to occur immediately after the child event is allocated. Ensure that childevent->ctx is non-NULL before any subsequent error path within inheritevent calls freeevent(), satisfying the assumptions of the cleanup code.

Details:

There's no clear Fixes tag, because this bug is a side-effect of multiple interacting commits over time (up to 15 years old), not a single regression.

The code initially incremented refcount then assigned context immediately after the childevent was created. Later, an early validity check for childevent was added before the refcount/assignment. Even later, a WARNONONCE() cleanup check was added, assuming event->ctx is valid if the pmuctx is valid. The problem is that the WARNONONCE() could trigger after the initial check passed but before childevent->ctx was assigned, violating its precondition. The solution is to assign childevent->ctx right after its initial validation. This ensures the context exists for any subsequent checks or cleanup routines, resolving the WARNONONCE().

To resolve it, defer the refcount update and childevent->ctx assignment directly after childevent->pmuctx is set but before checking if the parent event is orphaned. The cleanup routine depends on event->pmuctx being non-NULL before it verifies event->ctx is non-NULL. This also maintains the author's original intent of passing in childctx to findgetpmucontext before its refcount/assignment.

[ mingo: Expanded the changelog from another email by Gabriel Shahrouzi. ]

1 / 2
Source: MITRE
First published (updated )
Severity
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

igc: fix PTM cycle trigger logic

1 / 2
Source: Microsoft
First published (updated )
Severity
5.5
Double Free
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

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

net: ngbe: fix memory leak in ngbeprobe() error path

When ngbeswinit() is called, memory is allocated for wx->rsskey in wxinitrsskey(). However, in ngbeprobe() function, the subsequent error paths after ngbeswinit() don't free the rsskey. Fix that by freeing it in error path along with wx->mactable.

Also change the label to which execution jumps when ngbeswinit() fails, because otherwise, it could lead to a double free for rsskey, when the mactable allocation fails in wxswinit().

1 / 2
Source: MITRE
First published (updated )
Severity
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

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

RDMA/core: Silence oversized kvmalloc() warning

syzkaller triggered an oversized kvmalloc() warning. Silence it by adding GFPNOWARN.

syzkaller log: WARNING: CPU: 7 PID: 518 at mm/util.c:665 kvmallocnodenoprof+0x175/0x180 CPU: 7 UID: 0 PID: 518 Comm: crepro Not tainted 6.11.0-rc6+ #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:kvmallocnodenoprof+0x175/0x180 RSP: 0018:ffffc90001e67c10 EFLAGS: 00010246 RAX: 0000000000000100 RBX: 0000000000000400 RCX: ffffffff8149d46b RDX: 0000000000000000 RSI: ffff8881030fae80 RDI: 0000000000000002 RBP: 000000712c800000 R08: 0000000000000100 R09: 0000000000000000 R10: ffffc90001e67c10 R11: 0030ae0601000000 R12: 0000000000000000 R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000000 FS: 00007fde79159740(0000) GS:ffff88813bdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000180 CR3: 0000000105eb4005 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ibumemodpget+0x1f6/0x390 mlx5ibregusermr+0x1e8/0x450 ibuverbsregmr+0x28b/0x440 ibuverbswrite+0x7d3/0xa30 vfswrite+0x1ac/0x6c0 ksyswrite+0x134/0x170 ? sanitizercovtracepc+0x1c/0x50 dosyscall64+0x50/0x110 entrySYSCALL64afterhwframe+0x76/0x7e

1 / 2
Source: MITRE
First published (updated )
Severity
5.5
Null Pointer Dereference
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

HID: pidff: Fix null pointer dereference in pidfffindfields

1 / 2
Source: Microsoft
First published (updated )
Severity
5.5
Integer Overflow
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

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

scsi: st: Fix array overflow in stsetup()

Change the array size to follow parms size instead of a fixed value.

1 / 2
Source: NVD
First published (updated )
Severity
5.5
Null Pointer Dereference
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

drm/amdkfd: debugfs hanghws skip GPU with MES

1 / 2
Source: Microsoft
First published (updated )
Severity
5.5
Null Pointer Dereference
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

drm/amdgpu: handle amdgpucgscreatedevice() errors in amdpowerplaycreate()

1 / 2
Source: Microsoft
First published (updated )
Severity
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

fbdev: omapfb: Add 'plane' value check

1 / 2
Source: Microsoft
First published (updated )
Severity
5.5
Null Pointer Dereference
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

cifs: avoid NULL pointer dereference in dbg call

1 / 2
Source: Microsoft
First published (updated )
Severity
5.5
Null Pointer Dereference
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

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

pm: cpupower: bench: Prevent NULL dereference on malloc failure

If malloc returns NULL due to low memory, 'config' pointer can be NULL. Add a check to prevent NULL dereference.

1 / 2
Source: NVD
First published (updated )
Severity
5.5
Null Pointer Dereference
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

cpufreq: scmi: Fix null-ptr-deref in scmicpufreqgetrate()

1 / 2
Source: Microsoft
First published (updated )
Severity
5.5
Null Pointer Dereference
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

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

tipc: fix NULL pointer dereference in tipcmonreinitself()

syzbot reported:

tipc: Node number set to 1055423674 Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 3 UID: 0 PID: 6017 Comm: kworker/3:5 Not tainted 6.15.0-rc1-syzkaller-00246-g900241a5cc15 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: events tipcnetfinalizework RIP: 0010:tipcmonreinitself+0x11c/0x210 net/tipc/monitor.c:719 ... RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010 RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007 R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010 FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> tipcnetfinalize+0x10b/0x180 net/tipc/net.c:140 processonework+0x9cc/0x1b70 kernel/workqueue.c:3238 processscheduledworks kernel/workqueue.c:3319 [inline] workerthread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 retfromfork+0x45/0x80 arch/x86/kernel/process.c:153 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:245 </TASK> ... RIP: 0010:tipcmonreinitself+0x11c/0x210 net/tipc/monitor.c:719 ... RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010 RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007 R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010 FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400

There is a racing condition between workqueue created when enabling bearer and another thread created when disabling bearer right after that as follow:

enablingbearer | disablingbearer --------------- | ---------------- tipcdisctimeout() | { | bearerdisable() ... | { schedulework(&tn->work); | tipcmondelete() ... | { } | ... | writelockbh(&mon->lock); | mon->self = NULL; | writeunlockbh(&mon->lock); | ... | } tipcnetfinalizework() | } { | ... | tipcnetfinalize() | { | ... | tipcmonreinitself() | { | ... | writelockbh(&mon->lock); | mon->self->addr = tipcownaddr(net); | writeunlockbh(&mon->lock); | ... ---truncated---

1 / 2
Source: MITRE
First published (updated )
Severity
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

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

usb: cdns3: Fix deadlock when using NCM gadget

The cdns3 driver has the same NCM deadlock as fixed in cdnsp by commit 58f2fcb3a845 ("usb: cdnsp: Fix deadlock issue during using NCM gadget").

Under PREEMPTRT the deadlock can be readily triggered by heavy network traffic, for example using "iperf --bidir" over NCM ethernet link.

The deadlock occurs because the threaded interrupt handler gets preempted by a softirq, but both are protected by the same spinlock. Prevent deadlock by disabling softirq during threaded irq handler.

1 / 2
Source: MITRE
First published (updated )
Severity
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

crypto: null - Use spin lock instead of mutex

1 / 2
Source: Microsoft
First published (updated )
Severity
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

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

sound/virtio: Fix cancelsync warnings on uninitialized workstructs

Betty reported hitting the following warning:

[ 8.709131][ T221] WARNING: CPU: 2 PID: 221 at kernel/workqueue.c:4182 ... [ 8.713282][ T221] Call trace: [ 8.713365][ T221] flushwork+0x8d0/0x914 [ 8.713468][ T221] cancelworksync+0xac/0xfc [ 8.713570][ T221] cancelworksync+0x24/0x34 [ 8.713667][ T221] virtsndremove+0xa8/0xf8 [virtiosnd ab15f34d0dd772f6d11327e08a81d46dc9c36276] [ 8.713868][ T221] virtsndprobe+0x48c/0x664 [virtiosnd ab15f34d0dd772f6d11327e08a81d46dc9c36276] [ 8.714035][ T221] virtiodevprobe+0x28c/0x390 [ 8.714139][ T221] reallyprobe+0x1bc/0x4c8 ...

It seems we're hitting the error path in virtsndprobe(), which triggers a virtsndremove() which iterates over the substreams calling cancelworksync() on the elapsedperiod workstruct.

Looking at the code, from earlier in: virtsndprobe()->virtsndbuilddevs()->virtsndpcmparsecfg()

We set snd->nsubstreams, allocate the snd->substreams, and if we then hit an error on the info allocation or something in virtsndctlqueryinfo() fails, we will exit without having initialized the elapsedperiod workstruct.

When that error path unwinds we then call virtsndremove() which as long as the substreams array is allocated, will iterate through calling cancelworksync() on the uninitialized work struct hitting this warning.

Takashi Iwai suggested this fix, which initializes the substreams structure right after allocation, so that if we hit the error paths we avoid trying to cleanup uninitialized data.

Note: I have not yet managed to reproduce the issue myself, so this patch has had limited testing.

Feedback or thoughts would be appreciated!

1 / 2
Source: MITRE
First published (updated )
Severity
5.5
EPSS
0.02%
Null Pointer Dereference
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

ASoC: Intel: avs: Fix null-ptr-deref in avscomponentprobe()

1 / 2
Source: Microsoft
First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203