| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: bpf_sk_storage: Fix invalid wait context lockdep report
'./test_progs -t test_local_storage' reported a splat:
[ 27.137569] =============================
[ 27.138122] [ BUG: Invalid wait context ]
[ 27.138650] 6.5.0-03980-gd11ae1b16b0a #247 Tainted: G O
[ 27.139542] -----------------------------
[ 27.140106] test_progs/1729 is trying to lock:
[ 27.140713] ffff8883ef047b88 (stock_lock){-.-.}-{3:3}, at: local_lock_acquire+0x9/0x130
[ 27.141834] other info that might help us debug this:
[ 27.142437] context-{5:5}
[ 27.142856] 2 locks held by test_progs/1729:
[ 27.143352] #0: ffffffff84bcd9c0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire+0x4/0x40
[ 27.144492] #1: ffff888107deb2c0 (&storage->lock){..-.}-{2:2}, at: bpf_local_storage_update+0x39e/0x8e0
[ 27.145855] stack backtrace:
[ 27.146274] CPU: 0 PID: 1729 Comm: test_progs Tainted: G O 6.5.0-03980-gd11ae1b16b0a #247
[ 27.147550] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 27.149127] Call Trace:
[ 27.149490] <TASK>
[ 27.149867] dump_stack_lvl+0x130/0x1d0
[ 27.152609] dump_stack+0x14/0x20
[ 27.153131] __lock_acquire+0x1657/0x2220
[ 27.153677] lock_acquire+0x1b8/0x510
[ 27.157908] local_lock_acquire+0x29/0x130
[ 27.159048] obj_cgroup_charge+0xf4/0x3c0
[ 27.160794] slab_pre_alloc_hook+0x28e/0x2b0
[ 27.161931] __kmem_cache_alloc_node+0x51/0x210
[ 27.163557] __kmalloc+0xaa/0x210
[ 27.164593] bpf_map_kzalloc+0xbc/0x170
[ 27.165147] bpf_selem_alloc+0x130/0x510
[ 27.166295] bpf_local_storage_update+0x5aa/0x8e0
[ 27.167042] bpf_fd_sk_storage_update_elem+0xdb/0x1a0
[ 27.169199] bpf_map_update_value+0x415/0x4f0
[ 27.169871] map_update_elem+0x413/0x550
[ 27.170330] __sys_bpf+0x5e9/0x640
[ 27.174065] __x64_sys_bpf+0x80/0x90
[ 27.174568] do_syscall_64+0x48/0xa0
[ 27.175201] entry_SYSCALL_64_after_hwframe+0x6e/0xd8
[ 27.175932] RIP: 0033:0x7effb40e41ad
[ 27.176357] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d8
[ 27.179028] RSP: 002b:00007ffe64c21fc8 EFLAGS: 00000202 ORIG_RAX: 0000000000000141
[ 27.180088] RAX: ffffffffffffffda RBX: 00007ffe64c22768 RCX: 00007effb40e41ad
[ 27.181082] RDX: 0000000000000020 RSI: 00007ffe64c22008 RDI: 0000000000000002
[ 27.182030] RBP: 00007ffe64c21ff0 R08: 0000000000000000 R09: 00007ffe64c22788
[ 27.183038] R10: 0000000000000064 R11: 0000000000000202 R12: 0000000000000000
[ 27.184006] R13: 00007ffe64c22788 R14: 00007effb42a1000 R15: 0000000000000000
[ 27.184958] </TASK>
It complains about acquiring a local_lock while holding a raw_spin_lock.
It means it should not allocate memory while holding a raw_spin_lock
since it is not safe for RT.
raw_spin_lock is needed because bpf_local_storage supports tracing
context. In particular for task local storage, it is easy to
get a "current" task PTR_TO_BTF_ID in tracing bpf prog.
However, task (and cgroup) local storage has already been moved to
bpf mem allocator which can be used after raw_spin_lock.
The splat is for the sk storage. For sk (and inode) storage,
it has not been moved to bpf mem allocator. Using raw_spin_lock or not,
kzalloc(GFP_ATOMIC) could theoretically be unsafe in tracing context.
However, the local storage helper requires a verifier accepted
sk pointer (PTR_TO_BTF_ID), it is hypothetical if that (mean running
a bpf prog in a kzalloc unsafe context and also able to hold a verifier
accepted sk pointer) could happen.
This patch avoids kzalloc after raw_spin_lock to silent the splat.
There is an existing kzalloc before the raw_spin_lock. At that point,
a kzalloc is very likely required because a lookup has just been done
before. Thus, this patch always does the kzalloc before acq
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
s390/idle: mark arch_cpu_idle() noinstr
linux-next commit ("cpuidle: tracing: Warn about !rcu_is_watching()")
adds a new warning which hits on s390's arch_cpu_idle() function:
RCU not on for: arch_cpu_idle+0x0/0x28
WARNING: CPU: 2 PID: 0 at include/linux/trace_recursion.h:162 arch_ftrace_ops_list_func+0x24c/0x258
Modules linked in:
CPU: 2 PID: 0 Comm: swapper/2 Not tainted 6.2.0-rc6-next-20230202 #4
Hardware name: IBM 8561 T01 703 (z/VM 7.3.0)
Krnl PSW : 0404d00180000000 00000000002b55c0 (arch_ftrace_ops_list_func+0x250/0x258)
R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3
Krnl GPRS: c0000000ffffbfff 0000000080000002 0000000000000026 0000000000000000
0000037ffffe3a28 0000037ffffe3a20 0000000000000000 0000000000000000
0000000000000000 0000000000f4acf6 00000000001044f0 0000037ffffe3cb0
0000000000000000 0000000000000000 00000000002b55bc 0000037ffffe3bb8
Krnl Code: 00000000002b55b0: c02000840051 larl %r2,0000000001335652
00000000002b55b6: c0e5fff512d1 brasl %r14,0000000000157b58
#00000000002b55bc: af000000 mc 0,0
>00000000002b55c0: a7f4ffe7 brc 15,00000000002b558e
00000000002b55c4: 0707 bcr 0,%r7
00000000002b55c6: 0707 bcr 0,%r7
00000000002b55c8: eb6ff0480024 stmg %r6,%r15,72(%r15)
00000000002b55ce: b90400ef lgr %r14,%r15
Call Trace:
[<00000000002b55c0>] arch_ftrace_ops_list_func+0x250/0x258
([<00000000002b55bc>] arch_ftrace_ops_list_func+0x24c/0x258)
[<0000000000f5f0fc>] ftrace_common+0x1c/0x20
[<00000000001044f6>] arch_cpu_idle+0x6/0x28
[<0000000000f4acf6>] default_idle_call+0x76/0x128
[<00000000001cc374>] do_idle+0xf4/0x1b0
[<00000000001cc6ce>] cpu_startup_entry+0x36/0x40
[<0000000000119d00>] smp_start_secondary+0x140/0x150
[<0000000000f5d2ae>] restart_int_handler+0x6e/0x90
Mark arch_cpu_idle() noinstr like all other architectures with
CONFIG_ARCH_WANTS_NO_INSTR (should) have it to fix this. |
| In the Linux kernel, the following vulnerability has been resolved:
ext4: correct grp validation in ext4_mb_good_group
Group corruption check will access memory of grp and will trigger kernel
crash if grp is NULL. So do NULL check before corruption check. |
| In the Linux kernel, the following vulnerability has been resolved:
mm: hugetlb: avoid soft lockup when mprotect to large memory area
When calling mprotect() to a large hugetlb memory area in our customer's
workload (~300GB hugetlb memory), soft lockup was observed:
watchdog: BUG: soft lockup - CPU#98 stuck for 23s! [t2_new_sysv:126916]
CPU: 98 PID: 126916 Comm: t2_new_sysv Kdump: loaded Not tainted 6.17-rc7
Hardware name: GIGACOMPUTING R2A3-T40-AAV1/Jefferson CIO, BIOS 5.4.4.1 07/15/2025
pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : mte_clear_page_tags+0x14/0x24
lr : mte_sync_tags+0x1c0/0x240
sp : ffff80003150bb80
x29: ffff80003150bb80 x28: ffff00739e9705a8 x27: 0000ffd2d6a00000
x26: 0000ff8e4bc00000 x25: 00e80046cde00f45 x24: 0000000000022458
x23: 0000000000000000 x22: 0000000000000004 x21: 000000011b380000
x20: ffff000000000000 x19: 000000011b379f40 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc875e0aa5e2c
x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
x5 : fffffc01ce7a5c00 x4 : 00000000046cde00 x3 : fffffc0000000000
x2 : 0000000000000004 x1 : 0000000000000040 x0 : ffff0046cde7c000
Call trace:
mte_clear_page_tags+0x14/0x24
set_huge_pte_at+0x25c/0x280
hugetlb_change_protection+0x220/0x430
change_protection+0x5c/0x8c
mprotect_fixup+0x10c/0x294
do_mprotect_pkey.constprop.0+0x2e0/0x3d4
__arm64_sys_mprotect+0x24/0x44
invoke_syscall+0x50/0x160
el0_svc_common+0x48/0x144
do_el0_svc+0x30/0xe0
el0_svc+0x30/0xf0
el0t_64_sync_handler+0xc4/0x148
el0t_64_sync+0x1a4/0x1a8
Soft lockup is not triggered with THP or base page because there is
cond_resched() called for each PMD size.
Although the soft lockup was triggered by MTE, it should be not MTE
specific. The other processing which takes long time in the loop may
trigger soft lockup too.
So add cond_resched() for hugetlb to avoid soft lockup. |
| In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix KMSAN uninit-value issue in hfsplus_delete_cat()
The syzbot reported issue in hfsplus_delete_cat():
[ 70.682285][ T9333] =====================================================
[ 70.682943][ T9333] BUG: KMSAN: uninit-value in hfsplus_subfolders_dec+0x1d7/0x220
[ 70.683640][ T9333] hfsplus_subfolders_dec+0x1d7/0x220
[ 70.684141][ T9333] hfsplus_delete_cat+0x105d/0x12b0
[ 70.684621][ T9333] hfsplus_rmdir+0x13d/0x310
[ 70.685048][ T9333] vfs_rmdir+0x5ba/0x810
[ 70.685447][ T9333] do_rmdir+0x964/0xea0
[ 70.685833][ T9333] __x64_sys_rmdir+0x71/0xb0
[ 70.686260][ T9333] x64_sys_call+0xcd8/0x3cf0
[ 70.686695][ T9333] do_syscall_64+0xd9/0x1d0
[ 70.687119][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 70.687646][ T9333]
[ 70.687856][ T9333] Uninit was stored to memory at:
[ 70.688311][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0
[ 70.688779][ T9333] hfsplus_create_cat+0x148e/0x1800
[ 70.689231][ T9333] hfsplus_mknod+0x27f/0x600
[ 70.689730][ T9333] hfsplus_mkdir+0x5a/0x70
[ 70.690146][ T9333] vfs_mkdir+0x483/0x7a0
[ 70.690545][ T9333] do_mkdirat+0x3f2/0xd30
[ 70.690944][ T9333] __x64_sys_mkdir+0x9a/0xf0
[ 70.691380][ T9333] x64_sys_call+0x2f89/0x3cf0
[ 70.691816][ T9333] do_syscall_64+0xd9/0x1d0
[ 70.692229][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 70.692773][ T9333]
[ 70.692990][ T9333] Uninit was stored to memory at:
[ 70.693469][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0
[ 70.693960][ T9333] hfsplus_create_cat+0x148e/0x1800
[ 70.694438][ T9333] hfsplus_fill_super+0x21c1/0x2700
[ 70.694911][ T9333] mount_bdev+0x37b/0x530
[ 70.695320][ T9333] hfsplus_mount+0x4d/0x60
[ 70.695729][ T9333] legacy_get_tree+0x113/0x2c0
[ 70.696167][ T9333] vfs_get_tree+0xb3/0x5c0
[ 70.696588][ T9333] do_new_mount+0x73e/0x1630
[ 70.697013][ T9333] path_mount+0x6e3/0x1eb0
[ 70.697425][ T9333] __se_sys_mount+0x733/0x830
[ 70.697857][ T9333] __x64_sys_mount+0xe4/0x150
[ 70.698269][ T9333] x64_sys_call+0x2691/0x3cf0
[ 70.698704][ T9333] do_syscall_64+0xd9/0x1d0
[ 70.699117][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 70.699730][ T9333]
[ 70.699946][ T9333] Uninit was created at:
[ 70.700378][ T9333] __alloc_pages_noprof+0x714/0xe60
[ 70.700843][ T9333] alloc_pages_mpol_noprof+0x2a2/0x9b0
[ 70.701331][ T9333] alloc_pages_noprof+0xf8/0x1f0
[ 70.701774][ T9333] allocate_slab+0x30e/0x1390
[ 70.702194][ T9333] ___slab_alloc+0x1049/0x33a0
[ 70.702635][ T9333] kmem_cache_alloc_lru_noprof+0x5ce/0xb20
[ 70.703153][ T9333] hfsplus_alloc_inode+0x5a/0xd0
[ 70.703598][ T9333] alloc_inode+0x82/0x490
[ 70.703984][ T9333] iget_locked+0x22e/0x1320
[ 70.704428][ T9333] hfsplus_iget+0x5c/0xba0
[ 70.704827][ T9333] hfsplus_btree_open+0x135/0x1dd0
[ 70.705291][ T9333] hfsplus_fill_super+0x1132/0x2700
[ 70.705776][ T9333] mount_bdev+0x37b/0x530
[ 70.706171][ T9333] hfsplus_mount+0x4d/0x60
[ 70.706579][ T9333] legacy_get_tree+0x113/0x2c0
[ 70.707019][ T9333] vfs_get_tree+0xb3/0x5c0
[ 70.707444][ T9333] do_new_mount+0x73e/0x1630
[ 70.707865][ T9333] path_mount+0x6e3/0x1eb0
[ 70.708270][ T9333] __se_sys_mount+0x733/0x830
[ 70.708711][ T9333] __x64_sys_mount+0xe4/0x150
[ 70.709158][ T9333] x64_sys_call+0x2691/0x3cf0
[ 70.709630][ T9333] do_syscall_64+0xd9/0x1d0
[ 70.710053][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 70.710611][ T9333]
[ 70.710842][ T9333] CPU: 3 UID: 0 PID: 9333 Comm: repro Not tainted 6.12.0-rc6-dirty #17
[ 70.711568][ T9333] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 70.712490][ T9333] =====================================================
[ 70.713085][ T9333] Disabling lock debugging due to kernel taint
[ 70.713618][ T9333] Kernel panic - not syncing: kmsan.panic set ...
[ 70.714159][ T9333]
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: fix memory leak in hns_roce_alloc_mr()
When hns_roce_mr_enable() failed in hns_roce_alloc_mr(), mr_key is not
released. Compiled test only. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/mxsfb: Disable overlay plane in mxsfb_plane_overlay_atomic_disable()
When disabling overlay plane in mxsfb_plane_overlay_atomic_update(),
overlay plane's framebuffer pointer is NULL. So, dereferencing it would
cause a kernel Oops(NULL pointer dereferencing). Fix the issue by
disabling overlay plane in mxsfb_plane_overlay_atomic_disable() instead. |
| In the Linux kernel, the following vulnerability has been resolved:
media: dvb-usb-v2: gl861: Fix null-ptr-deref in gl861_i2c_master_xfer
In gl861_i2c_master_xfer, msg is controlled by user. When msg[i].buf
is null and msg[i].len is zero, former checks on msg[i].buf would be
passed. Malicious data finally reach gl861_i2c_master_xfer. If accessing
msg[i].buf[0] without sanity check, null ptr deref would happen.
We add check on msg[i].len to prevent crash.
Similar commit:
commit 0ed554fd769a
("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()") |
| Insufficient control flow management in the Linux kernel-mode driver for some Intel(R) 700 Series Ethernet before version 2.28.5 may allow an authenticated user to potentially enable escalation of privilege via local access. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_conn: return ERR_PTR instead of NULL when there is no link
hci_connect_sco currently returns NULL when there is no link (i.e. when
hci_conn_link() returns NULL).
sco_connect() expects an ERR_PTR in case of any error (see line 266 in
sco.c). Thus, hcon set as NULL passes through to sco_conn_add(), which
tries to get hcon->hdev, resulting in dereferencing a NULL pointer as
reported by syzkaller.
The same issue exists for iso_connect_cis() calling hci_connect_cis().
Thus, make hci_connect_sco() and hci_connect_cis() return ERR_PTR
instead of NULL. |
| In the Linux kernel, the following vulnerability has been resolved:
iio: core: Prevent invalid memory access when there is no parent
Commit 813665564b3d ("iio: core: Convert to use firmware node handle
instead of OF node") switched the kind of nodes to use for label
retrieval in device registration. Probably an unwanted change in that
commit was that if the device has no parent then NULL pointer is
accessed. This is what happens in the stock IIO dummy driver when a
new entry is created in configfs:
# mkdir /sys/kernel/config/iio/devices/dummy/foo
BUG: kernel NULL pointer dereference, address: ...
...
Call Trace:
__iio_device_register
iio_dummy_probe
Since there seems to be no reason to make a parent device of an IIO
dummy device mandatory, let’s prevent the invalid memory access in
__iio_device_register when the parent device is NULL. With this
change, the IIO dummy driver works fine with configfs. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: ocb: don't leave if not joined
If there's no OCB state, don't ask the driver/mac80211 to
leave, since that's just confusing. Since set/clear the
chandef state, that's a simple check. |
| In the Linux kernel before 4.8, usb_parse_endpoint in drivers/usb/core/config.c does not validate the wMaxPacketSize field of an endpoint descriptor. NOTE: This vulnerability only affects products that are no longer supported by the supplier. |
| In the Linux kernel, the following vulnerability has been resolved:
PCI: Free released resource after coalescing
release_resource() doesn't actually free the resource or resource list
entry so free the resource list entry to avoid a leak. |
| In the Linux kernel, the following vulnerability has been resolved:
FS: JFS: Check for read-only mounted filesystem in txBegin
This patch adds a check for read-only mounted filesystem
in txBegin before starting a transaction potentially saving
from NULL pointer deref. |
| In the Linux kernel, the following vulnerability has been resolved:
erofs: kill hooked chains to avoid loops on deduplicated compressed images
After heavily stressing EROFS with several images which include a
hand-crafted image of repeated patterns for more than 46 days, I found
two chains could be linked with each other almost simultaneously and
form a loop so that the entire loop won't be submitted. As a
consequence, the corresponding file pages will remain locked forever.
It can be _only_ observed on data-deduplicated compressed images.
For example, consider two chains with five pclusters in total:
Chain 1: 2->3->4->5 -- The tail pcluster is 5;
Chain 2: 5->1->2 -- The tail pcluster is 2.
Chain 2 could link to Chain 1 with pcluster 5; and Chain 1 could link
to Chain 2 at the same time with pcluster 2.
Since hooked chains are all linked locklessly now, I have no idea how
to simply avoid the race. Instead, let's avoid hooked chains completely
until I could work out a proper way to fix this and end users finally
tell us that it's needed to add it back.
Actually, this optimization can be found with multi-threaded workloads
(especially even more often on deduplicated compressed images), yet I'm
not sure about the overall system impacts of not having this compared
with implementation complexity. |
| In the Linux kernel, the following vulnerability has been resolved:
regulator: da9063: fix null pointer deref with partial DT config
When some of the da9063 regulators do not have corresponding DT nodes
a null pointer dereference occurs on boot because such regulators have
no init_data causing the pointers calculated in
da9063_check_xvp_constraints() to be invalid.
Do not dereference them in this case. |
| In the Linux kernel, the following vulnerability has been resolved:
md: fix warning for holder mismatch from export_rdev()
Commit a1d767191096 ("md: use mddev->external to select holder in
export_rdev()") fix the problem that 'claim_rdev' is used for
blkdev_get_by_dev() while 'rdev' is used for blkdev_put().
However, if mddev->external is changed from 0 to 1, then 'rdev' is used
for blkdev_get_by_dev() while 'claim_rdev' is used for blkdev_put(). And
this problem can be reporduced reliably by following:
New file: mdadm/tests/23rdev-lifetime
devname=${dev0##*/}
devt=`cat /sys/block/$devname/dev`
pid=""
runtime=2
clean_up_test() {
pill -9 $pid
echo clear > /sys/block/md0/md/array_state
}
trap 'clean_up_test' EXIT
add_by_sysfs() {
while true; do
echo $devt > /sys/block/md0/md/new_dev
done
}
remove_by_sysfs(){
while true; do
echo remove > /sys/block/md0/md/dev-${devname}/state
done
}
echo md0 > /sys/module/md_mod/parameters/new_array || die "create md0 failed"
add_by_sysfs &
pid="$pid $!"
remove_by_sysfs &
pid="$pid $!"
sleep $runtime
exit 0
Test cmd:
./test --save-logs --logdir=/tmp/ --keep-going --dev=loop --tests=23rdev-lifetime
Test result:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 960 at block/bdev.c:618 blkdev_put+0x27c/0x330
Modules linked in: multipath md_mod loop
CPU: 0 PID: 960 Comm: test Not tainted 6.5.0-rc2-00121-g01e55c376936-dirty #50
RIP: 0010:blkdev_put+0x27c/0x330
Call Trace:
<TASK>
export_rdev.isra.23+0x50/0xa0 [md_mod]
mddev_unlock+0x19d/0x300 [md_mod]
rdev_attr_store+0xec/0x190 [md_mod]
sysfs_kf_write+0x52/0x70
kernfs_fop_write_iter+0x19a/0x2a0
vfs_write+0x3b5/0x770
ksys_write+0x74/0x150
__x64_sys_write+0x22/0x30
do_syscall_64+0x40/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Fix the problem by recording if 'rdev' is used as holder. |
| In the Linux kernel, the following vulnerability has been resolved:
of: overlay: Call of_changeset_init() early
When of_overlay_fdt_apply() fails, the changeset may be partially
applied, and the caller is still expected to call of_overlay_remove() to
clean up this partial state.
However, of_overlay_apply() calls of_resolve_phandles() before
init_overlay_changeset(). Hence if the overlay fails to apply due to an
unresolved symbol, the overlay_changeset.cset.entries list is still
uninitialized, and cleanup will crash with a NULL-pointer dereference in
overlay_removal_is_ok().
Fix this by moving the call to of_changeset_init() from
init_overlay_changeset() to of_overlay_fdt_apply(), where all other
early initialization is done. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/msm: fix workqueue leak on bind errors
Make sure to destroy the workqueue also in case of early errors during
bind (e.g. a subcomponent failing to bind).
Since commit c3b790ea07a1 ("drm: Manage drm_mode_config_init with
drmm_") the mode config will be freed when the drm device is released
also when using the legacy interface, but add an explicit cleanup for
consistency and to facilitate backporting.
Patchwork: https://patchwork.freedesktop.org/patch/525093/ |
