| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Make it so that a waiting process can be aborted
When sendmsg() creates an rxrpc call, it queues it to wait for a connection
and channel to be assigned and then waits before it can start shovelling
data as the encrypted DATA packet content includes a summary of the
connection parameters.
However, sendmsg() may get interrupted before a connection gets assigned
and further sendmsg() calls will fail with EBUSY until an assignment is
made.
Fix this so that the call can at least be aborted without failing on
EBUSY. We have to be careful here as sendmsg() mustn't be allowed to start
the call timer if the call doesn't yet have a connection assigned as an
oops may follow shortly thereafter. |
| In the Linux kernel, the following vulnerability has been resolved:
nubus: Partially revert proc_create_single_data() conversion
The conversion to proc_create_single_data() introduced a regression
whereby reading a file in /proc/bus/nubus results in a seg fault:
# grep -r . /proc/bus/nubus/e/
Data read fault at 0x00000020 in Super Data (pc=0x1074c2)
BAD KERNEL BUSERR
Oops: 00000000
Modules linked in:
PC: [<001074c2>] PDE_DATA+0xc/0x16
SR: 2010 SP: 38284958 a2: 01152370
d0: 00000001 d1: 01013000 d2: 01002790 d3: 00000000
d4: 00000001 d5: 0008ce2e a0: 00000000 a1: 00222a40
Process grep (pid: 45, task=142f8727)
Frame format=B ssw=074d isc=2008 isb=4e5e daddr=00000020 dobuf=01199e70
baddr=001074c8 dibuf=ffffffff ver=f
Stack from 01199e48:
01199e70 00222a58 01002790 00000000 011a3000 01199eb0 015000c0 00000000
00000000 01199ec0 01199ec0 000d551a 011a3000 00000001 00000000 00018000
d003f000 00000003 00000001 0002800d 01052840 01199fa8 c01f8000 00000000
00000029 0b532b80 00000000 00000000 00000029 0b532b80 01199ee4 00103640
011198c0 d003f000 00018000 01199fa8 00000000 011198c0 00000000 01199f4c
000b3344 011198c0 d003f000 00018000 01199fa8 00000000 00018000 011198c0
Call Trace: [<00222a58>] nubus_proc_rsrc_show+0x18/0xa0
[<000d551a>] seq_read+0xc4/0x510
[<00018000>] fp_fcos+0x2/0x82
[<0002800d>] __sys_setreuid+0x115/0x1c6
[<00103640>] proc_reg_read+0x5c/0xb0
[<00018000>] fp_fcos+0x2/0x82
[<000b3344>] __vfs_read+0x2c/0x13c
[<00018000>] fp_fcos+0x2/0x82
[<00018000>] fp_fcos+0x2/0x82
[<000b8aa2>] sys_statx+0x60/0x7e
[<000b34b6>] vfs_read+0x62/0x12a
[<00018000>] fp_fcos+0x2/0x82
[<00018000>] fp_fcos+0x2/0x82
[<000b39c2>] ksys_read+0x48/0xbe
[<00018000>] fp_fcos+0x2/0x82
[<000b3a4e>] sys_read+0x16/0x1a
[<00018000>] fp_fcos+0x2/0x82
[<00002b84>] syscall+0x8/0xc
[<00018000>] fp_fcos+0x2/0x82
[<0000c016>] not_ext+0xa/0x18
Code: 4e5e 4e75 4e56 0000 206e 0008 2068 ffe8 <2068> 0020 2008 4e5e 4e75 4e56 0000 2f0b 206e 0008 2068 0004 2668 0020 206b ffe8
Disabling lock debugging due to kernel taint
Segmentation fault
The proc_create_single_data() conversion does not work because
single_open(file, nubus_proc_rsrc_show, PDE_DATA(inode)) is not
equivalent to the original code. |
| In the Linux kernel, the following vulnerability has been resolved:
arm64: efi: Make efi_rt_lock a raw_spinlock
Running a rt-kernel base on 6.2.0-rc3-rt1 on an Ampere Altra outputs
the following:
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 9, name: kworker/u320:0
preempt_count: 2, expected: 0
RCU nest depth: 0, expected: 0
3 locks held by kworker/u320:0/9:
#0: ffff3fff8c27d128 ((wq_completion)efi_rts_wq){+.+.}-{0:0}, at: process_one_work (./include/linux/atomic/atomic-long.h:41)
#1: ffff80000861bdd0 ((work_completion)(&efi_rts_work.work)){+.+.}-{0:0}, at: process_one_work (./include/linux/atomic/atomic-long.h:41)
#2: ffffdf7e1ed3e460 (efi_rt_lock){+.+.}-{3:3}, at: efi_call_rts (drivers/firmware/efi/runtime-wrappers.c:101)
Preemption disabled at:
efi_virtmap_load (./arch/arm64/include/asm/mmu_context.h:248)
CPU: 0 PID: 9 Comm: kworker/u320:0 Tainted: G W 6.2.0-rc3-rt1
Hardware name: WIWYNN Mt.Jade Server System B81.03001.0005/Mt.Jade Motherboard, BIOS 1.08.20220218 (SCP: 1.08.20220218) 2022/02/18
Workqueue: efi_rts_wq efi_call_rts
Call trace:
dump_backtrace (arch/arm64/kernel/stacktrace.c:158)
show_stack (arch/arm64/kernel/stacktrace.c:165)
dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4))
dump_stack (lib/dump_stack.c:114)
__might_resched (kernel/sched/core.c:10134)
rt_spin_lock (kernel/locking/rtmutex.c:1769 (discriminator 4))
efi_call_rts (drivers/firmware/efi/runtime-wrappers.c:101)
[...]
This seems to come from commit ff7a167961d1 ("arm64: efi: Execute
runtime services from a dedicated stack") which adds a spinlock. This
spinlock is taken through:
efi_call_rts()
\-efi_call_virt()
\-efi_call_virt_pointer()
\-arch_efi_call_virt_setup()
Make 'efi_rt_lock' a raw_spinlock to avoid being preempted.
[ardb: The EFI runtime services are called with a different set of
translation tables, and are permitted to use the SIMD registers.
The context switch code preserves/restores neither, and so EFI
calls must be made with preemption disabled, rather than only
disabling migration.] |
| In the Linux kernel, the following vulnerability has been resolved:
sched/fair: Don't balance task to its current running CPU
We've run into the case that the balancer tries to balance a migration
disabled task and trigger the warning in set_task_cpu() like below:
------------[ cut here ]------------
WARNING: CPU: 7 PID: 0 at kernel/sched/core.c:3115 set_task_cpu+0x188/0x240
Modules linked in: hclgevf xt_CHECKSUM ipt_REJECT nf_reject_ipv4 <...snip>
CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G O 6.1.0-rc4+ #1
Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V5.B221.01 12/09/2021
pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : set_task_cpu+0x188/0x240
lr : load_balance+0x5d0/0xc60
sp : ffff80000803bc70
x29: ffff80000803bc70 x28: ffff004089e190e8 x27: ffff004089e19040
x26: ffff007effcabc38 x25: 0000000000000000 x24: 0000000000000001
x23: ffff80000803be84 x22: 000000000000000c x21: ffffb093e79e2a78
x20: 000000000000000c x19: ffff004089e19040 x18: 0000000000000000
x17: 0000000000001fad x16: 0000000000000030 x15: 0000000000000000
x14: 0000000000000003 x13: 0000000000000000 x12: 0000000000000000
x11: 0000000000000001 x10: 0000000000000400 x9 : ffffb093e4cee530
x8 : 00000000fffffffe x7 : 0000000000ce168a x6 : 000000000000013e
x5 : 00000000ffffffe1 x4 : 0000000000000001 x3 : 0000000000000b2a
x2 : 0000000000000b2a x1 : ffffb093e6d6c510 x0 : 0000000000000001
Call trace:
set_task_cpu+0x188/0x240
load_balance+0x5d0/0xc60
rebalance_domains+0x26c/0x380
_nohz_idle_balance.isra.0+0x1e0/0x370
run_rebalance_domains+0x6c/0x80
__do_softirq+0x128/0x3d8
____do_softirq+0x18/0x24
call_on_irq_stack+0x2c/0x38
do_softirq_own_stack+0x24/0x3c
__irq_exit_rcu+0xcc/0xf4
irq_exit_rcu+0x18/0x24
el1_interrupt+0x4c/0xe4
el1h_64_irq_handler+0x18/0x2c
el1h_64_irq+0x74/0x78
arch_cpu_idle+0x18/0x4c
default_idle_call+0x58/0x194
do_idle+0x244/0x2b0
cpu_startup_entry+0x30/0x3c
secondary_start_kernel+0x14c/0x190
__secondary_switched+0xb0/0xb4
---[ end trace 0000000000000000 ]---
Further investigation shows that the warning is superfluous, the migration
disabled task is just going to be migrated to its current running CPU.
This is because that on load balance if the dst_cpu is not allowed by the
task, we'll re-select a new_dst_cpu as a candidate. If no task can be
balanced to dst_cpu we'll try to balance the task to the new_dst_cpu
instead. In this case when the migration disabled task is not on CPU it
only allows to run on its current CPU, load balance will select its
current CPU as new_dst_cpu and later triggers the warning above.
The new_dst_cpu is chosen from the env->dst_grpmask. Currently it
contains CPUs in sched_group_span() and if we have overlapped groups it's
possible to run into this case. This patch makes env->dst_grpmask of
group_balance_mask() which exclude any CPUs from the busiest group and
solve the issue. For balancing in a domain with no overlapped groups
the behaviour keeps same as before. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: nSVM: Load L1's TSC multiplier based on L1 state, not L2 state
When emulating nested VM-Exit, load L1's TSC multiplier if L1's desired
ratio doesn't match the current ratio, not if the ratio L1 is using for
L2 diverges from the default. Functionally, the end result is the same
as KVM will run L2 with L1's multiplier if L2's multiplier is the default,
i.e. checking that L1's multiplier is loaded is equivalent to checking if
L2 has a non-default multiplier.
However, the assertion that TSC scaling is exposed to L1 is flawed, as
userspace can trigger the WARN at will by writing the MSR and then
updating guest CPUID to hide the feature (modifying guest CPUID is
allowed anytime before KVM_RUN). E.g. hacking KVM's state_test
selftest to do
vcpu_set_msr(vcpu, MSR_AMD64_TSC_RATIO, 0);
vcpu_clear_cpuid_feature(vcpu, X86_FEATURE_TSCRATEMSR);
after restoring state in a new VM+vCPU yields an endless supply of:
------------[ cut here ]------------
WARNING: CPU: 10 PID: 206939 at arch/x86/kvm/svm/nested.c:1105
nested_svm_vmexit+0x6af/0x720 [kvm_amd]
Call Trace:
nested_svm_exit_handled+0x102/0x1f0 [kvm_amd]
svm_handle_exit+0xb9/0x180 [kvm_amd]
kvm_arch_vcpu_ioctl_run+0x1eab/0x2570 [kvm]
kvm_vcpu_ioctl+0x4c9/0x5b0 [kvm]
? trace_hardirqs_off+0x4d/0xa0
__se_sys_ioctl+0x7a/0xc0
__x64_sys_ioctl+0x21/0x30
do_syscall_64+0x41/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Unlike the nested VMRUN path, hoisting the svm->tsc_scaling_enabled check
into the if-statement is wrong as KVM needs to ensure L1's multiplier is
loaded in the above scenario. Alternatively, the WARN_ON() could simply
be deleted, but that would make KVM's behavior even more subtle, e.g. it's
not immediately obvious why it's safe to write MSR_AMD64_TSC_RATIO when
checking only tsc_ratio_msr. |
| In the Linux kernel, the following vulnerability has been resolved:
ublk: fail to recover device if queue setup is interrupted
In ublk_ctrl_end_recovery(), if wait_for_completion_interruptible() is
interrupted by signal, queues aren't setup successfully yet, so we
have to fail UBLK_CMD_END_USER_RECOVERY, otherwise kernel oops can be
triggered. |
| An issue was discovered in the PCI Express (PCIe) Integrity and Data Encryption (IDE) specification, where insufficient guidance on re-keying and stream flushing during device rebinding may allow stale write transactions from a previous security context to be processed in a new one. This can lead to unintended data access across trusted domains, compromising confidentiality and integrity. |
| A vulnerability was discovered in the PCI Express (PCIe) Integrity and Data Encryption (IDE) specification, where insufficient guidance on tag reuse after completion timeouts may allow multiple outstanding Non-Posted Requests to share the same tag. This tag aliasing condition can result in completions being delivered to the wrong security context, potentially compromising data integrity and confidentiality. |
| An issue was discovered in the PCI Express (PCIe) Integrity and Data Encryption (IDE) specification, where insufficient guidance on Transaction Layer Packet (TLP) ordering and tag uniqueness may allow encrypted packets to be replayed or reordered without detection. This can enable local or physical attackers on the PCIe bus to violate data integrity protections. |
| Arbitrary directory creation in GalaxyBudsManager PC prior to version 2.1.240315.51 allows attacker to create arbitrary directory. |
| A vulnerability in the implementation of Network Address Translation (NAT) functionality in Cisco IOS 12.4 through 15.6 could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device. The vulnerability is due to the improper translation of H.323 messages that use the Registration, Admission, and Status (RAS) protocol and are sent to an affected device via IPv4 packets. An attacker could exploit this vulnerability by sending a crafted H.323 RAS packet through an affected device. A successful exploit could allow the attacker to cause the affected device to crash and reload, resulting in a DoS condition. This vulnerability affects Cisco devices that are configured to use an application layer gateway with NAT (NAT ALG) for H.323 RAS messages. By default, a NAT ALG is enabled for H.323 RAS messages. Cisco Bug IDs: CSCvc57217. |
| Dell PowerProtect Cyber Recovery, versions prior to 19.18.0.2, contains an Insertion of Sensitive Information Into Sent Data vulnerability. A high privileged attacker with remote access could potentially exploit this vulnerability, leading to Information exposure. |
| An exposure of sensitive information to an unauthorized actor vulnerability in Fortinet FortiSandbox 4.4.0 through 4.4.4, FortiSandbox 4.2.1 through 4.2.6, FortiSandbox 4.0 all versions, FortiSandbox 3.2.2 through 3.2.4, FortiSandbox 3.1.5 allows attacker to information disclosure via HTTP get requests. |
| An exposure of sensitive information to an unauthorized actor vulnerability [CWE-200] in Fortinet FortiADC version 7.4.0, version 7.2.3 and below, version 7.1.4 and below, 7.0 all versions, 6.2 all versions may allow an authenticated attacker to obtain sensitive data via crafted HTTP or HTTPs requests. |
| A exposure of sensitive system information to an unauthorized control sphere vulnerability in Fortinet FortiClientWindows 7.2.0 through 7.2.1, FortiClientWindows 7.0.13 through 7.0.14 may allow an unauthorized remote attacker to view application information via navigation to a hosted webpage, if Windows is configured to accept incoming connections to port 8053 (non-default setup) |
| A key management errors vulnerability in Fortinet FortiAnalyzer 7.4.0 through 7.4.2, FortiAnalyzer 7.2.0 through 7.2.5, FortiAnalyzer 7.0 all versions, FortiAnalyzer 6.4 all versions, FortiManager 7.4.0 through 7.4.2, FortiManager 7.2.0 through 7.2.5, FortiManager 7.0 all versions, FortiManager 6.4 all versions, FortiOS 7.6.0, FortiOS 7.4.4, FortiOS 7.2.7, FortiOS 7.0.14, FortiPortal 6.0 all versions may allow an authenticated admin to retrieve a certificate's private key via the device's admin shell. |
| The issue was addressed with improved bounds checks. This issue is fixed in watchOS 9.5, tvOS 16.5, macOS Ventura 13.4, iOS 15.7.8 and iPadOS 15.7.8, Safari 16.5, iOS 16.5 and iPadOS 16.5. A remote attacker may be able to break out of Web Content sandbox. Apple is aware of a report that this issue may have been actively exploited. |
| Vulnerability in the BI Publisher (formerly XML Publisher) component of Oracle Fusion Middleware (subcomponent: BI Publisher Security). Supported versions that are affected are 11.1.1.9.0, 12.2.1.3.0 and 12.2.1.4.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise BI Publisher (formerly XML Publisher). While the vulnerability is in BI Publisher (formerly XML Publisher), attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of BI Publisher (formerly XML Publisher) accessible data as well as unauthorized read access to a subset of BI Publisher (formerly XML Publisher) accessible data. CVSS 3.0 Base Score 7.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N). |
| A vulnerability in the Border Gateway Protocol (BGP) over an Ethernet Virtual Private Network (EVPN) for Cisco IOS XE Software could allow an unauthenticated, remote attacker to cause the device to reload, resulting in a denial of service (DoS) condition, or potentially corrupt the BGP routing table, which could result in network instability. The vulnerability exists due to changes in the implementation of the BGP MPLS-Based Ethernet VPN RFC (RFC 7432) draft between IOS XE software releases. When the BGP Inclusive Multicast Ethernet Tag Route or BGP EVPN MAC/IP Advertisement Route update packet is received, it could be possible that the IP address length field is miscalculated. An attacker could exploit this vulnerability by sending a crafted BGP packet to an affected device after the BGP session was established. An exploit could allow the attacker to cause the affected device to reload or corrupt the BGP routing table; either outcome would result in a DoS. The vulnerability may be triggered when the router receives a crafted BGP message from a peer on an existing BGP session. This vulnerability affects all releases of Cisco IOS XE Software prior to software release 16.3 that support BGP EVPN configurations. If the device is not configured for EVPN, it is not vulnerable. Cisco Bug IDs: CSCui67191, CSCvg52875. |
| A vulnerability in the crypto engine of the Cisco Integrated Services Module for VPN (ISM-VPN) running Cisco IOS Software could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device. The vulnerability is due to insufficient handling of VPN traffic by the affected device. An attacker could exploit this vulnerability by sending crafted VPN traffic to an affected device. A successful exploit could allow the attacker to cause the affected device to hang or crash, resulting in a DoS condition. Cisco Bug IDs: CSCvd39267. |
