| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
clk: rockchip: Fix memory leak in rockchip_clk_register_pll()
If clk_register() fails, @pll->rate_table may have allocated memory by
kmemdup(), so it needs to be freed, otherwise will cause memory leak
issue, this patch fixes it. |
| In the Linux kernel, the following vulnerability has been resolved:
octeontx2-af: Add validation before accessing cgx and lmac
with the addition of new MAC blocks like CN10K RPM and CN10KB
RPM_USX, LMACs are noncontiguous and CGX blocks are also
noncontiguous. But during RVU driver initialization, the driver
is assuming they are contiguous and trying to access
cgx or lmac with their id which is resulting in kernel panic.
This patch fixes the issue by adding proper checks.
[ 23.219150] pc : cgx_lmac_read+0x38/0x70
[ 23.219154] lr : rvu_program_channels+0x3f0/0x498
[ 23.223852] sp : ffff000100d6fc80
[ 23.227158] x29: ffff000100d6fc80 x28: ffff00010009f880 x27:
000000000000005a
[ 23.234288] x26: ffff000102586768 x25: 0000000000002500 x24:
fffffffffff0f000 |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath9k: hif_usb: fix memory leak of remain_skbs
hif_dev->remain_skb is allocated and used exclusively in
ath9k_hif_usb_rx_stream(). It is implied that an allocated remain_skb is
processed and subsequently freed (in error paths) only during the next
call of ath9k_hif_usb_rx_stream().
So, if the urbs are deallocated between those two calls due to the device
deinitialization or suspend, it is possible that ath9k_hif_usb_rx_stream()
is not called next time and the allocated remain_skb is leaked. Our local
Syzkaller instance was able to trigger that.
remain_skb makes sense when receiving two consecutive urbs which are
logically linked together, i.e. a specific data field from the first skb
indicates a cached skb to be allocated, memcpy'd with some data and
subsequently processed in the next call to ath9k_hif_usb_rx_stream(). Urbs
deallocation supposedly makes that link irrelevant so we need to free the
cached skb in those cases.
Fix the leak by introducing a function to explicitly free remain_skb (if
it is not NULL) when the rx urbs have been deallocated. remain_skb is NULL
when it has not been allocated at all (hif_dev struct is kzalloced) or
when it has been processed in next call to ath9k_hif_usb_rx_stream().
Found by Linux Verification Center (linuxtesting.org) with Syzkaller. |
| The NASA’s Interplanetary Overlay Network (ION) is an implementation of Delay/Disruption Tolerant Networking (DTN). A BPv7 bundle with a malformed extension block causes uncontrolled memory allocation inside ION-DTN 4.1.3s, leading to receiver thread termination and a Denial-of-Service (DoS). The triggering bundle contains an extension block starting at `0x85070201005bbb0e20b4ea001a000927c0...`. The first byte in the extension block (0x85) indicates a CBOR array of five elements of which the first four are numbers (0x07, 0x02, 0x01, 0x00) but the fifth element is a byte string of length 27 (`0x5bbb0e20b4ea001a000927c0...`). The vulnerability seems to be due to processing the fifth element of the array (i.e., the byte string) as replacing it with a number makes the vulnerability no longer be triggered. While parsing this extension block, ION obtains a very large block length, which in the code in `bei.c`:764) seems to be passed from `blockLength` which is an unsigned int, to a 32 bit signed integer `blkSize`. The unsigned to signed conversion causes `blkSize` to hold the value of -369092043, which is then converted into a 64-bit unsigned value inside `MTAKE(blkSize)`, resulting in an attempt to allocate an unrealistic amount of memory, causing the error. As of time of publication, no known patched versions of BPv7 exist. |
| In the Linux kernel, the following vulnerability has been resolved:
ring-buffer: Fix deadloop issue on reading trace_pipe
Soft lockup occurs when reading file 'trace_pipe':
watchdog: BUG: soft lockup - CPU#6 stuck for 22s! [cat:4488]
[...]
RIP: 0010:ring_buffer_empty_cpu+0xed/0x170
RSP: 0018:ffff88810dd6fc48 EFLAGS: 00000246
RAX: 0000000000000000 RBX: 0000000000000246 RCX: ffffffff93d1aaeb
RDX: ffff88810a280040 RSI: 0000000000000008 RDI: ffff88811164b218
RBP: ffff88811164b218 R08: 0000000000000000 R09: ffff88815156600f
R10: ffffed102a2acc01 R11: 0000000000000001 R12: 0000000051651901
R13: 0000000000000000 R14: ffff888115e49500 R15: 0000000000000000
[...]
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f8d853c2000 CR3: 000000010dcd8000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
__find_next_entry+0x1a8/0x4b0
? peek_next_entry+0x250/0x250
? down_write+0xa5/0x120
? down_write_killable+0x130/0x130
trace_find_next_entry_inc+0x3b/0x1d0
tracing_read_pipe+0x423/0xae0
? tracing_splice_read_pipe+0xcb0/0xcb0
vfs_read+0x16b/0x490
ksys_read+0x105/0x210
? __ia32_sys_pwrite64+0x200/0x200
? switch_fpu_return+0x108/0x220
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x61/0xc6
Through the vmcore, I found it's because in tracing_read_pipe(),
ring_buffer_empty_cpu() found some buffer is not empty but then it
cannot read anything due to "rb_num_of_entries() == 0" always true,
Then it infinitely loop the procedure due to user buffer not been
filled, see following code path:
tracing_read_pipe() {
... ...
waitagain:
tracing_wait_pipe() // 1. find non-empty buffer here
trace_find_next_entry_inc() // 2. loop here try to find an entry
__find_next_entry()
ring_buffer_empty_cpu(); // 3. find non-empty buffer
peek_next_entry() // 4. but peek always return NULL
ring_buffer_peek()
rb_buffer_peek()
rb_get_reader_page()
// 5. because rb_num_of_entries() == 0 always true here
// then return NULL
// 6. user buffer not been filled so goto 'waitgain'
// and eventually leads to an deadloop in kernel!!!
}
By some analyzing, I found that when resetting ringbuffer, the 'entries'
of its pages are not all cleared (see rb_reset_cpu()). Then when reducing
the ringbuffer, and if some reduced pages exist dirty 'entries' data, they
will be added into 'cpu_buffer->overrun' (see rb_remove_pages()), which
cause wrong 'overrun' count and eventually cause the deadloop issue.
To fix it, we need to clear every pages in rb_reset_cpu(). |
| In the Linux kernel, the following vulnerability has been resolved:
Drivers: hv: vmbus: Don't dereference ACPI root object handle
Since the commit referenced in the Fixes: tag below the VMBus client driver
is walking the ACPI namespace up from the VMBus ACPI device to the ACPI
namespace root object trying to find Hyper-V MMIO ranges.
However, if it is not able to find them it ends trying to walk resources of
the ACPI namespace root object itself.
This object has all-ones handle, which causes a NULL pointer dereference
in the ACPI code (from dereferencing this pointer with an offset).
This in turn causes an oops on boot with VMBus host implementations that do
not provide Hyper-V MMIO ranges in their VMBus ACPI device or its
ancestors.
The QEMU VMBus implementation is an example of such implementation.
I guess providing these ranges is optional, since all tested Windows
versions seem to be able to use VMBus devices without them.
Fix this by explicitly terminating the lookup at the ACPI namespace root
object.
Note that Linux guests under KVM/QEMU do not use the Hyper-V PV interface
by default - they only do so if the KVM PV interface is missing or
disabled.
Example stack trace of such oops:
[ 3.710827] ? __die+0x1f/0x60
[ 3.715030] ? page_fault_oops+0x159/0x460
[ 3.716008] ? exc_page_fault+0x73/0x170
[ 3.716959] ? asm_exc_page_fault+0x22/0x30
[ 3.717957] ? acpi_ns_lookup+0x7a/0x4b0
[ 3.718898] ? acpi_ns_internalize_name+0x79/0xc0
[ 3.720018] acpi_ns_get_node_unlocked+0xb5/0xe0
[ 3.721120] ? acpi_ns_check_object_type+0xfe/0x200
[ 3.722285] ? acpi_rs_convert_aml_to_resource+0x37/0x6e0
[ 3.723559] ? down_timeout+0x3a/0x60
[ 3.724455] ? acpi_ns_get_node+0x3a/0x60
[ 3.725412] acpi_ns_get_node+0x3a/0x60
[ 3.726335] acpi_ns_evaluate+0x1c3/0x2c0
[ 3.727295] acpi_ut_evaluate_object+0x64/0x1b0
[ 3.728400] acpi_rs_get_method_data+0x2b/0x70
[ 3.729476] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus]
[ 3.730940] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus]
[ 3.732411] acpi_walk_resources+0x78/0xd0
[ 3.733398] vmbus_platform_driver_probe+0x9f/0x1d0 [hv_vmbus]
[ 3.734802] platform_probe+0x3d/0x90
[ 3.735684] really_probe+0x19b/0x400
[ 3.736570] ? __device_attach_driver+0x100/0x100
[ 3.737697] __driver_probe_device+0x78/0x160
[ 3.738746] driver_probe_device+0x1f/0x90
[ 3.739743] __driver_attach+0xc2/0x1b0
[ 3.740671] bus_for_each_dev+0x70/0xc0
[ 3.741601] bus_add_driver+0x10e/0x210
[ 3.742527] driver_register+0x55/0xf0
[ 3.744412] ? 0xffffffffc039a000
[ 3.745207] hv_acpi_init+0x3c/0x1000 [hv_vmbus] |
| The RegistrationMagic – Custom Registration Forms, User Registration, Payment, and User Login plugin for WordPress is vulnerable to SQL Injection in all versions up to, and including, 6.0.6.2 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for authenticated attackers, with administrator access or higher, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database. An unauthenticated attacker could utilize an injected Cross-Site Scripting via user-agent on form submission to leverage this to achieve Reflected Cross-Site Scripting. |
| The Motors – Car Dealership & Classified Listings Plugin plugin for WordPress is vulnerable to arbitrary file deletion due to insufficient file path validation when deleting profile pictures in all versions up to, and including, 1.4.89. This makes it possible for authenticated attackers, with Subscriber-level access and above, to delete arbitrary files on the server, which can easily lead to remote code execution when the right file is deleted (such as wp-config.php). |
| Dependency-Track is a component analysis platform that allows organizations to identify and reduce risk in the software supply chain. Prior to version 4.13.5, Dependency-Track may send credentials meant for a private NuGet repository to `api.nuget.org` via the HTTP `Authorization` header, and may disclose names and versions of components marked as internal to `api.nuget.org`. This can happen if the Dependency-Track instance contains .NET components, a custom NuGet repository has been configured, the custom repository has been configured with authentication credentials, and the repository server does not provide `PackageBaseAddress` resource in its service index. The issue has been fixed in Dependency-Track 4.13.5. Some workarounds are avaialble. Disable custom NuGet repositories until the patch has been applied, invalidate the previously used credentials, and generate new credentials for usage after the patch has been applied. |
| Dell PowerProtect Data Domain BoostFS for Linux Ubuntu systems of Feature Release versions 7.7.1.0 through 8.3.0.15, LTS2025 release version 8.3.1.0, LTS2024 release versions 7.13.1.0 through 7.13.1.30, LTS 2023 release versions 7.10.1.0 through 7.10.1.60, contain an Incorrect Privilege Assignment vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Unauthorized access. |
| An Improper Resource Locking vulnerability in the SDM component of B&R Automation Runtime versions before 6.3 and before Q4.93 may allow an unauthenticated network-based attacker to delete data causing denial of service conditions. |
| A Generation of Predictable Numbers or Identifiers vulnerability in the SDM component of B&R Automation Runtime versions before 6.4 may allow an unauthenticated network-based attacker to take over already established sessions. |
| A security flaw has been discovered in kaifangqian kaifangqian-base up to 7b3faecda13848b3ced6c17c7423b76c5b47b8ab. This issue affects the function getAllUsers of the file kaifangqian-parent/kaifangqian-system/src/main/java/com/kaifangqian/modules/system/controller/SysUserController.java. The manipulation results in information disclosure. The attack can be launched remotely. The exploit has been released to the public and may be exploited. This product does not use versioning. This is why information about affected and unaffected releases are unavailable. |
| In the Linux kernel, the following vulnerability has been resolved:
net/handshake: fix null-ptr-deref in handshake_nl_done_doit()
We should not call trace_handshake_cmd_done_err() if socket lookup has failed.
Also we should call trace_handshake_cmd_done_err() before releasing the file,
otherwise dereferencing sock->sk can return garbage.
This also reverts 7afc6d0a107f ("net/handshake: Fix uninitialized local variable")
Unable to handle kernel paging request at virtual address dfff800000000003
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
Mem abort info:
ESR = 0x0000000096000005
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x05: level 1 translation fault
Data abort info:
ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
CM = 0, WnR = 0, TnD = 0, TagAccess = 0
GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[dfff800000000003] address between user and kernel address ranges
Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
Modules linked in:
CPU: 1 PID: 5986 Comm: syz-executor292 Not tainted 6.5.0-rc7-syzkaller-gfe4469582053 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : handshake_nl_done_doit+0x198/0x9c8 net/handshake/netlink.c:193
lr : handshake_nl_done_doit+0x180/0x9c8
sp : ffff800096e37180
x29: ffff800096e37200 x28: 1ffff00012dc6e34 x27: dfff800000000000
x26: ffff800096e373d0 x25: 0000000000000000 x24: 00000000ffffffa8
x23: ffff800096e373f0 x22: 1ffff00012dc6e38 x21: 0000000000000000
x20: ffff800096e371c0 x19: 0000000000000018 x18: 0000000000000000
x17: 0000000000000000 x16: ffff800080516cc4 x15: 0000000000000001
x14: 1fffe0001b14aa3b x13: 0000000000000000 x12: 0000000000000000
x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000003
x8 : 0000000000000003 x7 : ffff800080afe47c x6 : 0000000000000000
x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff800080a88078
x2 : 0000000000000001 x1 : 00000000ffffffa8 x0 : 0000000000000000
Call trace:
handshake_nl_done_doit+0x198/0x9c8 net/handshake/netlink.c:193
genl_family_rcv_msg_doit net/netlink/genetlink.c:970 [inline]
genl_family_rcv_msg net/netlink/genetlink.c:1050 [inline]
genl_rcv_msg+0x96c/0xc50 net/netlink/genetlink.c:1067
netlink_rcv_skb+0x214/0x3c4 net/netlink/af_netlink.c:2549
genl_rcv+0x38/0x50 net/netlink/genetlink.c:1078
netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
netlink_unicast+0x660/0x8d4 net/netlink/af_netlink.c:1365
netlink_sendmsg+0x834/0xb18 net/netlink/af_netlink.c:1914
sock_sendmsg_nosec net/socket.c:725 [inline]
sock_sendmsg net/socket.c:748 [inline]
____sys_sendmsg+0x56c/0x840 net/socket.c:2494
___sys_sendmsg net/socket.c:2548 [inline]
__sys_sendmsg+0x26c/0x33c net/socket.c:2577
__do_sys_sendmsg net/socket.c:2586 [inline]
__se_sys_sendmsg net/socket.c:2584 [inline]
__arm64_sys_sendmsg+0x80/0x94 net/socket.c:2584
__invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]
invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51
el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136
do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155
el0_svc+0x58/0x16c arch/arm64/kernel/entry-common.c:678
el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696
el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591
Code: 12800108 b90043e8 910062b3 d343fe68 (387b6908) |
| In the Linux kernel, the following vulnerability has been resolved:
tun: Fix memory leak for detached NAPI queue.
syzkaller reported [0] memory leaks of sk and skb related to the TUN
device with no repro, but we can reproduce it easily with:
struct ifreq ifr = {}
int fd_tun, fd_tmp;
char buf[4] = {};
fd_tun = openat(AT_FDCWD, "/dev/net/tun", O_WRONLY, 0);
ifr.ifr_flags = IFF_TUN | IFF_NAPI | IFF_MULTI_QUEUE;
ioctl(fd_tun, TUNSETIFF, &ifr);
ifr.ifr_flags = IFF_DETACH_QUEUE;
ioctl(fd_tun, TUNSETQUEUE, &ifr);
fd_tmp = socket(AF_PACKET, SOCK_PACKET, 0);
ifr.ifr_flags = IFF_UP;
ioctl(fd_tmp, SIOCSIFFLAGS, &ifr);
write(fd_tun, buf, sizeof(buf));
close(fd_tun);
If we enable NAPI and multi-queue on a TUN device, we can put skb into
tfile->sk.sk_write_queue after the queue is detached. We should prevent
it by checking tfile->detached before queuing skb.
Note this must be done under tfile->sk.sk_write_queue.lock because write()
and ioctl(IFF_DETACH_QUEUE) can run concurrently. Otherwise, there would
be a small race window:
write() ioctl(IFF_DETACH_QUEUE)
`- tun_get_user `- __tun_detach
|- if (tfile->detached) |- tun_disable_queue
| `-> false | `- tfile->detached = tun
| `- tun_queue_purge
|- spin_lock_bh(&queue->lock)
`- __skb_queue_tail(queue, skb)
Another solution is to call tun_queue_purge() when closing and
reattaching the detached queue, but it could paper over another
problems. Also, we do the same kind of test for IFF_NAPI_FRAGS.
[0]:
unreferenced object 0xffff88801edbc800 (size 2048):
comm "syz-executor.1", pid 33269, jiffies 4295743834 (age 18.756s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............
backtrace:
[<000000008c16ea3d>] __do_kmalloc_node mm/slab_common.c:965 [inline]
[<000000008c16ea3d>] __kmalloc+0x4a/0x130 mm/slab_common.c:979
[<000000003addde56>] kmalloc include/linux/slab.h:563 [inline]
[<000000003addde56>] sk_prot_alloc+0xef/0x1b0 net/core/sock.c:2035
[<000000003e20621f>] sk_alloc+0x36/0x2f0 net/core/sock.c:2088
[<0000000028e43843>] tun_chr_open+0x3d/0x190 drivers/net/tun.c:3438
[<000000001b0f1f28>] misc_open+0x1a6/0x1f0 drivers/char/misc.c:165
[<000000004376f706>] chrdev_open+0x111/0x300 fs/char_dev.c:414
[<00000000614d379f>] do_dentry_open+0x2f9/0x750 fs/open.c:920
[<000000008eb24774>] do_open fs/namei.c:3636 [inline]
[<000000008eb24774>] path_openat+0x143f/0x1a30 fs/namei.c:3791
[<00000000955077b5>] do_filp_open+0xce/0x1c0 fs/namei.c:3818
[<00000000b78973b0>] do_sys_openat2+0xf0/0x260 fs/open.c:1356
[<00000000057be699>] do_sys_open fs/open.c:1372 [inline]
[<00000000057be699>] __do_sys_openat fs/open.c:1388 [inline]
[<00000000057be699>] __se_sys_openat fs/open.c:1383 [inline]
[<00000000057be699>] __x64_sys_openat+0x83/0xf0 fs/open.c:1383
[<00000000a7d2182d>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
[<00000000a7d2182d>] do_syscall_64+0x3c/0x90 arch/x86/entry/common.c:80
[<000000004cc4e8c4>] entry_SYSCALL_64_after_hwframe+0x72/0xdc
unreferenced object 0xffff88802f671700 (size 240):
comm "syz-executor.1", pid 33269, jiffies 4295743854 (age 18.736s)
hex dump (first 32 bytes):
68 c9 db 1e 80 88 ff ff 68 c9 db 1e 80 88 ff ff h.......h.......
00 c0 7b 2f 80 88 ff ff 00 c8 db 1e 80 88 ff ff ..{/............
backtrace:
[<00000000e9d9fdb6>] __alloc_skb+0x223/0x250 net/core/skbuff.c:644
[<000000002c3e4e0b>] alloc_skb include/linux/skbuff.h:1288 [inline]
[<000000002c3e4e0b>] alloc_skb_with_frags+0x6f/0x350 net/core/skbuff.c:6378
[<00000000825f98d7>] sock_alloc_send_pskb+0x3ac/0x3e0 net/core/sock.c:2729
[<00000000e9eb3df3>] tun_alloc_skb drivers/net/tun.c:1529 [inline]
[<
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
bcache: Fix __bch_btree_node_alloc to make the failure behavior consistent
In some specific situations, the return value of __bch_btree_node_alloc
may be NULL. This may lead to a potential NULL pointer dereference in
caller function like a calling chain :
btree_split->bch_btree_node_alloc->__bch_btree_node_alloc.
Fix it by initializing the return value in __bch_btree_node_alloc. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/i915: Fix system suspend without fbdev being initialized
If fbdev is not initialized for some reason - in practice on platforms
without display - suspending fbdev should be skipped during system
suspend, fix this up. While at it add an assert that suspending fbdev
only happens with the display present.
This fixes the following:
[ 91.227923] PM: suspend entry (s2idle)
[ 91.254598] Filesystems sync: 0.025 seconds
[ 91.270518] Freezing user space processes
[ 91.272266] Freezing user space processes completed (elapsed 0.001 seconds)
[ 91.272686] OOM killer disabled.
[ 91.272872] Freezing remaining freezable tasks
[ 91.274295] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
[ 91.659622] BUG: kernel NULL pointer dereference, address: 00000000000001c8
[ 91.659981] #PF: supervisor write access in kernel mode
[ 91.660252] #PF: error_code(0x0002) - not-present page
[ 91.660511] PGD 0 P4D 0
[ 91.660647] Oops: 0002 [#1] PREEMPT SMP NOPTI
[ 91.660875] CPU: 4 PID: 917 Comm: bash Not tainted 6.2.0-rc7+ #54
[ 91.661185] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20221117gitfff6d81270b5-9.fc37 unknown
[ 91.661680] RIP: 0010:mutex_lock+0x19/0x30
[ 91.661914] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 53 48 89 fb e8 62 d3 ff ff 31 c0 65 48 8b 14 25 00 15 03 00 <f0> 48 0f b1 13 75 06 5b c3 cc cc cc cc 48 89 df 5b eb b4 0f 1f 40
[ 91.662840] RSP: 0018:ffffa1e8011ffc08 EFLAGS: 00010246
[ 91.663087] RAX: 0000000000000000 RBX: 00000000000001c8 RCX: 0000000000000000
[ 91.663440] RDX: ffff8be455eb0000 RSI: 0000000000000001 RDI: 00000000000001c8
[ 91.663802] RBP: ffff8be459440000 R08: ffff8be459441f08 R09: ffffffff8e1432c0
[ 91.664167] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
[ 91.664532] R13: 00000000000001c8 R14: 0000000000000000 R15: ffff8be442f4fb20
[ 91.664905] FS: 00007f28ffc16740(0000) GS:ffff8be4bb900000(0000) knlGS:0000000000000000
[ 91.665334] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 91.665626] CR2: 00000000000001c8 CR3: 0000000114926006 CR4: 0000000000770ee0
[ 91.665988] PKRU: 55555554
[ 91.666131] Call Trace:
[ 91.666265] <TASK>
[ 91.666381] intel_fbdev_set_suspend+0x97/0x1b0 [i915]
[ 91.666738] i915_drm_suspend+0xb9/0x100 [i915]
[ 91.667029] pci_pm_suspend+0x78/0x170
[ 91.667234] ? __pfx_pci_pm_suspend+0x10/0x10
[ 91.667461] dpm_run_callback+0x47/0x150
[ 91.667673] __device_suspend+0x10a/0x4e0
[ 91.667880] dpm_suspend+0x134/0x270
[ 91.668069] dpm_suspend_start+0x79/0x80
[ 91.668272] suspend_devices_and_enter+0x11b/0x890
[ 91.668526] pm_suspend.cold+0x270/0x2fc
[ 91.668737] state_store+0x46/0x90
[ 91.668916] kernfs_fop_write_iter+0x11b/0x200
[ 91.669153] vfs_write+0x1e1/0x3a0
[ 91.669336] ksys_write+0x53/0xd0
[ 91.669510] do_syscall_64+0x58/0xc0
[ 91.669699] ? syscall_exit_to_user_mode_prepare+0x18e/0x1c0
[ 91.669980] ? syscall_exit_to_user_mode_prepare+0x18e/0x1c0
[ 91.670278] ? syscall_exit_to_user_mode+0x17/0x40
[ 91.670524] ? do_syscall_64+0x67/0xc0
[ 91.670717] ? __irq_exit_rcu+0x3d/0x140
[ 91.670931] entry_SYSCALL_64_after_hwframe+0x72/0xdc
[ 91.671202] RIP: 0033:0x7f28ffd14284
v2: CC stable. (Jani)
References: https://gitlab.freedesktop.org/drm/intel/-/issues/8015
(cherry picked from commit 9542d708409a41449e99c9a464deb5e062c4bee2) |
| In the Linux kernel, the following vulnerability has been resolved:
clk: Fix memory leak in devm_clk_notifier_register()
devm_clk_notifier_register() allocates a devres resource for clk
notifier but didn't register that to the device, so the notifier didn't
get unregistered on device detach and the allocated resource was leaked.
Fix the issue by registering the resource through devres_add().
This issue was found with kmemleak on a Chromebook. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_event: call disconnect callback before deleting conn
In hci_cs_disconnect, we do hci_conn_del even if disconnection failed.
ISO, L2CAP and SCO connections refer to the hci_conn without
hci_conn_get, so disconn_cfm must be called so they can clean up their
conn, otherwise use-after-free occurs.
ISO:
==========================================================
iso_sock_connect:880: sk 00000000eabd6557
iso_connect_cis:356: 70:1a:b8:98:ff:a2 -> 28:3d:c2:4a:7e:da
...
iso_conn_add:140: hcon 000000001696f1fd conn 00000000b6251073
hci_dev_put:1487: hci0 orig refcnt 17
__iso_chan_add:214: conn 00000000b6251073
iso_sock_clear_timer:117: sock 00000000eabd6557 state 3
...
hci_rx_work:4085: hci0 Event packet
hci_event_packet:7601: hci0: event 0x0f
hci_cmd_status_evt:4346: hci0: opcode 0x0406
hci_cs_disconnect:2760: hci0: status 0x0c
hci_sent_cmd_data:3107: hci0 opcode 0x0406
hci_conn_del:1151: hci0 hcon 000000001696f1fd handle 2560
hci_conn_unlink:1102: hci0: hcon 000000001696f1fd
hci_conn_drop:1451: hcon 00000000d8521aaf orig refcnt 2
hci_chan_list_flush:2780: hcon 000000001696f1fd
hci_dev_put:1487: hci0 orig refcnt 21
hci_dev_put:1487: hci0 orig refcnt 20
hci_req_cmd_complete:3978: opcode 0x0406 status 0x0c
... <no iso_* activity on sk/conn> ...
iso_sock_sendmsg:1098: sock 00000000dea5e2e0, sk 00000000eabd6557
BUG: kernel NULL pointer dereference, address: 0000000000000668
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP PTI
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014
RIP: 0010:iso_sock_sendmsg (net/bluetooth/iso.c:1112) bluetooth
==========================================================
L2CAP:
==================================================================
hci_cmd_status_evt:4359: hci0: opcode 0x0406
hci_cs_disconnect:2760: hci0: status 0x0c
hci_sent_cmd_data:3085: hci0 opcode 0x0406
hci_conn_del:1151: hci0 hcon ffff88800c999000 handle 3585
hci_conn_unlink:1102: hci0: hcon ffff88800c999000
hci_chan_list_flush:2780: hcon ffff88800c999000
hci_chan_del:2761: hci0 hcon ffff88800c999000 chan ffff888018ddd280
...
BUG: KASAN: slab-use-after-free in hci_send_acl+0x2d/0x540 [bluetooth]
Read of size 8 at addr ffff888018ddd298 by task bluetoothd/1175
CPU: 0 PID: 1175 Comm: bluetoothd Tainted: G E 6.4.0-rc4+ #2
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x5b/0x90
print_report+0xcf/0x670
? __virt_addr_valid+0xf8/0x180
? hci_send_acl+0x2d/0x540 [bluetooth]
kasan_report+0xa8/0xe0
? hci_send_acl+0x2d/0x540 [bluetooth]
hci_send_acl+0x2d/0x540 [bluetooth]
? __pfx___lock_acquire+0x10/0x10
l2cap_chan_send+0x1fd/0x1300 [bluetooth]
? l2cap_sock_sendmsg+0xf2/0x170 [bluetooth]
? __pfx_l2cap_chan_send+0x10/0x10 [bluetooth]
? lock_release+0x1d5/0x3c0
? mark_held_locks+0x1a/0x90
l2cap_sock_sendmsg+0x100/0x170 [bluetooth]
sock_write_iter+0x275/0x280
? __pfx_sock_write_iter+0x10/0x10
? __pfx___lock_acquire+0x10/0x10
do_iter_readv_writev+0x176/0x220
? __pfx_do_iter_readv_writev+0x10/0x10
? find_held_lock+0x83/0xa0
? selinux_file_permission+0x13e/0x210
do_iter_write+0xda/0x340
vfs_writev+0x1b4/0x400
? __pfx_vfs_writev+0x10/0x10
? __seccomp_filter+0x112/0x750
? populate_seccomp_data+0x182/0x220
? __fget_light+0xdf/0x100
? do_writev+0x19d/0x210
do_writev+0x19d/0x210
? __pfx_do_writev+0x10/0x10
? mark_held_locks+0x1a/0x90
do_syscall_64+0x60/0x90
? lockdep_hardirqs_on_prepare+0x149/0x210
? do_syscall_64+0x6c/0x90
? lockdep_hardirqs_on_prepare+0x149/0x210
entry_SYSCALL_64_after_hwframe+0x72/0xdc
RIP: 0033:0x7ff45cb23e64
Code: 15 d1 1f 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d 9d a7 0d 00 00 74 13 b8 14 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89
RSP: 002b:00007fff21ae09b8 EFLAGS: 00000202 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX:
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
nvme-core: fix dev_pm_qos memleak
Call dev_pm_qos_hide_latency_tolerance() in the error unwind patch to
avoid following kmemleak:-
blktests (master) # kmemleak-clear; ./check nvme/044;
blktests (master) # kmemleak-scan ; kmemleak-show
nvme/044 (Test bi-directional authentication) [passed]
runtime 2.111s ... 2.124s
unreferenced object 0xffff888110c46240 (size 96):
comm "nvme", pid 33461, jiffies 4345365353 (age 75.586s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000069ac2cec>] kmalloc_trace+0x25/0x90
[<000000006acc66d5>] dev_pm_qos_update_user_latency_tolerance+0x6f/0x100
[<00000000cc376ea7>] nvme_init_ctrl+0x38e/0x410 [nvme_core]
[<000000007df61b4b>] 0xffffffffc05e88b3
[<00000000d152b985>] 0xffffffffc05744cb
[<00000000f04a4041>] vfs_write+0xc5/0x3c0
[<00000000f9491baf>] ksys_write+0x5f/0xe0
[<000000001c46513d>] do_syscall_64+0x3b/0x90
[<00000000ecf348fe>] entry_SYSCALL_64_after_hwframe+0x72/0xdc |
