| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
skbuff: Fix a race between coalescing and releasing SKBs
Commit 1effe8ca4e34 ("skbuff: fix coalescing for page_pool fragment
recycling") allowed coalescing to proceed with non page pool page and page
pool page when @from is cloned, i.e.
to->pp_recycle --> false
from->pp_recycle --> true
skb_cloned(from) --> true
However, it actually requires skb_cloned(@from) to hold true until
coalescing finishes in this situation. If the other cloned SKB is
released while the merging is in process, from_shinfo->nr_frags will be
set to 0 toward the end of the function, causing the increment of frag
page _refcount to be unexpectedly skipped resulting in inconsistent
reference counts. Later when SKB(@to) is released, it frees the page
directly even though the page pool page is still in use, leading to
use-after-free or double-free errors. So it should be prohibited.
The double-free error message below prompted us to investigate:
BUG: Bad page state in process swapper/1 pfn:0e0d1
page:00000000c6548b28 refcount:-1 mapcount:0 mapping:0000000000000000
index:0x2 pfn:0xe0d1
flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)
raw: 000fffffc0000000 0000000000000000 ffffffff00000101 0000000000000000
raw: 0000000000000002 0000000000000000 ffffffffffffffff 0000000000000000
page dumped because: nonzero _refcount
CPU: 1 PID: 0 Comm: swapper/1 Tainted: G E 6.2.0+
Call Trace:
<IRQ>
dump_stack_lvl+0x32/0x50
bad_page+0x69/0xf0
free_pcp_prepare+0x260/0x2f0
free_unref_page+0x20/0x1c0
skb_release_data+0x10b/0x1a0
napi_consume_skb+0x56/0x150
net_rx_action+0xf0/0x350
? __napi_schedule+0x79/0x90
__do_softirq+0xc8/0x2b1
__irq_exit_rcu+0xb9/0xf0
common_interrupt+0x82/0xa0
</IRQ>
<TASK>
asm_common_interrupt+0x22/0x40
RIP: 0010:default_idle+0xb/0x20 |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix calltrace warning in amddrm_buddy_fini
The following call trace is observed when removing the amdgpu driver, which
is caused by that BOs allocated for psp are not freed until removing.
[61811.450562] RIP: 0010:amddrm_buddy_fini.cold+0x29/0x47 [amddrm_buddy]
[61811.450577] Call Trace:
[61811.450577] <TASK>
[61811.450579] amdgpu_vram_mgr_fini+0x135/0x1c0 [amdgpu]
[61811.450728] amdgpu_ttm_fini+0x207/0x290 [amdgpu]
[61811.450870] amdgpu_bo_fini+0x27/0xa0 [amdgpu]
[61811.451012] gmc_v9_0_sw_fini+0x4a/0x60 [amdgpu]
[61811.451166] amdgpu_device_fini_sw+0x117/0x520 [amdgpu]
[61811.451306] amdgpu_driver_release_kms+0x16/0x30 [amdgpu]
[61811.451447] devm_drm_dev_init_release+0x4d/0x80 [drm]
[61811.451466] devm_action_release+0x15/0x20
[61811.451469] release_nodes+0x40/0xb0
[61811.451471] devres_release_all+0x9b/0xd0
[61811.451473] __device_release_driver+0x1bb/0x2a0
[61811.451476] driver_detach+0xf3/0x140
[61811.451479] bus_remove_driver+0x6c/0xf0
[61811.451481] driver_unregister+0x31/0x60
[61811.451483] pci_unregister_driver+0x40/0x90
[61811.451486] amdgpu_exit+0x15/0x447 [amdgpu]
For smu v13_0_2, if the GPU supports xgmi, refer to
commit f5c7e7797060 ("drm/amdgpu: Adjust removal control flow for smu v13_0_2"),
it will run gpu recover in AMDGPU_RESET_FOR_DEVICE_REMOVE mode when removing,
which makes all devices in hive list have hw reset but no resume except the
basic ip blocks, then other ip blocks will not call .hw_fini according to
ip_block.status.hw.
Since psp_free_shared_bufs just includes some software operations, so move
it to psp_sw_fini. |
| In the Linux kernel, the following vulnerability has been resolved:
irqchip/ti-sci: Fix refcount leak in ti_sci_intr_irq_domain_probe
of_irq_find_parent() returns a node pointer with refcount incremented,
We should use of_node_put() on it when not needed anymore.
Add missing of_node_put() to avoid refcount leak. |
| In the Linux kernel, the following vulnerability has been resolved:
mlxsw: minimal: fix potential memory leak in mlxsw_m_linecards_init
The line cards array is not freed in the error path of
mlxsw_m_linecards_init(), which can lead to a memory leak. Fix by
freeing the array in the error path, thereby making the error path
identical to mlxsw_m_linecards_fini(). |
| In the Linux kernel, the following vulnerability has been resolved:
usb: ucsi_acpi: Increase the command completion timeout
Commit 130a96d698d7 ("usb: typec: ucsi: acpi: Increase command
completion timeout value") increased the timeout from 5 seconds
to 60 seconds due to issues related to alternate mode discovery.
After the alternate mode discovery switch to polled mode
the timeout was reduced, but instead of being set back to
5 seconds it was reduced to 1 second.
This is causing problems when using a Lenovo ThinkPad X1 yoga gen7
connected over Type-C to a LG 27UL850-W (charging DP over Type-C).
When the monitor is already connected at boot the following error
is logged: "PPM init failed (-110)", /sys/class/typec is empty and
on unplugging the NULL pointer deref fixed earlier in this series
happens.
When the monitor is connected after boot the following error
is logged instead: "GET_CONNECTOR_STATUS failed (-110)".
Setting the timeout back to 5 seconds fixes both cases. |
| In the Linux kernel, the following vulnerability has been resolved:
rapidio: fix possible UAF when kfifo_alloc() fails
If kfifo_alloc() fails in mport_cdev_open(), goto err_fifo and just free
priv. But priv is still in the chdev->file_list, then list traversal
may cause UAF. This fixes the following smatch warning:
drivers/rapidio/devices/rio_mport_cdev.c:1930 mport_cdev_open() warn: '&priv->list' not removed from list |
| In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix memory leaks in error path
The memory allocated by vxlan_vnigroup_init() is not freed in the error
path, leading to memory leaks [1]. Fix by calling
vxlan_vnigroup_uninit() in the error path.
The leaks can be reproduced by annotating gro_cells_init() with
ALLOW_ERROR_INJECTION() and then running:
# echo "100" > /sys/kernel/debug/fail_function/probability
# echo "1" > /sys/kernel/debug/fail_function/times
# echo "gro_cells_init" > /sys/kernel/debug/fail_function/inject
# printf %#x -12 > /sys/kernel/debug/fail_function/gro_cells_init/retval
# ip link add name vxlan0 type vxlan dstport 4789 external vnifilter
RTNETLINK answers: Cannot allocate memory
[1]
unreferenced object 0xffff88810db84a00 (size 512):
comm "ip", pid 330, jiffies 4295010045 (age 66.016s)
hex dump (first 32 bytes):
f8 d5 76 0e 81 88 ff ff 01 00 00 00 00 00 00 02 ..v.............
03 00 04 00 48 00 00 00 00 00 00 01 04 00 01 00 ....H...........
backtrace:
[<ffffffff81a3097a>] kmalloc_trace+0x2a/0x60
[<ffffffff82f049fc>] vxlan_vnigroup_init+0x4c/0x160
[<ffffffff82ecd69e>] vxlan_init+0x1ae/0x280
[<ffffffff836858ca>] register_netdevice+0x57a/0x16d0
[<ffffffff82ef67b7>] __vxlan_dev_create+0x7c7/0xa50
[<ffffffff82ef6ce6>] vxlan_newlink+0xd6/0x130
[<ffffffff836d02ab>] __rtnl_newlink+0x112b/0x18a0
[<ffffffff836d0a8c>] rtnl_newlink+0x6c/0xa0
[<ffffffff836c0ddf>] rtnetlink_rcv_msg+0x43f/0xd40
[<ffffffff83908ce0>] netlink_rcv_skb+0x170/0x440
[<ffffffff839066af>] netlink_unicast+0x53f/0x810
[<ffffffff839072d8>] netlink_sendmsg+0x958/0xe70
[<ffffffff835c319f>] ____sys_sendmsg+0x78f/0xa90
[<ffffffff835cd6da>] ___sys_sendmsg+0x13a/0x1e0
[<ffffffff835cd94c>] __sys_sendmsg+0x11c/0x1f0
[<ffffffff8424da78>] do_syscall_64+0x38/0x80
unreferenced object 0xffff88810e76d5f8 (size 192):
comm "ip", pid 330, jiffies 4295010045 (age 66.016s)
hex dump (first 32 bytes):
04 00 00 00 00 00 00 00 db e1 4f e7 00 00 00 00 ..........O.....
08 d6 76 0e 81 88 ff ff 08 d6 76 0e 81 88 ff ff ..v.......v.....
backtrace:
[<ffffffff81a3162e>] __kmalloc_node+0x4e/0x90
[<ffffffff81a0e166>] kvmalloc_node+0xa6/0x1f0
[<ffffffff8276e1a3>] bucket_table_alloc.isra.0+0x83/0x460
[<ffffffff8276f18b>] rhashtable_init+0x43b/0x7c0
[<ffffffff82f04a1c>] vxlan_vnigroup_init+0x6c/0x160
[<ffffffff82ecd69e>] vxlan_init+0x1ae/0x280
[<ffffffff836858ca>] register_netdevice+0x57a/0x16d0
[<ffffffff82ef67b7>] __vxlan_dev_create+0x7c7/0xa50
[<ffffffff82ef6ce6>] vxlan_newlink+0xd6/0x130
[<ffffffff836d02ab>] __rtnl_newlink+0x112b/0x18a0
[<ffffffff836d0a8c>] rtnl_newlink+0x6c/0xa0
[<ffffffff836c0ddf>] rtnetlink_rcv_msg+0x43f/0xd40
[<ffffffff83908ce0>] netlink_rcv_skb+0x170/0x440
[<ffffffff839066af>] netlink_unicast+0x53f/0x810
[<ffffffff839072d8>] netlink_sendmsg+0x958/0xe70
[<ffffffff835c319f>] ____sys_sendmsg+0x78f/0xa90 |
| The killProcesses mutation in Chaos Controller Manager is vulnerable to OS command injection. In conjunction with CVE-2025-59358, this allows unauthenticated in-cluster attackers to perform remote code execution across the cluster. |
| Elevation of Privileges in the cleaning feature of Gen Digital CCleaner version 6.33.11465 on Windows allows a local user to gain SYSTEM privileges via exploiting insecure file delete operations. Reported in CCleaner v. 6.33.11465. This issue affects CCleaner: before < 6.36.11508. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath9k: don't allow to overwrite ENDPOINT0 attributes
A bad USB device is able to construct a service connection response
message with target endpoint being ENDPOINT0 which is reserved for
HTC_CTRL_RSVD_SVC and should not be modified to be used for any other
services.
Reject such service connection responses.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: fix race in sock_map_free()
sock_map_free() calls release_sock(sk) without owning a reference
on the socket. This can cause use-after-free as syzbot found [1]
Jakub Sitnicki already took care of a similar issue
in sock_hash_free() in commit 75e68e5bf2c7 ("bpf, sockhash:
Synchronize delete from bucket list on map free")
[1]
refcount_t: decrement hit 0; leaking memory.
WARNING: CPU: 0 PID: 3785 at lib/refcount.c:31 refcount_warn_saturate+0x17c/0x1a0 lib/refcount.c:31
Modules linked in:
CPU: 0 PID: 3785 Comm: kworker/u4:6 Not tainted 6.1.0-rc7-syzkaller-00103-gef4d3ea40565 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Workqueue: events_unbound bpf_map_free_deferred
RIP: 0010:refcount_warn_saturate+0x17c/0x1a0 lib/refcount.c:31
Code: 68 8b 31 c0 e8 75 71 15 fd 0f 0b e9 64 ff ff ff e8 d9 6e 4e fd c6 05 62 9c 3d 0a 01 48 c7 c7 80 bb 68 8b 31 c0 e8 54 71 15 fd <0f> 0b e9 43 ff ff ff 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c a2 fe ff
RSP: 0018:ffffc9000456fb60 EFLAGS: 00010246
RAX: eae59bab72dcd700 RBX: 0000000000000004 RCX: ffff8880207057c0
RDX: 0000000000000000 RSI: 0000000000000201 RDI: 0000000000000000
RBP: 0000000000000004 R08: ffffffff816fdabd R09: fffff520008adee5
R10: fffff520008adee5 R11: 1ffff920008adee4 R12: 0000000000000004
R13: dffffc0000000000 R14: ffff88807b1c6c00 R15: 1ffff1100f638dcf
FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b30c30000 CR3: 000000000d08e000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
__refcount_dec include/linux/refcount.h:344 [inline]
refcount_dec include/linux/refcount.h:359 [inline]
__sock_put include/net/sock.h:779 [inline]
tcp_release_cb+0x2d0/0x360 net/ipv4/tcp_output.c:1092
release_sock+0xaf/0x1c0 net/core/sock.c:3468
sock_map_free+0x219/0x2c0 net/core/sock_map.c:356
process_one_work+0x81c/0xd10 kernel/workqueue.c:2289
worker_thread+0xb14/0x1330 kernel/workqueue.c:2436
kthread+0x266/0x300 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
</TASK> |
| In the Linux kernel, the following vulnerability has been resolved:
lib/crypto: arm/poly1305: Fix register corruption in no-SIMD contexts
Restore the SIMD usability check that was removed by commit 773426f4771b
("crypto: arm/poly1305 - Add block-only interface").
This safety check is cheap and is well worth eliminating a footgun.
While the Poly1305 functions should not be called when SIMD registers
are unusable, if they are anyway, they should just do the right thing
instead of corrupting random tasks' registers and/or computing incorrect
MACs. Fixing this is also needed for poly1305_kunit to pass.
Just use may_use_simd() instead of the original crypto_simd_usable(),
since poly1305_kunit won't rely on crypto_simd_disabled_for_test. |
| A vulnerability was identified in Tenda AC9 and AC15 15.03.05.14/15.03.05.18. This vulnerability affects the function formexeCommand of the file /goform/exeCommand. Such manipulation of the argument cmdinput leads to buffer overflow. The attack can be executed remotely. The exploit is publicly available and might be used. |
| A vulnerability was detected in Campcodes Online Job Finder System 1.0. The impacted element is an unknown function of the file /eris/applicationform.php. The manipulation of the argument picture results in unrestricted upload. It is possible to launch the attack remotely. The exploit is now public and may be used. |
| In the Linux kernel, the following vulnerability has been resolved:
fsverity: reject FS_IOC_ENABLE_VERITY on mode 3 fds
Commit 56124d6c87fd ("fsverity: support enabling with tree block size <
PAGE_SIZE") changed FS_IOC_ENABLE_VERITY to use __kernel_read() to read
the file's data, instead of direct pagecache accesses.
An unintended consequence of this is that the
'WARN_ON_ONCE(!(file->f_mode & FMODE_READ))' in __kernel_read() became
reachable by fuzz tests. This happens if FS_IOC_ENABLE_VERITY is called
on a fd opened with access mode 3, which means "ioctl access only".
Arguably, FS_IOC_ENABLE_VERITY should work on ioctl-only fds. But
ioctl-only fds are a weird Linux extension that is rarely used and that
few people even know about. (The documentation for FS_IOC_ENABLE_VERITY
even specifically says it requires O_RDONLY.) It's probably not
worthwhile to make the ioctl internally open a new fd just to handle
this case. Thus, just reject the ioctl on such fds for now. |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix use-after-free of new block group that became unused
If a task creates a new block group and that block group becomes unused
before we finish its creation, at btrfs_create_pending_block_groups(),
then when btrfs_mark_bg_unused() is called against the block group, we
assume that the block group is currently in the list of block groups to
reclaim, and we move it out of the list of new block groups and into the
list of unused block groups. This has two consequences:
1) We move it out of the list of new block groups associated to the
current transaction. So the block group creation is not finished and
if we attempt to delete the bg because it's unused, we will not find
the block group item in the extent tree (or the new block group tree),
its device extent items in the device tree etc, resulting in the
deletion to fail due to the missing items;
2) We don't increment the reference count on the block group when we
move it to the list of unused block groups, because we assumed the
block group was on the list of block groups to reclaim, and in that
case it already has the correct reference count. However the block
group was on the list of new block groups, in which case no extra
reference was taken because it's local to the current task. This
later results in doing an extra reference count decrement when
removing the block group from the unused list, eventually leading the
reference count to 0.
This second case was caught when running generic/297 from fstests, which
produced the following assertion failure and stack trace:
[589.559] assertion failed: refcount_read(&block_group->refs) == 1, in fs/btrfs/block-group.c:4299
[589.559] ------------[ cut here ]------------
[589.559] kernel BUG at fs/btrfs/block-group.c:4299!
[589.560] invalid opcode: 0000 [#1] PREEMPT SMP PTI
[589.560] CPU: 8 PID: 2819134 Comm: umount Tainted: G W 6.4.0-rc6-btrfs-next-134+ #1
[589.560] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014
[589.560] RIP: 0010:btrfs_free_block_groups+0x449/0x4a0 [btrfs]
[589.561] Code: 68 62 da c0 (...)
[589.561] RSP: 0018:ffffa55a8c3b3d98 EFLAGS: 00010246
[589.561] RAX: 0000000000000058 RBX: ffff8f030d7f2000 RCX: 0000000000000000
[589.562] RDX: 0000000000000000 RSI: ffffffff953f0878 RDI: 00000000ffffffff
[589.562] RBP: ffff8f030d7f2088 R08: 0000000000000000 R09: ffffa55a8c3b3c50
[589.562] R10: 0000000000000001 R11: 0000000000000001 R12: ffff8f05850b4c00
[589.562] R13: ffff8f030d7f2090 R14: ffff8f05850b4cd8 R15: dead000000000100
[589.563] FS: 00007f497fd2e840(0000) GS:ffff8f09dfc00000(0000) knlGS:0000000000000000
[589.563] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[589.563] CR2: 00007f497ff8ec10 CR3: 0000000271472006 CR4: 0000000000370ee0
[589.563] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[589.564] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[589.564] Call Trace:
[589.564] <TASK>
[589.565] ? __die_body+0x1b/0x60
[589.565] ? die+0x39/0x60
[589.565] ? do_trap+0xeb/0x110
[589.565] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs]
[589.566] ? do_error_trap+0x6a/0x90
[589.566] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs]
[589.566] ? exc_invalid_op+0x4e/0x70
[589.566] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs]
[589.567] ? asm_exc_invalid_op+0x16/0x20
[589.567] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs]
[589.567] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs]
[589.567] close_ctree+0x35d/0x560 [btrfs]
[589.568] ? fsnotify_sb_delete+0x13e/0x1d0
[589.568] ? dispose_list+0x3a/0x50
[589.568] ? evict_inodes+0x151/0x1a0
[589.568] generic_shutdown_super+0x73/0x1a0
[589.569] kill_anon_super+0x14/0x30
[589.569] btrfs_kill_super+0x12/0x20 [btrfs]
[589.569] deactivate_locked
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
sctp: handle the error returned from sctp_auth_asoc_init_active_key
When it returns an error from sctp_auth_asoc_init_active_key(), the
active_key is actually not updated. The old sh_key will be freeed
while it's still used as active key in asoc. Then an use-after-free
will be triggered when sending patckets, as found by syzbot:
sctp_auth_shkey_hold+0x22/0xa0 net/sctp/auth.c:112
sctp_set_owner_w net/sctp/socket.c:132 [inline]
sctp_sendmsg_to_asoc+0xbd5/0x1a20 net/sctp/socket.c:1863
sctp_sendmsg+0x1053/0x1d50 net/sctp/socket.c:2025
inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:819
sock_sendmsg_nosec net/socket.c:714 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:734
This patch is to fix it by not replacing the sh_key when it returns
errors from sctp_auth_asoc_init_active_key() in sctp_auth_set_key().
For sctp_auth_set_active_key(), old active_key_id will be set back
to asoc->active_key_id when the same thing happens. |
| In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Validate BOOT record_size
When the NTFS BOOT record_size field < 0, it represents a
shift value. However, there is no sanity check on the shift result
and the sbi->record_bits calculation through blksize_bits() assumes
the size always > 256, which could lead to NPD while mounting a
malformed NTFS image.
[ 318.675159] BUG: kernel NULL pointer dereference, address: 0000000000000158
[ 318.675682] #PF: supervisor read access in kernel mode
[ 318.675869] #PF: error_code(0x0000) - not-present page
[ 318.676246] PGD 0 P4D 0
[ 318.676502] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 318.676934] CPU: 0 PID: 259 Comm: mount Not tainted 5.19.0 #5
[ 318.677289] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 318.678136] RIP: 0010:ni_find_attr+0x2d/0x1c0
[ 318.678656] Code: 89 ca 4d 89 c7 41 56 41 55 41 54 41 89 cc 55 48 89 fd 53 48 89 d3 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 44 24 180
[ 318.679848] RSP: 0018:ffffa6c8c0297bd8 EFLAGS: 00000246
[ 318.680104] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000080
[ 318.680790] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[ 318.681679] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[ 318.682577] R10: 0000000000000000 R11: 0000000000000005 R12: 0000000000000080
[ 318.683015] R13: ffff8d5582e68400 R14: 0000000000000100 R15: 0000000000000000
[ 318.683618] FS: 00007fd9e1c81e40(0000) GS:ffff8d55fdc00000(0000) knlGS:0000000000000000
[ 318.684280] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 318.684651] CR2: 0000000000000158 CR3: 0000000002e1a000 CR4: 00000000000006f0
[ 318.685623] Call Trace:
[ 318.686607] <TASK>
[ 318.686872] ? ntfs_alloc_inode+0x1a/0x60
[ 318.687235] attr_load_runs_vcn+0x2b/0xa0
[ 318.687468] mi_read+0xbb/0x250
[ 318.687576] ntfs_iget5+0x114/0xd90
[ 318.687750] ntfs_fill_super+0x588/0x11b0
[ 318.687953] ? put_ntfs+0x130/0x130
[ 318.688065] ? snprintf+0x49/0x70
[ 318.688164] ? put_ntfs+0x130/0x130
[ 318.688256] get_tree_bdev+0x16a/0x260
[ 318.688407] vfs_get_tree+0x20/0xb0
[ 318.688519] path_mount+0x2dc/0x9b0
[ 318.688877] do_mount+0x74/0x90
[ 318.689142] __x64_sys_mount+0x89/0xd0
[ 318.689636] do_syscall_64+0x3b/0x90
[ 318.689998] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 318.690318] RIP: 0033:0x7fd9e133c48a
[ 318.690687] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008
[ 318.691357] RSP: 002b:00007ffd374406c8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5
[ 318.691632] RAX: ffffffffffffffda RBX: 0000564d0b051080 RCX: 00007fd9e133c48a
[ 318.691920] RDX: 0000564d0b051280 RSI: 0000564d0b051300 RDI: 0000564d0b0596a0
[ 318.692123] RBP: 0000000000000000 R08: 0000564d0b0512a0 R09: 0000000000000020
[ 318.692349] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000564d0b0596a0
[ 318.692673] R13: 0000564d0b051280 R14: 0000000000000000 R15: 00000000ffffffff
[ 318.693007] </TASK>
[ 318.693271] Modules linked in:
[ 318.693614] CR2: 0000000000000158
[ 318.694446] ---[ end trace 0000000000000000 ]---
[ 318.694779] RIP: 0010:ni_find_attr+0x2d/0x1c0
[ 318.694952] Code: 89 ca 4d 89 c7 41 56 41 55 41 54 41 89 cc 55 48 89 fd 53 48 89 d3 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 44 24 180
[ 318.696042] RSP: 0018:ffffa6c8c0297bd8 EFLAGS: 00000246
[ 318.696531] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000080
[ 318.698114] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[ 318.699286] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[ 318.699795] R10: 0000000000000000 R11: 0000000000000005 R12: 0000000000000080
[ 318.700236] R13: ffff8d5582e68400 R14: 0000000000000100 R15: 0000000000000000
[ 318.700973] FS: 00007fd9e1c81e40(0000) GS:ffff8d55fdc00000(0000) knlGS:0000000000000000
[
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
media: hi846: fix usage of pm_runtime_get_if_in_use()
pm_runtime_get_if_in_use() does not only return nonzero values when
the device is in use, it can return a negative errno too.
And especially during resuming from system suspend, when runtime pm
is not yet up again, -EAGAIN is being returned, so the subsequent
pm_runtime_put() call results in a refcount underflow.
Fix system-resume by handling -EAGAIN of pm_runtime_get_if_in_use(). |
| In the Linux kernel, the following vulnerability has been resolved:
memory: of: Fix refcount leak bug in of_get_ddr_timings()
We should add the of_node_put() when breaking out of
for_each_child_of_node() as it will automatically increase
and decrease the refcount. |
