| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: fix sleeping-in-atomic in ath11k_mac_op_set_bitrate_mask()
ath11k_mac_disable_peer_fixed_rate() is passed as the iterator to
ieee80211_iterate_stations_atomic(). Note in this case the iterator is
required to be atomic, however ath11k_mac_disable_peer_fixed_rate() does
not follow it as it might sleep. Consequently below warning is seen:
BUG: sleeping function called from invalid context at wmi.c:304
Call Trace:
<TASK>
dump_stack_lvl
__might_resched.cold
ath11k_wmi_cmd_send
ath11k_wmi_set_peer_param
ath11k_mac_disable_peer_fixed_rate
ieee80211_iterate_stations_atomic
ath11k_mac_op_set_bitrate_mask.cold
Change to ieee80211_iterate_stations_mtx() to fix this issue.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 |
| In the Linux kernel, the following vulnerability has been resolved:
team: replace team lock with rtnl lock
syszbot reports various ordering issues for lower instance locks and
team lock. Switch to using rtnl lock for protecting team device,
similar to bonding. Based on the patch by Tetsuo Handa. |
| Use-after-free vulnerability in the AppendElements function in Mozilla Firefox before 37.0, Firefox ESR 31.x before 31.6, and Thunderbird before 31.6 on Linux, when the Fluendo MP3 plugin for GStreamer is used, allows remote attackers to execute arbitrary code or cause a denial of service (heap memory corruption) via a crafted MP3 file. |
| The bufferdata function in WebGL is vulnerable to a buffer overflow with specific graphics drivers on Linux. This could result in malicious content freezing a tab or triggering a potentially exploitable crash. *Note: this issue only occurs on Linux. Other operating systems are unaffected.*. This vulnerability affects Thunderbird < 60.7, Firefox < 67, and Firefox ESR < 60.7. |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/arm-smmu-qcom: Add SM6115 MDSS compatible
Add the SM6115 MDSS compatible to clients compatible list, as it also
needs that workaround.
Without this workaround, for example, QRB4210 RB2 which is based on
SM4250/SM6115 generates a lot of smmu unhandled context faults during
boot:
arm_smmu_context_fault: 116854 callbacks suppressed
arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402,
iova=0x5c0ec600, fsynr=0x320021, cbfrsynra=0x420, cb=5
arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420
arm-smmu c600000.iommu: FSYNR0 = 00320021 [S1CBNDX=50 PNU PLVL=1]
arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402,
iova=0x5c0d7800, fsynr=0x320021, cbfrsynra=0x420, cb=5
arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420
and also failed initialisation of lontium lt9611uxc, gpu and dpu is
observed:
(binding MDSS components triggered by lt9611uxc have failed)
------------[ cut here ]------------
!aspace
WARNING: CPU: 6 PID: 324 at drivers/gpu/drm/msm/msm_gem_vma.c:130 msm_gem_vma_init+0x150/0x18c [msm]
Modules linked in: ... (long list of modules)
CPU: 6 UID: 0 PID: 324 Comm: (udev-worker) Not tainted 6.15.0-03037-gaacc73ceeb8b #4 PREEMPT
Hardware name: Qualcomm Technologies, Inc. QRB4210 RB2 (DT)
pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : msm_gem_vma_init+0x150/0x18c [msm]
lr : msm_gem_vma_init+0x150/0x18c [msm]
sp : ffff80008144b280
...
Call trace:
msm_gem_vma_init+0x150/0x18c [msm] (P)
get_vma_locked+0xc0/0x194 [msm]
msm_gem_get_and_pin_iova_range+0x4c/0xdc [msm]
msm_gem_kernel_new+0x48/0x160 [msm]
msm_gpu_init+0x34c/0x53c [msm]
adreno_gpu_init+0x1b0/0x2d8 [msm]
a6xx_gpu_init+0x1e8/0x9e0 [msm]
adreno_bind+0x2b8/0x348 [msm]
component_bind_all+0x100/0x230
msm_drm_bind+0x13c/0x3d0 [msm]
try_to_bring_up_aggregate_device+0x164/0x1d0
__component_add+0xa4/0x174
component_add+0x14/0x20
dsi_dev_attach+0x20/0x34 [msm]
dsi_host_attach+0x58/0x98 [msm]
devm_mipi_dsi_attach+0x34/0x90
lt9611uxc_attach_dsi.isra.0+0x94/0x124 [lontium_lt9611uxc]
lt9611uxc_probe+0x540/0x5fc [lontium_lt9611uxc]
i2c_device_probe+0x148/0x2a8
really_probe+0xbc/0x2c0
__driver_probe_device+0x78/0x120
driver_probe_device+0x3c/0x154
__driver_attach+0x90/0x1a0
bus_for_each_dev+0x68/0xb8
driver_attach+0x24/0x30
bus_add_driver+0xe4/0x208
driver_register+0x68/0x124
i2c_register_driver+0x48/0xcc
lt9611uxc_driver_init+0x20/0x1000 [lontium_lt9611uxc]
do_one_initcall+0x60/0x1d4
do_init_module+0x54/0x1fc
load_module+0x1748/0x1c8c
init_module_from_file+0x74/0xa0
__arm64_sys_finit_module+0x130/0x2f8
invoke_syscall+0x48/0x104
el0_svc_common.constprop.0+0xc0/0xe0
do_el0_svc+0x1c/0x28
el0_svc+0x2c/0x80
el0t_64_sync_handler+0x10c/0x138
el0t_64_sync+0x198/0x19c
---[ end trace 0000000000000000 ]---
msm_dpu 5e01000.display-controller: [drm:msm_gpu_init [msm]] *ERROR* could not allocate memptrs: -22
msm_dpu 5e01000.display-controller: failed to load adreno gpu
platform a400000.remoteproc:glink-edge:apr:service@7:dais: Adding to iommu group 19
msm_dpu 5e01000.display-controller: failed to bind 5900000.gpu (ops a3xx_ops [msm]): -22
msm_dpu 5e01000.display-controller: adev bind failed: -22
lt9611uxc 0-002b: failed to attach dsi to host
lt9611uxc 0-002b: probe with driver lt9611uxc failed with error -22 |
| In the Linux kernel, the following vulnerability has been resolved:
open_tree_attr: do not allow id-mapping changes without OPEN_TREE_CLONE
As described in commit 7a54947e727b ('Merge patch series "fs: allow
changing idmappings"'), open_tree_attr(2) was necessary in order to
allow for a detached mount to be created and have its idmappings changed
without the risk of any racing threads operating on it. For this reason,
mount_setattr(2) still does not allow for id-mappings to be changed.
However, there was a bug in commit 2462651ffa76 ("fs: allow changing
idmappings") which allowed users to bypass this restriction by calling
open_tree_attr(2) *without* OPEN_TREE_CLONE.
can_idmap_mount() prevented this bug from allowing an attached
mountpoint's id-mapping from being modified (thanks to an is_anon_ns()
check), but this still allows for detached (but visible) mounts to have
their be id-mapping changed. This risks the same UAF and locking issues
as described in the merge commit, and was likely unintentional. |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix refcount leak causing resource not released
When ksmbd_conn_releasing(opinfo->conn) returns true,the refcount was not
decremented properly, causing a refcount leak that prevents the count from
reaching zero and the memory from being released. |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: qat - flush misc workqueue during device shutdown
Repeated loading and unloading of a device specific QAT driver, for
example qat_4xxx, in a tight loop can lead to a crash due to a
use-after-free scenario. This occurs when a power management (PM)
interrupt triggers just before the device-specific driver (e.g.,
qat_4xxx.ko) is unloaded, while the core driver (intel_qat.ko) remains
loaded.
Since the driver uses a shared workqueue (`qat_misc_wq`) across all
devices and owned by intel_qat.ko, a deferred routine from the
device-specific driver may still be pending in the queue. If this
routine executes after the driver is unloaded, it can dereference freed
memory, resulting in a page fault and kernel crash like the following:
BUG: unable to handle page fault for address: ffa000002e50a01c
#PF: supervisor read access in kernel mode
RIP: 0010:pm_bh_handler+0x1d2/0x250 [intel_qat]
Call Trace:
pm_bh_handler+0x1d2/0x250 [intel_qat]
process_one_work+0x171/0x340
worker_thread+0x277/0x3a0
kthread+0xf0/0x120
ret_from_fork+0x2d/0x50
To prevent this, flush the misc workqueue during device shutdown to
ensure that all pending work items are completed before the driver is
unloaded.
Note: This approach may slightly increase shutdown latency if the
workqueue contains jobs from other devices, but it ensures correctness
and stability. |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: caam - Prevent crash on suspend with iMX8QM / iMX8ULP
Since the CAAM on these SoCs is managed by another ARM core, called the
SECO (Security Controller) on iMX8QM and Secure Enclave on iMX8ULP, which
also reserves access to register page 0 suspend operations cannot touch
this page.
This is similar to when running OPTEE, where OPTEE will reserve page 0.
Track this situation using a new state variable no_page0, reflecting if
page 0 is reserved elsewhere, either by other management cores in SoC or
by OPTEE.
Replace the optee_en check in suspend/resume with the new check.
optee_en cannot go away as it's needed elsewhere to gate OPTEE specific
situations.
Fixes the following splat at suspend:
Internal error: synchronous external abort: 0000000096000010 [#1] SMP
Hardware name: Freescale i.MX8QXP ACU6C (DT)
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : readl+0x0/0x18
lr : rd_reg32+0x18/0x3c
sp : ffffffc08192ba20
x29: ffffffc08192ba20 x28: ffffff8025190000 x27: 0000000000000000
x26: ffffffc0808ae808 x25: ffffffc080922338 x24: ffffff8020e89090
x23: 0000000000000000 x22: ffffffc080922000 x21: ffffff8020e89010
x20: ffffffc080387ef8 x19: ffffff8020e89010 x18: 000000005d8000d5
x17: 0000000030f35963 x16: 000000008f785f3f x15: 000000003b8ef57c
x14: 00000000c418aef8 x13: 00000000f5fea526 x12: 0000000000000001
x11: 0000000000000002 x10: 0000000000000001 x9 : 0000000000000000
x8 : ffffff8025190870 x7 : ffffff8021726880 x6 : 0000000000000002
x5 : ffffff80217268f0 x4 : ffffff8021726880 x3 : ffffffc081200000
x2 : 0000000000000001 x1 : ffffff8020e89010 x0 : ffffffc081200004
Call trace:
readl+0x0/0x18
caam_ctrl_suspend+0x30/0xdc
dpm_run_callback.constprop.0+0x24/0x5c
device_suspend+0x170/0x2e8
dpm_suspend+0xa0/0x104
dpm_suspend_start+0x48/0x50
suspend_devices_and_enter+0x7c/0x45c
pm_suspend+0x148/0x160
state_store+0xb4/0xf8
kobj_attr_store+0x14/0x24
sysfs_kf_write+0x38/0x48
kernfs_fop_write_iter+0xb4/0x178
vfs_write+0x118/0x178
ksys_write+0x6c/0xd0
__arm64_sys_write+0x14/0x1c
invoke_syscall.constprop.0+0x64/0xb0
do_el0_svc+0x90/0xb0
el0_svc+0x18/0x44
el0t_64_sync_handler+0x88/0x124
el0t_64_sync+0x150/0x154
Code: 88dffc21 88dffc21 5ac00800 d65f03c0 (b9400000) |
| PrivateBin is an online pastebin where the server has zero knowledge of pasted data. Starting in version 1.7.7 and prior to version 2.0.3, dragging a file whose filename contains HTML is reflected verbatim into the page via the drag-and-drop helper, so any user who drops a crafted file on PrivateBin will execute arbitrary JavaScript within their own session (self-XSS). This allows an attacker who can entice a victim to drag or otherwise attach such a file to exfiltrate plaintext, encryption keys, or stored pastes before they are encrypted or sent. Certain conditions must exist for the vulnerability to be exploitable. Only macOS or Linux users are affected, due to the way the `>` character is treated in a file name on Windows. The PrivateBin instance needs to have file upload enabled. An attacker needs to have access to the local file system or somehow convince the user to create (or download) a malicious file (name). An attacker needs to convince the user to attach that malicious file to PrivateBin. Any Mac / Linux user who can be tricked into dragging a maliciously named file into the editor is impacted; code runs in the origin of the PrivateBin instance they are using. Attackers can steal plaintext, passphrases, or manipulate the UI before data is encrypted, defeating the zero-knowledge guarantees for that victim session, assuming counter-measures like Content-Security-Policy (CSP) have been disabled. If CSP is not disabled, HTML injection attacks may be possible - like redirecting to a foreign website, phishing etc. As the whole exploit needs to be included in the file name of the attached file and only affects the local session of the user (aka it is neither persistent nor remotely executable) and that user needs to interact and actively attach that file to the paste, the impact is considered to be practically low. Version 2.0.3 patches the issue. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: fix incorrect mpc_combine array size
[why]
MAX_SURFACES is per stream, while MAX_PLANES is per asic. The
mpc_combine is an array that records all the planes per asic. Therefore
MAX_PLANES should be used as the array size. Using MAX_SURFACES causes
array overflow when there are more than 3 planes.
[how]
Use the MAX_PLANES for the mpc_combine array size. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: think-lmi: Fix password opcode ordering for workstations
The Lenovo workstations require the password opcode to be run before
the attribute value is changed (if Admin password is enabled).
Tested on some Thinkpads to confirm they are OK with this order too. |
| In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_mirred: don't override retval if we already lost the skb
If we're redirecting the skb, and haven't called tcf_mirred_forward(),
yet, we need to tell the core to drop the skb by setting the retcode
to SHOT. If we have called tcf_mirred_forward(), however, the skb
is out of our hands and returning SHOT will lead to UaF.
Move the retval override to the error path which actually need it. |
| A use-after-free vulnerability in the Linux kernel's ipv4: igmp component can be exploited to achieve local privilege escalation.
A race condition can be exploited to cause a timer be mistakenly registered on a RCU read locked object which is freed by another thread.
We recommend upgrading past commit e2b706c691905fe78468c361aaabc719d0a496f1. |
| In the Linux kernel, the following vulnerability has been resolved:
mm/khugepaged: fix ->anon_vma race
If an ->anon_vma is attached to the VMA, collapse_and_free_pmd() requires
it to be locked.
Page table traversal is allowed under any one of the mmap lock, the
anon_vma lock (if the VMA is associated with an anon_vma), and the
mapping lock (if the VMA is associated with a mapping); and so to be
able to remove page tables, we must hold all three of them.
retract_page_tables() bails out if an ->anon_vma is attached, but does
this check before holding the mmap lock (as the comment above the check
explains).
If we racily merged an existing ->anon_vma (shared with a child
process) from a neighboring VMA, subsequent rmap traversals on pages
belonging to the child will be able to see the page tables that we are
concurrently removing while assuming that nothing else can access them.
Repeat the ->anon_vma check once we hold the mmap lock to ensure that
there really is no concurrent page table access.
Hitting this bug causes a lockdep warning in collapse_and_free_pmd(),
in the line "lockdep_assert_held_write(&vma->anon_vma->root->rwsem)".
It can also lead to use-after-free access. |
| In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix UAF in cifs_demultiplex_thread()
There is a UAF when xfstests on cifs:
BUG: KASAN: use-after-free in smb2_is_network_name_deleted+0x27/0x160
Read of size 4 at addr ffff88810103fc08 by task cifsd/923
CPU: 1 PID: 923 Comm: cifsd Not tainted 6.1.0-rc4+ #45
...
Call Trace:
<TASK>
dump_stack_lvl+0x34/0x44
print_report+0x171/0x472
kasan_report+0xad/0x130
kasan_check_range+0x145/0x1a0
smb2_is_network_name_deleted+0x27/0x160
cifs_demultiplex_thread.cold+0x172/0x5a4
kthread+0x165/0x1a0
ret_from_fork+0x1f/0x30
</TASK>
Allocated by task 923:
kasan_save_stack+0x1e/0x40
kasan_set_track+0x21/0x30
__kasan_slab_alloc+0x54/0x60
kmem_cache_alloc+0x147/0x320
mempool_alloc+0xe1/0x260
cifs_small_buf_get+0x24/0x60
allocate_buffers+0xa1/0x1c0
cifs_demultiplex_thread+0x199/0x10d0
kthread+0x165/0x1a0
ret_from_fork+0x1f/0x30
Freed by task 921:
kasan_save_stack+0x1e/0x40
kasan_set_track+0x21/0x30
kasan_save_free_info+0x2a/0x40
____kasan_slab_free+0x143/0x1b0
kmem_cache_free+0xe3/0x4d0
cifs_small_buf_release+0x29/0x90
SMB2_negotiate+0x8b7/0x1c60
smb2_negotiate+0x51/0x70
cifs_negotiate_protocol+0xf0/0x160
cifs_get_smb_ses+0x5fa/0x13c0
mount_get_conns+0x7a/0x750
cifs_mount+0x103/0xd00
cifs_smb3_do_mount+0x1dd/0xcb0
smb3_get_tree+0x1d5/0x300
vfs_get_tree+0x41/0xf0
path_mount+0x9b3/0xdd0
__x64_sys_mount+0x190/0x1d0
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x46/0xb0
The UAF is because:
mount(pid: 921) | cifsd(pid: 923)
-------------------------------|-------------------------------
| cifs_demultiplex_thread
SMB2_negotiate |
cifs_send_recv |
compound_send_recv |
smb_send_rqst |
wait_for_response |
wait_event_state [1] |
| standard_receive3
| cifs_handle_standard
| handle_mid
| mid->resp_buf = buf; [2]
| dequeue_mid [3]
KILL the process [4] |
resp_iov[i].iov_base = buf |
free_rsp_buf [5] |
| is_network_name_deleted [6]
| callback
1. After send request to server, wait the response until
mid->mid_state != SUBMITTED;
2. Receive response from server, and set it to mid;
3. Set the mid state to RECEIVED;
4. Kill the process, the mid state already RECEIVED, get 0;
5. Handle and release the negotiate response;
6. UAF.
It can be easily reproduce with add some delay in [3] - [6].
Only sync call has the problem since async call's callback is
executed in cifsd process.
Add an extra state to mark the mid state to READY before wakeup the
waitter, then it can get the resp safely. |
| In the Linux kernel, the following vulnerability has been resolved:
x86/srso: Add SRSO mitigation for Hygon processors
Add mitigation for the speculative return stack overflow vulnerability
which exists on Hygon processors too. |
| In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid deadlock in fs reclaim with page writeback
Ext4 has a filesystem wide lock protecting ext4_writepages() calls to
avoid races with switching of journalled data flag or inode format. This
lock can however cause a deadlock like:
CPU0 CPU1
ext4_writepages()
percpu_down_read(sbi->s_writepages_rwsem);
ext4_change_inode_journal_flag()
percpu_down_write(sbi->s_writepages_rwsem);
- blocks, all readers block from now on
ext4_do_writepages()
ext4_init_io_end()
kmem_cache_zalloc(io_end_cachep, GFP_KERNEL)
fs_reclaim frees dentry...
dentry_unlink_inode()
iput() - last ref =>
iput_final() - inode dirty =>
write_inode_now()...
ext4_writepages() tries to acquire sbi->s_writepages_rwsem
and blocks forever
Make sure we cannot recurse into filesystem reclaim from writeback code
to avoid the deadlock. |
| In the Linux kernel, the following vulnerability has been resolved:
xfrm: add NULL check in xfrm_update_ae_params
Normally, x->replay_esn and x->preplay_esn should be allocated at
xfrm_alloc_replay_state_esn(...) in xfrm_state_construct(...), hence the
xfrm_update_ae_params(...) is okay to update them. However, the current
implementation of xfrm_new_ae(...) allows a malicious user to directly
dereference a NULL pointer and crash the kernel like below.
BUG: kernel NULL pointer dereference, address: 0000000000000000
PGD 8253067 P4D 8253067 PUD 8e0e067 PMD 0
Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI
CPU: 0 PID: 98 Comm: poc.npd Not tainted 6.4.0-rc7-00072-gdad9774deaf1 #8
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.o4
RIP: 0010:memcpy_orig+0xad/0x140
Code: e8 4c 89 5f e0 48 8d 7f e0 73 d2 83 c2 20 48 29 d6 48 29 d7 83 fa 10 72 34 4c 8b 06 4c 8b 4e 08 c
RSP: 0018:ffff888008f57658 EFLAGS: 00000202
RAX: 0000000000000000 RBX: ffff888008bd0000 RCX: ffffffff8238e571
RDX: 0000000000000018 RSI: ffff888007f64844 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff888008f57818
R13: ffff888007f64aa4 R14: 0000000000000000 R15: 0000000000000000
FS: 00000000014013c0(0000) GS:ffff88806d600000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 00000000054d8000 CR4: 00000000000006f0
Call Trace:
<TASK>
? __die+0x1f/0x70
? page_fault_oops+0x1e8/0x500
? __pfx_is_prefetch.constprop.0+0x10/0x10
? __pfx_page_fault_oops+0x10/0x10
? _raw_spin_unlock_irqrestore+0x11/0x40
? fixup_exception+0x36/0x460
? _raw_spin_unlock_irqrestore+0x11/0x40
? exc_page_fault+0x5e/0xc0
? asm_exc_page_fault+0x26/0x30
? xfrm_update_ae_params+0xd1/0x260
? memcpy_orig+0xad/0x140
? __pfx__raw_spin_lock_bh+0x10/0x10
xfrm_update_ae_params+0xe7/0x260
xfrm_new_ae+0x298/0x4e0
? __pfx_xfrm_new_ae+0x10/0x10
? __pfx_xfrm_new_ae+0x10/0x10
xfrm_user_rcv_msg+0x25a/0x410
? __pfx_xfrm_user_rcv_msg+0x10/0x10
? __alloc_skb+0xcf/0x210
? stack_trace_save+0x90/0xd0
? filter_irq_stacks+0x1c/0x70
? __stack_depot_save+0x39/0x4e0
? __kasan_slab_free+0x10a/0x190
? kmem_cache_free+0x9c/0x340
? netlink_recvmsg+0x23c/0x660
? sock_recvmsg+0xeb/0xf0
? __sys_recvfrom+0x13c/0x1f0
? __x64_sys_recvfrom+0x71/0x90
? do_syscall_64+0x3f/0x90
? entry_SYSCALL_64_after_hwframe+0x72/0xdc
? copyout+0x3e/0x50
netlink_rcv_skb+0xd6/0x210
? __pfx_xfrm_user_rcv_msg+0x10/0x10
? __pfx_netlink_rcv_skb+0x10/0x10
? __pfx_sock_has_perm+0x10/0x10
? mutex_lock+0x8d/0xe0
? __pfx_mutex_lock+0x10/0x10
xfrm_netlink_rcv+0x44/0x50
netlink_unicast+0x36f/0x4c0
? __pfx_netlink_unicast+0x10/0x10
? netlink_recvmsg+0x500/0x660
netlink_sendmsg+0x3b7/0x700
This Null-ptr-deref bug is assigned CVE-2023-3772. And this commit
adds additional NULL check in xfrm_update_ae_params to fix the NPD. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/msm: Make .remove and .shutdown HW shutdown consistent
Drivers' .remove and .shutdown callbacks are executed on different code
paths. The former is called when a device is removed from the bus, while
the latter is called at system shutdown time to quiesce the device.
This means that some overlap exists between the two, because both have to
take care of properly shutting down the hardware. But currently the logic
used in these two callbacks isn't consistent in msm drivers, which could
lead to kernel panic.
For example, on .remove the component is deleted and its .unbind callback
leads to the hardware being shutdown but only if the DRM device has been
marked as registered.
That check doesn't exist in the .shutdown logic and this can lead to the
driver calling drm_atomic_helper_shutdown() for a DRM device that hasn't
been properly initialized.
A situation like this can happen if drivers for expected sub-devices fail
to probe, since the .bind callback will never be executed. If that is the
case, drm_atomic_helper_shutdown() will attempt to take mutexes that are
only initialized if drm_mode_config_init() is called during a device bind.
This bug was attempted to be fixed in commit 623f279c7781 ("drm/msm: fix
shutdown hook in case GPU components failed to bind"), but unfortunately
it still happens in some cases as the one mentioned above, i.e:
systemd-shutdown[1]: Powering off.
kvm: exiting hardware virtualization
platform wifi-firmware.0: Removing from iommu group 12
platform video-firmware.0: Removing from iommu group 10
------------[ cut here ]------------
WARNING: CPU: 6 PID: 1 at drivers/gpu/drm/drm_modeset_lock.c:317 drm_modeset_lock_all_ctx+0x3c4/0x3d0
...
Hardware name: Google CoachZ (rev3+) (DT)
pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : drm_modeset_lock_all_ctx+0x3c4/0x3d0
lr : drm_modeset_lock_all_ctx+0x48/0x3d0
sp : ffff80000805bb80
x29: ffff80000805bb80 x28: ffff327c00128000 x27: 0000000000000000
x26: 0000000000000000 x25: 0000000000000001 x24: ffffc95d820ec030
x23: ffff327c00bbd090 x22: ffffc95d8215eca0 x21: ffff327c039c5800
x20: ffff327c039c5988 x19: ffff80000805bbe8 x18: 0000000000000034
x17: 000000040044ffff x16: ffffc95d80cac920 x15: 0000000000000000
x14: 0000000000000315 x13: 0000000000000315 x12: 0000000000000000
x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
x8 : ffff80000805bc28 x7 : 0000000000000000 x6 : 0000000000000000
x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
x2 : ffff327c00128000 x1 : 0000000000000000 x0 : ffff327c039c59b0
Call trace:
drm_modeset_lock_all_ctx+0x3c4/0x3d0
drm_atomic_helper_shutdown+0x70/0x134
msm_drv_shutdown+0x30/0x40
platform_shutdown+0x28/0x40
device_shutdown+0x148/0x350
kernel_power_off+0x38/0x80
__do_sys_reboot+0x288/0x2c0
__arm64_sys_reboot+0x28/0x34
invoke_syscall+0x48/0x114
el0_svc_common.constprop.0+0x44/0xec
do_el0_svc+0x2c/0xc0
el0_svc+0x2c/0x84
el0t_64_sync_handler+0x11c/0x150
el0t_64_sync+0x18c/0x190
---[ end trace 0000000000000000 ]---
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018
Mem abort info:
ESR = 0x0000000096000004
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x04: level 0 translation fault
Data abort info:
ISV = 0, ISS = 0x00000004
CM = 0, WnR = 0
user pgtable: 4k pages, 48-bit VAs, pgdp=000000010eab1000
[0000000000000018] pgd=0000000000000000, p4d=0000000000000000
Internal error: Oops: 96000004 [#1] PREEMPT SMP
...
Hardware name: Google CoachZ (rev3+) (DT)
pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : ww_mutex_lock+0x28/0x32c
lr : drm_modeset_lock_all_ctx+0x1b0/0x3d0
sp : ffff80000805bb50
x29: ffff80000805bb50 x28: ffff327c00128000 x27: 0000000000000000
x26: 00000
---truncated--- |
