| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix NULL ptr dereference on VSI filter sync
Remove the reason of null pointer dereference in sync VSI filters.
Added new I40E_VSI_RELEASING flag to signalize deleting and releasing
of VSI resources to sync this thread with sync filters subtask.
Without this patch it is possible to start update the VSI filter list
after VSI is removed, that's causing a kernel oops. |
| In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix null deref accessing lag dev
It could be the lag dev is null so stop processing the event.
In bond_enslave() the active/backup slave being set before setting the
upper dev so first event is without an upper dev.
After setting the upper dev with bond_master_upper_dev_link() there is
a second event and in that event we have an upper dev. |
| In the Linux kernel, the following vulnerability has been resolved:
gve: Add NULL pointer checks when freeing irqs.
When freeing notification blocks, we index priv->msix_vectors.
If we failed to allocate priv->msix_vectors (see abort_with_msix_vectors)
this could lead to a NULL pointer dereference if the driver is unloaded. |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Clear DMA ops when switching domain
Since commit 08a27c1c3ecf ("iommu: Add support to change default domain
of an iommu group") a user can switch a device between IOMMU and direct
DMA through sysfs. This doesn't work for AMD IOMMU at the moment because
dev->dma_ops is not cleared when switching from a DMA to an identity
IOMMU domain. The DMA layer thus attempts to use the dma-iommu ops on an
identity domain, causing an oops:
# echo 0000:00:05.0 > /sys/sys/bus/pci/drivers/e1000e/unbind
# echo identity > /sys/bus/pci/devices/0000:00:05.0/iommu_group/type
# echo 0000:00:05.0 > /sys/sys/bus/pci/drivers/e1000e/bind
...
BUG: kernel NULL pointer dereference, address: 0000000000000028
...
Call Trace:
iommu_dma_alloc
e1000e_setup_tx_resources
e1000e_open
Since iommu_change_dev_def_domain() calls probe_finalize() again, clear
the dma_ops there like Vt-d does. |
| In the Linux kernel, the following vulnerability has been resolved:
efi/fdt: fix panic when no valid fdt found
setup_arch() would invoke efi_init()->efi_get_fdt_params(). If no
valid fdt found then initial_boot_params will be null. So we
should stop further fdt processing here. I encountered this
issue on risc-v. |
| In the Linux kernel, the following vulnerability has been resolved:
ice: track AF_XDP ZC enabled queues in bitmap
Commit c7a219048e45 ("ice: Remove xsk_buff_pool from VSI structure")
silently introduced a regression and broke the Tx side of AF_XDP in copy
mode. xsk_pool on ice_ring is set only based on the existence of the XDP
prog on the VSI which in turn picks ice_clean_tx_irq_zc to be executed.
That is not something that should happen for copy mode as it should use
the regular data path ice_clean_tx_irq.
This results in a following splat when xdpsock is run in txonly or l2fwd
scenarios in copy mode:
<snip>
[ 106.050195] BUG: kernel NULL pointer dereference, address: 0000000000000030
[ 106.057269] #PF: supervisor read access in kernel mode
[ 106.062493] #PF: error_code(0x0000) - not-present page
[ 106.067709] PGD 0 P4D 0
[ 106.070293] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 106.074721] CPU: 61 PID: 0 Comm: swapper/61 Not tainted 5.12.0-rc2+ #45
[ 106.081436] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019
[ 106.092027] RIP: 0010:xp_raw_get_dma+0x36/0x50
[ 106.096551] Code: 74 14 48 b8 ff ff ff ff ff ff 00 00 48 21 f0 48 c1 ee 30 48 01 c6 48 8b 87 90 00 00 00 48 89 f2 81 e6 ff 0f 00 00 48 c1 ea 0c <48> 8b 04 d0 48 83 e0 fe 48 01 f0 c3 66 66 2e 0f 1f 84 00 00 00 00
[ 106.115588] RSP: 0018:ffffc9000d694e50 EFLAGS: 00010206
[ 106.120893] RAX: 0000000000000000 RBX: ffff88984b8c8a00 RCX: ffff889852581800
[ 106.128137] RDX: 0000000000000006 RSI: 0000000000000000 RDI: ffff88984cd8b800
[ 106.135383] RBP: ffff888123b50001 R08: ffff889896800000 R09: 0000000000000800
[ 106.142628] R10: 0000000000000000 R11: ffffffff826060c0 R12: 00000000000000ff
[ 106.149872] R13: 0000000000000000 R14: 0000000000000040 R15: ffff888123b50018
[ 106.157117] FS: 0000000000000000(0000) GS:ffff8897e0f40000(0000) knlGS:0000000000000000
[ 106.165332] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 106.171163] CR2: 0000000000000030 CR3: 000000000560a004 CR4: 00000000007706e0
[ 106.178408] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 106.185653] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 106.192898] PKRU: 55555554
[ 106.195653] Call Trace:
[ 106.198143] <IRQ>
[ 106.200196] ice_clean_tx_irq_zc+0x183/0x2a0 [ice]
[ 106.205087] ice_napi_poll+0x3e/0x590 [ice]
[ 106.209356] __napi_poll+0x2a/0x160
[ 106.212911] net_rx_action+0xd6/0x200
[ 106.216634] __do_softirq+0xbf/0x29b
[ 106.220274] irq_exit_rcu+0x88/0xc0
[ 106.223819] common_interrupt+0x7b/0xa0
[ 106.227719] </IRQ>
[ 106.229857] asm_common_interrupt+0x1e/0x40
</snip>
Fix this by introducing the bitmap of queues that are zero-copy enabled,
where each bit, corresponding to a queue id that xsk pool is being
configured on, will be set/cleared within ice_xsk_pool_{en,dis}able and
checked within ice_xsk_pool(). The latter is a function used for
deciding which napi poll routine is executed.
Idea is being taken from our other drivers such as i40e and ixgbe. |
| In the Linux kernel, the following vulnerability has been resolved:
HID: magicmouse: fix NULL-deref on disconnect
Commit 9d7b18668956 ("HID: magicmouse: add support for Apple Magic
Trackpad 2") added a sanity check for an Apple trackpad but returned
success instead of -ENODEV when the check failed. This means that the
remove callback will dereference the never-initialised driver data
pointer when the driver is later unbound (e.g. on USB disconnect). |
| In the Linux kernel, the following vulnerability has been resolved:
drm/mediatek: hdmi: Perform NULL pointer check for mtk_hdmi_conf
In commit 41ca9caaae0b
("drm/mediatek: hdmi: Add check for CEA modes only") a check
for CEA modes was added to function mtk_hdmi_bridge_mode_valid()
in order to address possible issues on MT8167;
moreover, with commit c91026a938c2
("drm/mediatek: hdmi: Add optional limit on maximal HDMI mode clock")
another similar check was introduced.
Unfortunately though, at the time of writing, MT8173 does not provide
any mtk_hdmi_conf structure and this is crashing the kernel with NULL
pointer upon entering mtk_hdmi_bridge_mode_valid(), which happens as
soon as a HDMI cable gets plugged in.
To fix this regression, add a NULL pointer check for hdmi->conf in the
said function, restoring HDMI functionality and avoiding NULL pointer
kernel panics. |
| In the Linux kernel, the following vulnerability has been resolved:
ipmi: ssif: initialize ssif_info->client early
During probe ssif_info->client is dereferenced in error path. However,
it is set when some of the error checking has already been done. This
causes following kernel crash if an error path is taken:
[ 30.645593][ T674] ipmi_ssif 0-000e: ipmi_ssif: Not probing, Interface already present
[ 30.657616][ T674] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000088
...
[ 30.657723][ T674] pc : __dev_printk+0x28/0xa0
[ 30.657732][ T674] lr : _dev_err+0x7c/0xa0
...
[ 30.657772][ T674] Call trace:
[ 30.657775][ T674] __dev_printk+0x28/0xa0
[ 30.657778][ T674] _dev_err+0x7c/0xa0
[ 30.657781][ T674] ssif_probe+0x548/0x900 [ipmi_ssif 62ce4b08badc1458fd896206d9ef69a3c31f3d3e]
[ 30.657791][ T674] i2c_device_probe+0x37c/0x3c0
...
Initialize ssif_info->client before any error path can be taken. Clear
i2c_client data in the error path to prevent the dangling pointer from
leaking. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: ideapad-laptop: fix a NULL pointer dereference
The third parameter of dytc_cql_command should not be NULL since it will
be dereferenced immediately. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: qedf: Add pointer checks in qedf_update_link_speed()
The following trace was observed:
[ 14.042059] Call Trace:
[ 14.042061] <IRQ>
[ 14.042068] qedf_link_update+0x144/0x1f0 [qedf]
[ 14.042117] qed_link_update+0x5c/0x80 [qed]
[ 14.042135] qed_mcp_handle_link_change+0x2d2/0x410 [qed]
[ 14.042155] ? qed_set_ptt+0x70/0x80 [qed]
[ 14.042170] ? qed_set_ptt+0x70/0x80 [qed]
[ 14.042186] ? qed_rd+0x13/0x40 [qed]
[ 14.042205] qed_mcp_handle_events+0x437/0x690 [qed]
[ 14.042221] ? qed_set_ptt+0x70/0x80 [qed]
[ 14.042239] qed_int_sp_dpc+0x3a6/0x3e0 [qed]
[ 14.042245] tasklet_action_common.isra.14+0x5a/0x100
[ 14.042250] __do_softirq+0xe4/0x2f8
[ 14.042253] irq_exit+0xf7/0x100
[ 14.042255] do_IRQ+0x7f/0xd0
[ 14.042257] common_interrupt+0xf/0xf
[ 14.042259] </IRQ>
API qedf_link_update() is getting called from QED but by that time
shost_data is not initialised. This results in a NULL pointer dereference
when we try to dereference shost_data while updating supported_speeds.
Add a NULL pointer check before dereferencing shost_data. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Use online_vcpus, not created_vcpus, to iterate over vCPUs
Use the kvm_for_each_vcpu() helper to iterate over vCPUs when encrypting
VMSAs for SEV, which effectively switches to use online_vcpus instead of
created_vcpus. This fixes a possible null-pointer dereference as
created_vcpus does not guarantee a vCPU exists, since it is updated at
the very beginning of KVM_CREATE_VCPU. created_vcpus exists to allow the
bulk of vCPU creation to run in parallel, while still correctly
restricting the max number of max vCPUs. |
| In the Linux kernel, the following vulnerability has been resolved:
memory: renesas-rpc-if: fix possible NULL pointer dereference of resource
The platform_get_resource_byname() can return NULL which would be
immediately dereferenced by resource_size(). Instead dereference it
after validating the resource.
Addresses-Coverity: Dereference null return value |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix null pointer dereference in lpfc_prep_els_iocb()
It is possible to call lpfc_issue_els_plogi() passing a did for which no
matching ndlp is found. A call is then made to lpfc_prep_els_iocb() with a
null pointer to a lpfc_nodelist structure resulting in a null pointer
dereference.
Fix by returning an error status if no valid ndlp is found. Fix up comments
regarding ndlp reference counting. |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/mediatek: Always enable the clk on resume
In mtk_iommu_runtime_resume always enable the clk, even
if m4u_dom is null. Otherwise the 'suspend' cb might
disable the clk which is already disabled causing the warning:
[ 1.586104] infra_m4u already disabled
[ 1.586133] WARNING: CPU: 0 PID: 121 at drivers/clk/clk.c:952 clk_core_disable+0xb0/0xb8
[ 1.594391] mtk-iommu 10205000.iommu: bound 18001000.larb (ops mtk_smi_larb_component_ops)
[ 1.598108] Modules linked in:
[ 1.598114] CPU: 0 PID: 121 Comm: kworker/0:2 Not tainted 5.12.0-rc5 #69
[ 1.609246] mtk-iommu 10205000.iommu: bound 14027000.larb (ops mtk_smi_larb_component_ops)
[ 1.617487] Hardware name: Google Elm (DT)
[ 1.617491] Workqueue: pm pm_runtime_work
[ 1.620545] mtk-iommu 10205000.iommu: bound 19001000.larb (ops mtk_smi_larb_component_ops)
[ 1.627229] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--)
[ 1.659297] pc : clk_core_disable+0xb0/0xb8
[ 1.663475] lr : clk_core_disable+0xb0/0xb8
[ 1.667652] sp : ffff800011b9bbe0
[ 1.670959] x29: ffff800011b9bbe0 x28: 0000000000000000
[ 1.676267] x27: ffff800011448000 x26: ffff8000100cfd98
[ 1.681574] x25: ffff800011b9bd48 x24: 0000000000000000
[ 1.686882] x23: 0000000000000000 x22: ffff8000106fad90
[ 1.692189] x21: 000000000000000a x20: ffff0000c0048500
[ 1.697496] x19: ffff0000c0048500 x18: ffffffffffffffff
[ 1.702804] x17: 0000000000000000 x16: 0000000000000000
[ 1.708112] x15: ffff800011460300 x14: fffffffffffe0000
[ 1.713420] x13: ffff8000114602d8 x12: 0720072007200720
[ 1.718727] x11: 0720072007200720 x10: 0720072007200720
[ 1.724035] x9 : ffff800011b9bbe0 x8 : ffff800011b9bbe0
[ 1.729342] x7 : 0000000000000009 x6 : ffff8000114b8328
[ 1.734649] x5 : 0000000000000000 x4 : 0000000000000000
[ 1.739956] x3 : 00000000ffffffff x2 : ffff800011460298
[ 1.745263] x1 : 1af1d7de276f4500 x0 : 0000000000000000
[ 1.750572] Call trace:
[ 1.753010] clk_core_disable+0xb0/0xb8
[ 1.756840] clk_core_disable_lock+0x24/0x40
[ 1.761105] clk_disable+0x20/0x30
[ 1.764501] mtk_iommu_runtime_suspend+0x88/0xa8
[ 1.769114] pm_generic_runtime_suspend+0x2c/0x48
[ 1.773815] __rpm_callback+0xe0/0x178
[ 1.777559] rpm_callback+0x24/0x88
[ 1.781041] rpm_suspend+0xdc/0x470
[ 1.784523] rpm_idle+0x12c/0x170
[ 1.787831] pm_runtime_work+0xa8/0xc0
[ 1.791573] process_one_work+0x1e8/0x360
[ 1.795580] worker_thread+0x44/0x478
[ 1.799237] kthread+0x150/0x158
[ 1.802460] ret_from_fork+0x10/0x30
[ 1.806034] ---[ end trace 82402920ef64573b ]---
[ 1.810728] ------------[ cut here ]------------
In addition, we now don't need to enable the clock from the
function mtk_iommu_hw_init since it is already enabled by the resume. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Make sure GHCB is mapped before updating
Access to the GHCB is mainly in the VMGEXIT path and it is known that the
GHCB will be mapped. But there are two paths where it is possible the GHCB
might not be mapped.
The sev_vcpu_deliver_sipi_vector() routine will update the GHCB to inform
the caller of the AP Reset Hold NAE event that a SIPI has been delivered.
However, if a SIPI is performed without a corresponding AP Reset Hold,
then the GHCB might not be mapped (depending on the previous VMEXIT),
which will result in a NULL pointer dereference.
The svm_complete_emulated_msr() routine will update the GHCB to inform
the caller of a RDMSR/WRMSR operation about any errors. While it is likely
that the GHCB will be mapped in this situation, add a safe guard
in this path to be certain a NULL pointer dereference is not encountered. |
| In the Linux kernel, the following vulnerability has been resolved:
PCI: endpoint: Fix NULL pointer dereference for ->get_features()
get_features ops of pci_epc_ops may return NULL, causing NULL pointer
dereference in pci_epf_test_alloc_space function. Let us add a check for
pci_epc_feature pointer in pci_epf_test_bind before we access it to avoid
any such NULL pointer dereference and return -ENOTSUPP in case
pci_epc_feature is not found.
When the patch is not applied and EPC features is not implemented in the
platform driver, we see the following dump due to kernel NULL pointer
dereference.
Call trace:
pci_epf_test_bind+0xf4/0x388
pci_epf_bind+0x3c/0x80
pci_epc_epf_link+0xa8/0xcc
configfs_symlink+0x1a4/0x48c
vfs_symlink+0x104/0x184
do_symlinkat+0x80/0xd4
__arm64_sys_symlinkat+0x1c/0x24
el0_svc_common.constprop.3+0xb8/0x170
el0_svc_handler+0x70/0x88
el0_svc+0x8/0x640
Code: d2800581 b9403ab9 f9404ebb 8b394f60 (f9400400)
---[ end trace a438e3c5a24f9df0 ]--- |
| In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Fix potential null dereference on pointer status
There are calls to idxd_cmd_exec that pass a null status pointer however
a recent commit has added an assignment to *status that can end up
with a null pointer dereference. The function expects a null status
pointer sometimes as there is a later assignment to *status where
status is first null checked. Fix the issue by null checking status
before making the assignment.
Addresses-Coverity: ("Explicit null dereferenced") |
| In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Fix null pointer dereference in svc_rqst_free()
When alloc_pages_node() returns null in svc_rqst_alloc(), the
null rq_scratch_page pointer will be dereferenced when calling
put_page() in svc_rqst_free(). Fix it by adding a null check.
Addresses-Coverity: ("Dereference after null check") |
| In the Linux kernel, the following vulnerability has been resolved:
can: mcp251xfd: mcp251xfd_probe(): fix an error pointer dereference in probe
When we converted this code to use dev_err_probe() we accidentally
removed a return. It means that if devm_clk_get() it will lead to an
Oops when we call clk_get_rate() on the next line. |
