| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: int3472: Check for adev == NULL
Not all devices have an ACPI companion fwnode, so adev might be NULL. This
can e.g. (theoretically) happen when a user manually binds one of
the int3472 drivers to another i2c/platform device through sysfs.
Add a check for adev not being set and return -ENODEV in that case to
avoid a possible NULL pointer deref in skl_int3472_get_acpi_buffer(). |
| In the Linux kernel, the following vulnerability has been resolved:
IB/hfi1: Fix leak of rcvhdrtail_dummy_kvaddr
This buffer is currently allocated in hfi1_init():
if (reinit)
ret = init_after_reset(dd);
else
ret = loadtime_init(dd);
if (ret)
goto done;
/* allocate dummy tail memory for all receive contexts */
dd->rcvhdrtail_dummy_kvaddr = dma_alloc_coherent(&dd->pcidev->dev,
sizeof(u64),
&dd->rcvhdrtail_dummy_dma,
GFP_KERNEL);
if (!dd->rcvhdrtail_dummy_kvaddr) {
dd_dev_err(dd, "cannot allocate dummy tail memory\n");
ret = -ENOMEM;
goto done;
}
The reinit triggered path will overwrite the old allocation and leak it.
Fix by moving the allocation to hfi1_alloc_devdata() and the deallocation
to hfi1_free_devdata(). |
| In the Linux kernel, the following vulnerability has been resolved:
sfc: fix TX channel offset when using legacy interrupts
In legacy interrupt mode the tx_channel_offset was hardcoded to 1, but
that's not correct if efx_sepparate_tx_channels is false. In that case,
the offset is 0 because the tx queues are in the single existing channel
at index 0, together with the rx queue.
Without this fix, as soon as you try to send any traffic, it tries to
get the tx queues from an uninitialized channel getting these errors:
WARNING: CPU: 1 PID: 0 at drivers/net/ethernet/sfc/tx.c:540 efx_hard_start_xmit+0x12e/0x170 [sfc]
[...]
RIP: 0010:efx_hard_start_xmit+0x12e/0x170 [sfc]
[...]
Call Trace:
<IRQ>
dev_hard_start_xmit+0xd7/0x230
sch_direct_xmit+0x9f/0x360
__dev_queue_xmit+0x890/0xa40
[...]
BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
[...]
RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc]
[...]
Call Trace:
<IRQ>
dev_hard_start_xmit+0xd7/0x230
sch_direct_xmit+0x9f/0x360
__dev_queue_xmit+0x890/0xa40
[...] |
| In the Linux kernel, the following vulnerability has been resolved:
perf/x86/intel/pt: Fix crash with stop filters in single-range mode
Add a check for !buf->single before calling pt_buffer_region_size in a
place where a missing check can cause a kernel crash.
Fixes a bug introduced by commit 670638477aed ("perf/x86/intel/pt:
Opportunistically use single range output mode"), which added a
support for PT single-range output mode. Since that commit if a PT
stop filter range is hit while tracing, the kernel will crash because
of a null pointer dereference in pt_handle_status due to calling
pt_buffer_region_size without a ToPA configured.
The commit which introduced single-range mode guarded almost all uses of
the ToPA buffer variables with checks of the buf->single variable, but
missed the case where tracing was stopped by the PT hardware, which
happens when execution hits a configured stop filter.
Tested that hitting a stop filter while PT recording successfully
records a trace with this patch but crashes without this patch. |
| CWE-476 NULL Pointer Dereference vulnerability in the evalExpr() function of GoAhead Web Server (version <= 6.0.0) when compiled with the ME_GOAHEAD_JAVASCRIPT flag. This vulnerability allows a remote attacker with the privileges to modify JavaScript template (JST) files to trigger a crash and cause a Denial of Service (DoS) by providing malicious templates. |
| In the Linux kernel, the following vulnerability has been resolved:
mailbox: th1520: Fix a NULL vs IS_ERR() bug
The devm_ioremap() function doesn't return error pointers, it returns
NULL. Update the error checking to match. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/komeda: check for error-valued pointer
komeda_pipeline_get_state() may return an error-valued pointer, thus
check the pointer for negative or null value before dereferencing. |
| When SIP session Application Level Gateway mode (ALG) profile with Passthru Mode enabled and SIP router ALG profile are configured on a Message Routing type virtual server, undisclosed traffic can cause the Traffic Management Microkernel (TMM) to terminate. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated. |
| in OpenHarmony v5.0.2 and prior versions allow a local attacker cause DOS through NULL pointer dereference. |
| FFmpeg git-master,N-113007-g8d24a28d06 was discovered to contain a segmentation violation via the component /libavcodec/jpeg2000dec.c. |
| FFmpeg git master before commit c08d30 was discovered to contain a NULL pointer dereference via the component libavformat/mov.c. |
| An attacker can publish a zone containing specific Resource Record Sets. Processing and caching results for these sets can lead to an illegal memory accesses and crash of the Recursor, causing a denial of service.
The remedy is: upgrade to the patched 5.2.1 version.
We would like to thank Volodymyr Ilyin for bringing this issue to our attention. |
| A vulnerability classified as critical was found in RT-Thread 5.1.0. This vulnerability affects the function csys_sendto of the file rt-thread/components/lwp/lwp_syscall.c. The manipulation of the argument to leads to null pointer dereference. |
| Substance3D - Viewer versions 0.22 and earlier are affected by a NULL Pointer Dereference vulnerability that could lead to application denial-of-service. An attacker could exploit this vulnerability to crash the application, causing disruption in service. Exploitation of this issue requires user interaction in that a victim must open a malicious file. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix system hang while resume with TBT monitor
[Why]
Connected with a Thunderbolt monitor and do the suspend and the system
may hang while resume.
The TBT monitor HPD will be triggered during the resume procedure
and call the drm_client_modeset_probe() while
struct drm_connector connector->dev->master is NULL.
It will mess up the pipe topology after resume.
[How]
Skip the TBT monitor HPD during the resume procedure because we
currently will probe the connectors after resume by default.
(cherry picked from commit 453f86a26945207a16b8f66aaed5962dc2b95b85) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags
[WHAT & HOW]
"dcn20_validate_apply_pipe_split_flags" dereferences merge, and thus it
cannot be a null pointer. Let's pass a valid pointer to avoid null
dereference.
This fixes 2 FORWARD_NULL issues reported by Coverity. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check null pointers before using them
[WHAT & HOW]
These pointers are null checked previously in the same function,
indicating they might be null as reported by Coverity. As a result,
they need to be checked when used again.
This fixes 3 FORWARD_NULL issue reported by Coverity. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check null pointers before used
[WHAT & HOW]
Poniters, such as dc->clk_mgr, are null checked previously in the same
function, so Coverity warns "implies that "dc->clk_mgr" might be null".
As a result, these pointers need to be checked when used again.
This fixes 10 FORWARD_NULL issues reported by Coverity. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check null pointers before multiple uses
[WHAT & HOW]
Poniters, such as stream_enc and dc->bw_vbios, are null checked previously
in the same function, so Coverity warns "implies that stream_enc and
dc->bw_vbios might be null". They are used multiple times in the
subsequent code and need to be checked.
This fixes 10 FORWARD_NULL issues reported by Coverity. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add null check for head_pipe in dcn201_acquire_free_pipe_for_layer
This commit addresses a potential null pointer dereference issue in the
`dcn201_acquire_free_pipe_for_layer` function. The issue could occur
when `head_pipe` is null.
The fix adds a check to ensure `head_pipe` is not null before asserting
it. If `head_pipe` is null, the function returns NULL to prevent a
potential null pointer dereference.
Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn201/dcn201_resource.c:1016 dcn201_acquire_free_pipe_for_layer() error: we previously assumed 'head_pipe' could be null (see line 1010) |
