| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
firmware: qcom: scm: Fix NULL dereference in IRQ handler before __scm is published
In qcom_scm_probe(), devm_request_threaded_irq() is called before
smp_store_release(&__scm, scm). Two paths can dereference __scm before
it is published, both causing a NULL pointer dereference.
The IRQ handler receives scm via its data argument but passes only wq_ctx
to qcom_scm_waitq_wakeup() and qcom_scm_get_completion(), which then
dereference __scm directly. Thread scm through both functions so the IRQ
handler path never touches __scm.
Non-atomic SMC calls made during probe (e.g. from qcom_tzmem_init via
qcom_scm_shm_bridge_enable) can return WAITQ_SLEEP, causing
qcom_scm_wait_for_wq_completion() to run before __scm is published and
dereference it. Add platform_set_drvdata(pdev, scm) early in probe and
change qcom_scm_wait_for_wq_completion() to take the device pointer and
use dev_get_drvdata() to reach scm, removing any dependency on __scm. |
| In the Linux kernel, the following vulnerability has been resolved:
dpll: fix NULL deref in dpll_device_ops() during teardown race
When the last owner of a dpll device unregisters while a foreign driver
still holds a pin on it via dpll_pin_on_pin_register(), the dpll object
stays alive with an empty registration list. A pin notification queued
before the unregister (e.g. ice reacting to zl3073x_i2c removal) then
walks pin->dpll_refs into dpll_device_ops(), which trips the WARN_ON and
dereferences the missing registration. dpll_lock cannot help because the
notification work was queued before the unregistering driver took the
lock.
Treat the empty registration list as a legitimate transient state. Make
dpll_priv() and dpll_device_ops() return NULL in that case and make
every pin netlink path that resolves a device from a pin skip such
dplls. dpll_cmd_pin_get_one() picks a ref with a live registration and
returns -ENODEV when there is none, the pin dumpit skips such a pin
instead of aborting the dump, dpll_msg_add_pin_dplls() and the
frequency, esync, reference sync and phase adjust set paths skip dead
refs, and dpll_pin_parent_device_set() validates the parent with
dpll_device_get_by_id(). dpll_pin_register() is the last caller that
dereferenced the device ops without a check, so move its frequency
monitor validation under dpll_lock and tolerate a missing registration
there as well.
The empty registration list is equivalent to a cleared DPLL_REGISTERED
mark, both transitions happen under dpll_lock in dpll_device_register()
and dpll_device_unregister(). A pin notification for a pin whose dplls
are all gone is now dropped with -ENODEV instead of crashing, all
callers in the core ignore that return value.
WARNING: drivers/dpll/dpll_core.c:1092 at dpll_device_ops+0x24/0x40,
CPU#83: kworker/u576:3/23471
Modules linked in: ... ice ... zl3073x_i2c(-) ... zl3073x ...
Workqueue: ice_dpll_wq ice_dpll_pin_notify_work [ice]
RIP: 0010:dpll_device_ops+0x24/0x40
Call Trace:
<TASK>
dpll_cmd_pin_get_one+0x336/0x520
dpll_pin_event_send+0x82/0x140
dpll_pin_on_pin_unregister+0xbb/0x160
ice_dpll_pin_notify_work+0x1bc/0x1f0 [ice]
process_one_work+0x19e/0x370
worker_thread+0x1a6/0x310
kthread+0xe4/0x120
ret_from_fork+0x1a1/0x270
ret_from_fork_asm+0x1a/0x30
</TASK>
---[ end trace 0000000000000000 ]---
BUG: kernel NULL pointer dereference, address: 0000000000000010
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: control: Don't add invalid kcontrols to LED layer
The kcontrol LED state layer tries to track the all associated
kcontrol elements with naive assumptions that they are readable.
But one can create a write-only element that has no get callback (even
a user element can do it), and this may lead to a NULL dereference at
the call chain of snd_ctl_led_notify(), as found by syzkaller.
For avoiding the Oops, add a sanity check of the kcontrol's info and
get callbacks, and just skip the invalid kcontrols before assigning
the kctl to the LED layer. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/uvmm: fix NULL deref unwinding an OP_MAP_SPARSE op
Each bind_job_op is zeroed by kzalloc_obj() in bind_job_op_from_uop(),
and the OP_MAP_SPARSE case in nouveau_uvmm_bind_job_submit() only creates
a region, so op->ops stays NULL for a successfully processed sparse map.
If a later op in the same job fails, the reverse unwind loop revisits that
op and calls drm_gpuva_ops_free(&uvmm->base, op->ops) unconditionally.
drm_gpuva_ops_free() dereferences its argument right away
(list_for_each_entry_safe on &ops->list), so a NULL op->ops oopses. The
path is reachable by any render-node fd holder, since NOUVEAU_VM_BIND is
DRM_RENDER_ALLOW.
Guard the free with IS_ERR_OR_NULL(), as nouveau_uvmm_bind_job_cleanup()
already does for the identical free. |
| In the Linux kernel, the following vulnerability has been resolved:
net: emac: Fix NULL pointer dereference in emac_probe
Move devm_request_irq() after devm_platform_ioremap_resource() so that
dev->emacp is mapped before the interrupt handler can fire. An early
interrupt hitting emac_irq() would dereference the NULL dev->emacp and
crash.
Also remove redundant error message. devm_platform_ioremap_resource()
already returns an error message with dev_err_probe(). |
| In the Linux kernel, the following vulnerability has been resolved:
firewire: ohci: fix NULL pointer dereference in ar_context_release
During the error handling path of the driver's probe function, a NULL
pointer dereference can occur in ar_context_release().
When pci_probe() fails early (e.g., if pcim_enable_device() or MMIO mapping
fails), the devres cleanup mechanism invokes release_ohci(). This function
unconditionally calls ar_context_release() to clean up the asynchronous
receive contexts. However, if ar_context_init() was not yet called,
ctx->ohci remains NULL (as the fw_ohci structure is zero-initialized by
devres_alloc()).
ar_context_release() immediately dereferences ctx->ohci to get the dev
pointer before checking if the context was actually initialized, leading to
a crash:
Oops: general protection fault, probably for non-canonical address
0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
RIP: 0010:ar_context_release+0x3f/0x380 drivers/firewire/ohci.c:543
Call Trace:
release_ohci+0x3f/0x60 drivers/firewire/ohci.c:3567
release_nodes drivers/base/devres.c:546 [inline]
devres_release_all+0x1a8/0x260 drivers/base/devres.c:576
device_unbind_cleanup drivers/base/dd.c:597 [inline]
really_probe+0x451/0xae0 drivers/base/dd.c:772
To fix this, move the assignment of the dev pointer after the !ctx->buffer
check. If ctx->buffer is NULL, it indicates that the context was never
successfully initialized and there is nothing to release, safely avoiding
the dereference of the uninitialized ctx->ohci pointer. |
| In the Linux kernel, the following vulnerability has been resolved:
xfs: handle NULL b_addr in xfs_buf_free
When xfs_buf_alloc_backing_mem() fails, xfs_buf_free() is called with
bp->b_addr still NULL. The code falls through to the folio_put path
which calls virt_to_folio(NULL), dereferencing an invalid address and
causing a kernel crash.
Call Trace:
xfs_buf_free+0x25f/0x510
xfs_buf_alloc+0xc98/0x19b0
xfs_buf_find_insert+0x55/0x14d0
xfs_buf_get_map+0x122b/0x17c0
xfbtree_init_leaf_block+0x11c/0x4a0
xfbtree_init+0x1bb/0x460
xrep_rmap_setup_scan+0x100/0x1f0
xrep_rmapbt+0x41/0xc0
Fix this by skipping folio_put() when bp->b_addr is NULL. |
| In the Linux kernel, the following vulnerability has been resolved:
bnxt_en: Handle partially initialized auxiliary devices
bnxt_aux_devices_init() calls auxiliary_device_init() before all fields
used by bnxt_aux_dev_release() are initialized. After
auxiliary_device_init() succeeds, later errors must unwind with
auxiliary_device_uninit(), which invokes the release callback.
The release callback assumes that aux_priv->id, aux_priv->edev,
edev->net and edev->ulp_tbl are all populated. If allocation fails
after auxiliary_device_init(), the release path can otherwise dereference
or clear partially initialized state.
Allocate and attach the bnxt_en_dev and ULP table before calling
auxiliary_device_init(), so the release callback only sees a fully
initialized auxiliary private object. If auxiliary_device_init() itself
fails, free those allocations directly because device_initialize() has not
run and the release callback will not be invoked.
This issue was found by a static analysis checker and confirmed by manual
source review. |
| In the Linux kernel, the following vulnerability has been resolved:
idpf: fix max_vport related crash on allocation error during init
Set adapter->max_vports only after successful allocation of vports, netdevs
and vport_config buffers. This fixes possible crashes on reset or rmmod,
following failed allocation on init
[ 305.981402] idpf 0000:83:00.0: enabling device (0100 -> 0102)
[ 305.994464] idpf 0000:83:00.0: Device HW Reset initiated
[ 320.416872] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 320.416918] #PF: supervisor read access in kernel mode
[ 320.416942] #PF: error_code(0x0000) - not-present page
[ 320.416963] PGD 2099657067 P4D 0
[ 320.416983] Oops: Oops: 0000 [#1] SMP NOPTI
...
[ 320.417093] RIP: 0010:idpf_remove+0x118/0x200 [idpf]
[ 320.417130] Code: 8b bb 98 09 00 00 e8 17 0f 5b e5 48 8b bb e8 08 00 00 e8 0b 0f 5b e5 66 83 bb 28 06 00 00 00 48 8b bb 20 06 00 00 74 49 31 ed <48> 8b 04 ef 48 85 c0 74 2f 48 8b 78 20 e8 66 58 91 e5 48 8b 83 20
[ 320.417183] RSP: 0018:ff7322212903fdb8 EFLAGS: 00010246
[ 320.417205] RAX: 0000000000000000 RBX: ff4463de40300000 RCX: ff7322212903fd4c
[ 320.417228] RDX: 0000000000000001 RSI: ffffffffa7f7d100 RDI: 0000000000000000
[ 320.417250] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
[ 320.417272] R10: 0000000000000001 R11: ff4463de3a638f58 R12: ff4463be89ac7000
[ 320.417294] R13: ff4463be89ac7198 R14: ff4463be94fc7198 R15: ffffffffc0f10f20
[ 320.417317] FS: 00007f963c0e6740(0000) GS:ff4463fdd65d8000(0000) knlGS:0000000000000000
[ 320.417342] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 320.417362] CR2: 0000000000000000 CR3: 00000020ba674002 CR4: 0000000000773ef0
[ 320.417385] PKRU: 55555554
[ 320.417398] Call Trace:
[ 320.417412] <TASK>
[ 320.417429] pci_device_remove+0x42/0xb0
[ 320.417459] device_release_driver_internal+0x1a9/0x210
[ 320.417492] driver_detach+0x4b/0x90
[ 320.417516] bus_remove_driver+0x70/0x100
[ 320.417539] pci_unregister_driver+0x2e/0xb0
[ 320.417564] __do_sys_delete_module.constprop.0+0x190/0x2f0
[ 320.417592] ? kmem_cache_free+0x31e/0x550
[ 320.417619] ? lockdep_hardirqs_on_prepare+0xde/0x190
[ 320.417644] ? do_syscall_64+0x38/0x6b0
[ 320.417665] do_syscall_64+0xc8/0x6b0
[ 320.417683] ? clear_bhb_loop+0x30/0x80
[ 320.417706] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 320.417727] RIP: 0033:0x7f963bb30beb |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix kernel panic during driver load failure
Avoid kernel panic if MES init fails during driver load. The KIQ ring is
falsely marked as ready as ASICs that use MES, KIQ is owned by MES.
BUG: kernel NULL pointer dereference, address: 0000000000000000
RIP: 0010:gfx_v12_1_wait_reg_mem+0x5a/0x1f0 [amdgpu]
Call Trace:
gfx_v12_1_ring_emit_reg_write_reg_wait+0x1f/0x30 [amdgpu]
amdgpu_gmc_fw_reg_write_reg_wait+0xb2/0x190 [amdgpu]
amdgpu_gmc_flush_gpu_tlb+0x1cc/0x230 [amdgpu]
amdgpu_gart_invalidate_tlb+0x81/0xa0 [amdgpu]
amdgpu_gart_unbind+0x72/0x90 [amdgpu]
amdgpu_ttm_backend_unbind+0xa4/0xb0 [amdgpu]
amdgpu_ttm_tt_unpopulate+0x13/0xd0 [amdgpu]
amdttm_tt_unpopulate+0x29/0x70 [amdttm]
ttm_bo_put+0x1eb/0x360 [amdttm]
amdgpu_bo_free_kernel+0xf9/0x1f0 [amdgpu]
amdgpu_ih_ring_fini+0x5a/0x90 [amdgpu]
amdgpu_irq_fini_hw+0x58/0x80 [amdgpu]
amdgpu_device_fini_hw+0x4e0/0x5b0 [amdgpu]
amdgpu_driver_load_kms+0x60/0xa0 [amdgpu]
amdgpu_pci_probe+0x28e/0x6d0 [amdgpu]
pci_device_probe+0x19f/0x220
really_probe+0x1ed/0x340
driver_probe_device+0x1e/0x80
__driver_attach+0xd3/0x1a0
bus_for_each_dev+0x68/0xa0
bus_add_driver+0x19f/0x270
driver_register+0x5d/0xf0
do_one_initcall+0xac/0x200
do_init_module+0x1ec/0x280
__se_sys_finit_module+0x2de/0x310
do_syscall_64+0x6a/0x250
entry_SYSCALL_64_after_hwframe+0x4b/0x53
(cherry picked from commit 4623b958dd6da0f4c3026afdf330626a09ecb0f0) |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: x_tables: allocate hook ops while under mutex
arp/ip(6)t_register_table() add the table to the per-netns list via
xt_register_table() before allocating the per-netns hook ops copy
via kmemdup_array(). This leaves a window where the table is
visible in the list with ops=NULL.
If the pernet exit happens runs concurrently the pre_exit callback finds
the table via xt_find_table() and passes the NULL ops pointer to
nf_unregister_net_hooks(), causing a NULL dereference:
general protection fault in nf_unregister_net_hooks+0xbc/0x150
RIP: nf_unregister_net_hooks (net/netfilter/core.c:613)
Call Trace:
ipt_unregister_table_pre_exit
iptable_mangle_net_pre_exit
ops_pre_exit_list
cleanup_net
Fix by moving the ops allocation into the xtables core so the table is
never in the list without valid ops. Also ensure the table is no longer
processing packets before its torn down on error unwind.
nf_register_net_hooks might have published at least one hook; call
synchronize_rcu() if there was an error.
audit log register message gets deferred until all operations have
passed, this avoids need to emit another ureg message in case of
error unwinding.
Based on earlier patch by Tristan Madani. |
| In the Linux kernel, the following vulnerability has been resolved:
f2fs: read COW data with the original inode during atomic write
When updating an atomic-write file, f2fs_write_begin() may read the
previously written data back from the COW inode:
prepare_atomic_write_begin() locates the block in the COW inode and sets
use_cow, and the read bio is then built with the COW inode:
f2fs_submit_page_read(use_cow ? F2FS_I(inode)->cow_inode : inode,
...);
and f2fs_grab_read_bio() decides whether to schedule fs-layer decryption
(STEP_DECRYPT) for the bio based on that inode via
fscrypt_inode_uses_fs_layer_crypto().
However, the folio being filled belongs to the original inode
(folio->mapping->host == inode), and the data stored in the COW block was
encrypted (or left as plaintext) using the original inode's context, not
the COW inode's -- see f2fs_encrypt_one_page(), which keys off
fio->page->mapping->host. fscrypt_decrypt_pagecache_blocks() likewise
operates on folio->mapping->host.
The COW inode is created as a tmpfile in the parent directory and inherits
its encryption policy from there. With test_dummy_encryption the newly
created COW inode gets the dummy policy and becomes encrypted, while a
pre-existing regular file -- created before the policy applied, e.g.
already present in the on-disk image -- stays unencrypted. The read
path then sets STEP_DECRYPT based on the encrypted COW inode and calls
fscrypt_decrypt_pagecache_blocks() on a folio whose host (the unencrypted
original inode) has a NULL ->i_crypt_info, dereferencing it:
Oops: general protection fault, probably for non-canonical address ...
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
RIP: 0010:fscrypt_decrypt_pagecache_blocks+0xa0/0x310
Workqueue: f2fs_post_read_wq f2fs_post_read_work
Call Trace:
fscrypt_decrypt_bio+0x1eb/0x340
f2fs_post_read_work+0xba/0x140
process_one_work+0x91c/0x1a40
worker_thread+0x677/0xe90
kthread+0x2bc/0x3a0
The COW inode is only needed to locate the on-disk block, and that block
address is already resolved into @blkaddr by prepare_atomic_write_begin()
via __find_data_block(cow_inode, ...); f2fs_submit_page_read() then reads
from that physical @blkaddr directly, so the inode argument only selects
the post-read crypto context, not which block is fetched. Reading with
@inode therefore returns the same (latest, not-yet-committed) COW data,
while making both the fs-layer decryption decision and the inline crypto
path use the correct (original inode's) key.
With the COW inode no longer used at the read site, the use_cow flag has no
remaining consumer; drop it from f2fs_write_begin() and
prepare_atomic_write_begin(). |
| In the Linux kernel, the following vulnerability has been resolved:
iio: frequency: admv1013: fix NULL pointer dereference on str
When device_property_read_string() fails, str is left uninitialized
but the code falls through to strcmp(str, ...), dereferencing a garbage
pointer. Replace manual read/strcmp with
device_property_match_property_string() and consolidate the SE mode
enums into a single sequential enum, mapping to hardware register
values via a switch consistent with other bitfields in the driver.
Several cleanup patches have been applied to this driver recently so
this will need a manual backport. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix dc_link NULL handling in HPD init
amdgpu_dm_hpd_init() may see connectors without a valid dc_link.
The code already checks dc_link for the polling decision, but later
unconditionally dereferences it when setting up HPD interrupts.
Assign dc_link early and skip connectors where it is NULL.
Fixes the below:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c:940 amdgpu_dm_hpd_init()
error: we previously assumed 'dc_link' could be null (see line 931)
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c
923 /*
924 * Analog connectors may be hot-plugged unlike other connector
925 * types that don't support HPD. Only poll analog connectors.
926 */
927 use_polling |=
928 amdgpu_dm_connector->dc_link &&
^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The patch adds this NULL check but hopefully it can be removed
929 dc_connector_supports_analog(amdgpu_dm_connector->dc_link->link_id.id);
930
931 dc_link = amdgpu_dm_connector->dc_link;
dc_link assigned here.
932
933 /*
934 * Get a base driver irq reference for hpd ints for the lifetime
935 * of dm. Note that only hpd interrupt types are registered with
936 * base driver; hpd_rx types aren't. IOW, amdgpu_irq_get/put on
937 * hpd_rx isn't available. DM currently controls hpd_rx
938 * explicitly with dc_interrupt_set()
939 */
--> 940 if (dc_link->irq_source_hpd != DC_IRQ_SOURCE_INVALID) {
^^^^^^^^^^^^^^^^^^^^^^^ If it's NULL then we are trouble because we dereference it here.
941 irq_type = dc_link->irq_source_hpd - DC_IRQ_SOURCE_HPD1;
942 /*
943 * TODO: There's a mismatch between mode_info.num_hpd
944 * and what bios reports as the # of connectors with hpd |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: nSVM: Raise #UD if unhandled VMMCALL isn't intercepted by L1
Explicitly synthesize a #UD for VMMCALL if L2 is active, L1 does NOT want
to intercept VMMCALL, nested_svm_l2_tlb_flush_enabled() is true, and the
hypercall is something other than one of the supported Hyper-V hypercalls.
When all of the above conditions are met, KVM will intercept VMMCALL but
never forward it to L1, i.e. will let L2 make hypercalls as if it were L1.
The TLFS says a whole lot of nothing about this scenario, so go with the
architectural behavior, which says that VMMCALL #UDs if it's not
intercepted.
Opportunistically do a 2-for-1 stub trade by stub-ifying the new API
instead of the helpers it uses. The last remaining "single" stub will
soon be dropped as well.
[sean: rewrite changelog and comment, tag for stable, remove defunct stubs] |
| In the Linux kernel, the following vulnerability has been resolved:
rxrpc, afs: Fix missing error pointer check after rxrpc_kernel_lookup_peer()
rxrpc_kernel_lookup_peer() can also return error pointers in addition to
NULL, so just checking for NULL is not sufficient.
Fix this by:
(1) Changing rxrpc_kernel_lookup_peer() to return -ENOMEM rather than NULL
on allocation failure.
(2) Making the callers in afs use IS_ERR() and PTR_ERR() to pass on the
error code returned. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix NULL pointer dereference in dcn401_init_hw()
dcn401_init_hw() assumes that update_bw_bounding_box() is valid when
entering the update path. However, the existing condition:
((!fams2_enable && update_bw_bounding_box) || freq_changed)
does not guarantee this, as the freq_changed branch can evaluate to true
independently of the callback pointer.
This can result in calling update_bw_bounding_box() when it is NULL.
Fix this by separating the update condition from the pointer checks and
ensuring the callback, dc->clk_mgr, and bw_params are validated before
use.
Fixes the below:
../dc/hwss/dcn401/dcn401_hwseq.c:367 dcn401_init_hw() error: we previously assumed 'dc->res_pool->funcs->update_bw_bounding_box' could be null (see line 362)
(cherry picked from commit 86117c5ab42f21562fedb0a64bffea3ee5fcd477) |
| In the Linux kernel, the following vulnerability has been resolved:
zram: set default primary compressor in zram_destroy_comps()
Patch series "zram: fix zram issues reported by sashiko".
Sashiko drove by and reported [1] a couple of zram issues:
a possible BUG_ON() in zlib code due to missing winbits range
validation and one possible NULL-ptr dereference in zcomp.
Both are low risk yet still worth fixing.
This patch (of 2):
zram_destroy_comps() resets all compressors and leaves them set to NULL,
including the primary one, which is invalid device state, as now
comp_algorithm_show()->strcmp() can be called on a NULL compressor. Set
default primary compressor in zram_destroy_comps(). |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/sva: Set handle->dev before the SVA handle is visible
iommu_attach_device_pasid() installs the new SVA attach handle in the
group PASID lookup before iommu_sva_bind_device() returns. A concurrent
bind can therefore find and reuse the same handle after iommu_sva_lock is
dropped.
handle->dev was initialized after dropping iommu_sva_lock. This leaves a
window where a racing bind can return a handle whose dev pointer is still
NULL. A subsequent iommu_sva_unbind_device() can then dereference it via
handle->dev->iommu_group.
Initialize handle->dev before releasing iommu_sva_lock so any visible SVA
handle is fully initialized. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: ISST: Add a NULL check for sst_inst[]
To be consistent with other places, add a NULL check for failed socket
loading by checking isst_common.sst_inst[]. |
