Threat and Vulnerability Intelligence Database
Example Searches:
CVE
Threat Actors
Countries
Vendors
Severity
Known Exploited
CVE-2023-52882 |
Description: In the Linux kernel, the following vulnerability has been resolved:
clk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate change
While PLL CPUX clock rate change when CPU is running from it works in
vast majority of cases, now and then it causes instability. This leads
to system crashes and other undefined behaviour. After a lot of testing
(30+ hours) while also doing a lot of frequency switches, we can't
observe any instability issues anymore when doing reparenting to stable
clock like 24 MHz oscillator.
EPSS Score: 0.04%
December 20th, 2024 (4 months ago)
|
|
CVE-2023-52881 |
Description: In the Linux kernel, the following vulnerability has been resolved:
tcp: do not accept ACK of bytes we never sent
This patch is based on a detailed report and ideas from Yepeng Pan
and Christian Rossow.
ACK seq validation is currently following RFC 5961 5.2 guidelines:
The ACK value is considered acceptable only if
it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <=
SND.NXT). All incoming segments whose ACK value doesn't satisfy the
above condition MUST be discarded and an ACK sent back. It needs to
be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a
duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK
acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an
ACK, drop the segment, and return". The "ignored" above implies that
the processing of the incoming data segment continues, which means
the ACK value is treated as acceptable. This mitigation makes the
ACK check more stringent since any ACK < SND.UNA wouldn't be
accepted, instead only ACKs that are in the range ((SND.UNA -
MAX.SND.WND) <= SEG.ACK <= SND.NXT) get through.
This can be refined for new (and possibly spoofed) flows,
by not accepting ACK for bytes that were never sent.
This greatly improves TCP security at a little cost.
I added a Fixes: tag to make sure this patch will reach stable trees,
even if the 'blamed' patch was adhering to the RFC.
tp->bytes_acked was added in linux-4.2
Following packetdrill test (cou...
EPSS Score: 0.04%
December 20th, 2024 (4 months ago)
|
|
CVE-2023-52880 |
Description: In the Linux kernel, the following vulnerability has been resolved:
tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc
Any unprivileged user can attach N_GSM0710 ldisc, but it requires
CAP_NET_ADMIN to create a GSM network anyway.
Require initial namespace CAP_NET_ADMIN to do that.
EPSS Score: 0.04%
December 20th, 2024 (4 months ago)
|
|
CVE-2023-52879 |
Description: In the Linux kernel, the following vulnerability has been resolved:
tracing: Have trace_event_file have ref counters
The following can crash the kernel:
# cd /sys/kernel/tracing
# echo 'p:sched schedule' > kprobe_events
# exec 5>>events/kprobes/sched/enable
# > kprobe_events
# exec 5>&-
The above commands:
1. Change directory to the tracefs directory
2. Create a kprobe event (doesn't matter what one)
3. Open bash file descriptor 5 on the enable file of the kprobe event
4. Delete the kprobe event (removes the files too)
5. Close the bash file descriptor 5
The above causes a crash!
BUG: kernel NULL pointer dereference, address: 0000000000000028
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 6 PID: 877 Comm: bash Not tainted 6.5.0-rc4-test-00008-g2c6b6b1029d4-dirty #186
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
RIP: 0010:tracing_release_file_tr+0xc/0x50
What happens here is that the kprobe event creates a trace_event_file
"file" descriptor that represents the file in tracefs to the event. It
maintains state of the event (is it enabled for the given instance?).
Opening the "enable" file gets a reference to the event "file" descriptor
via the open file descriptor. When the kprobe event is deleted, the file is
also deleted from the tracefs system which also frees the event "file"
descriptor.
But as the tracefs file is...
EPSS Score: 0.04%
December 20th, 2024 (4 months ago)
|
|
CVE-2023-52878 |
Description: In the Linux kernel, the following vulnerability has been resolved:
can: dev: can_put_echo_skb(): don't crash kernel if can_priv::echo_skb is accessed out of bounds
If the "struct can_priv::echoo_skb" is accessed out of bounds, this
would cause a kernel crash. Instead, issue a meaningful warning
message and return with an error.
EPSS Score: 0.05%
December 20th, 2024 (4 months ago)
|
|
CVE-2023-52877 |
Description: In the Linux kernel, the following vulnerability has been resolved:
usb: typec: tcpm: Fix NULL pointer dereference in tcpm_pd_svdm()
It is possible that typec_register_partner() returns ERR_PTR on failure.
When port->partner is an error, a NULL pointer dereference may occur as
shown below.
[91222.095236][ T319] typec port0: failed to register partner (-17)
...
[91225.061491][ T319] Unable to handle kernel NULL pointer dereference
at virtual address 000000000000039f
[91225.274642][ T319] pc : tcpm_pd_data_request+0x310/0x13fc
[91225.274646][ T319] lr : tcpm_pd_data_request+0x298/0x13fc
[91225.308067][ T319] Call trace:
[91225.308070][ T319] tcpm_pd_data_request+0x310/0x13fc
[91225.308073][ T319] tcpm_pd_rx_handler+0x100/0x9e8
[91225.355900][ T319] kthread_worker_fn+0x178/0x58c
[91225.355902][ T319] kthread+0x150/0x200
[91225.355905][ T319] ret_from_fork+0x10/0x30
Add a check for port->partner to avoid dereferencing a NULL pointer.
EPSS Score: 0.04%
December 20th, 2024 (4 months ago)
|
|
CVE-2023-52876 |
Description: In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt7629-eth: Add check for mtk_alloc_clk_data
Add the check for the return value of mtk_alloc_clk_data() in order to
avoid NULL pointer dereference.
EPSS Score: 0.04%
December 20th, 2024 (4 months ago)
|
|
CVE-2023-52875 |
Description: In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt2701: Add check for mtk_alloc_clk_data
Add the check for the return value of mtk_alloc_clk_data() in order to
avoid NULL pointer dereference.
EPSS Score: 0.04%
December 20th, 2024 (4 months ago)
|
|
CVE-2023-52874 |
Description: In the Linux kernel, the following vulnerability has been resolved:
x86/tdx: Zero out the missing RSI in TDX_HYPERCALL macro
In the TDX_HYPERCALL asm, after the TDCALL instruction returns from the
untrusted VMM, the registers that the TDX guest shares to the VMM need
to be cleared to avoid speculative execution of VMM-provided values.
RSI is specified in the bitmap of those registers, but it is missing
when zeroing out those registers in the current TDX_HYPERCALL.
It was there when it was originally added in commit 752d13305c78
("x86/tdx: Expand __tdx_hypercall() to handle more arguments"), but was
later removed in commit 1e70c680375a ("x86/tdx: Do not corrupt
frame-pointer in __tdx_hypercall()"), which was correct because %rsi is
later restored in the "pop %rsi". However a later commit 7a3a401874be
("x86/tdx: Drop flags from __tdx_hypercall()") removed that "pop %rsi"
but forgot to add the "xor %rsi, %rsi" back.
Fix by adding it back.
EPSS Score: 0.05%
December 20th, 2024 (4 months ago)
|
|
CVE-2023-52873 |
Description: In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt6779: Add check for mtk_alloc_clk_data
Add the check for the return value of mtk_alloc_clk_data() in order to
avoid NULL pointer dereference.
EPSS Score: 0.04%
December 20th, 2024 (4 months ago)
|