Archivos mensuales: agosto 2024

In the Linux kernel, the following vulnerability has been resolved:

crypto: ccp – Fix null pointer dereference in __sev_snp_shutdown_locked

Fix a null pointer dereference induced by DEBUG_TEST_DRIVER_REMOVE.
Return from __sev_snp_shutdown_locked() if the psp_device or the
sev_device structs are not initialized. Without the fix, the driver will
produce the following splat:

ccp 0000:55:00.5: enabling device (0000 -> 0002)
ccp 0000:55:00.5: sev enabled
ccp 0000:55:00.5: psp enabled
BUG: kernel NULL pointer dereference, address: 00000000000000f0
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) – not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC NOPTI
CPU: 262 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc1+ #29
RIP: 0010:__sev_snp_shutdown_locked+0x2e/0x150
Code: 00 55 48 89 e5 41 57 41 56 41 54 53 48 83 ec 10 41 89 f7 49 89 fe 65 48 8b 04 25 28 00 00 00 48 89 45 d8 48 8b 05 6a 5a 7f 06 8b a0 f0 00 00 00 41 0f b6 9c 24 a2 00 00 00 48 83 fb 02 0f 83
RSP: 0018:ffffb2ea4014b7b8 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff9e4acd2e0a28 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffb2ea4014b808
RBP: ffffb2ea4014b7e8 R08: 0000000000000106 R09: 000000000003d9c0
R10: 0000000000000001 R11: ffffffffa39ff070 R12: ffff9e49d40590c8
R13: 0000000000000000 R14: ffffb2ea4014b808 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff9e58b1e00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000000f0 CR3: 0000000418a3e001 CR4: 0000000000770ef0
PKRU: 55555554
Call Trace:

? __die_body+0x6f/0xb0
? __die+0xcc/0xf0
? page_fault_oops+0x330/0x3a0
? save_trace+0x2a5/0x360
? do_user_addr_fault+0x583/0x630
? exc_page_fault+0x81/0x120
? asm_exc_page_fault+0x2b/0x30
? __sev_snp_shutdown_locked+0x2e/0x150
__sev_firmware_shutdown+0x349/0x5b0
? pm_runtime_barrier+0x66/0xe0
sev_dev_destroy+0x34/0xb0
psp_dev_destroy+0x27/0x60
sp_destroy+0x39/0x90
sp_pci_remove+0x22/0x60
pci_device_remove+0x4e/0x110
really_probe+0x271/0x4e0
__driver_probe_device+0x8f/0x160
driver_probe_device+0x24/0x120
__driver_attach+0xc7/0x280
? driver_attach+0x30/0x30
bus_for_each_dev+0x10d/0x130
driver_attach+0x22/0x30
bus_add_driver+0x171/0x2b0
? unaccepted_memory_init_kdump+0x20/0x20
driver_register+0x67/0x100
__pci_register_driver+0x83/0x90
sp_pci_init+0x22/0x30
sp_mod_init+0x13/0x30
do_one_initcall+0xb8/0x290
? sched_clock_noinstr+0xd/0x10
? local_clock_noinstr+0x3e/0x100
? stack_depot_save_flags+0x21e/0x6a0
? local_clock+0x1c/0x60
? stack_depot_save_flags+0x21e/0x6a0
? sched_clock_noinstr+0xd/0x10
? local_clock_noinstr+0x3e/0x100
? __lock_acquire+0xd90/0xe30
? sched_clock_noinstr+0xd/0x10
? local_clock_noinstr+0x3e/0x100
? __create_object+0x66/0x100
? local_clock+0x1c/0x60
? __create_object+0x66/0x100
? parameq+0x1b/0x90
? parse_one+0x6d/0x1d0
? parse_args+0xd7/0x1f0
? do_initcall_level+0x180/0x180
do_initcall_level+0xb0/0x180
do_initcalls+0x60/0xa0
? kernel_init+0x1f/0x1d0
do_basic_setup+0x41/0x50
kernel_init_freeable+0x1ac/0x230
? rest_init+0x1f0/0x1f0
kernel_init+0x1f/0x1d0
? rest_init+0x1f0/0x1f0
ret_from_fork+0x3d/0x50
? rest_init+0x1f0/0x1f0
ret_from_fork_asm+0x11/0x20

Modules linked in:
CR2: 00000000000000f0
—[ end trace 0000000000000000 ]—
RIP: 0010:__sev_snp_shutdown_locked+0x2e/0x150
Code: 00 55 48 89 e5 41 57 41 56 41 54 53 48 83 ec 10 41 89 f7 49 89 fe 65 48 8b 04 25 28 00 00 00 48 89 45 d8 48 8b 05 6a 5a 7f 06 8b a0 f0 00 00 00 41 0f b6 9c 24 a2 00 00 00 48 83 fb 02 0f 83
RSP: 0018:ffffb2ea4014b7b8 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff9e4acd2e0a28 RCX: 0000000000000000
RDX: 0000000
—truncated—

In the Linux kernel, the following vulnerability has been resolved:

exec: Fix ToCToU between perm check and set-uid/gid usage

When opening a file for exec via do_filp_open(), permission checking is
done against the file's metadata at that moment, and on success, a file
pointer is passed back. Much later in the execve() code path, the file
metadata (specifically mode, uid, and gid) is used to determine if/how
to set the uid and gid. However, those values may have changed since the
permissions check, meaning the execution may gain unintended privileges.

For example, if a file could change permissions from executable and not
set-id:

———x 1 root root 16048 Aug 7 13:16 target

to set-id and non-executable:

—S—— 1 root root 16048 Aug 7 13:16 target

it is possible to gain root privileges when execution should have been
disallowed.

While this race condition is rare in real-world scenarios, it has been
observed (and proven exploitable) when package managers are updating
the setuid bits of installed programs. Such files start with being
world-executable but then are adjusted to be group-exec with a set-uid
bit. For example, "chmod o-x,u+s target" makes "target" executable only
by uid "root" and gid "cdrom", while also becoming setuid-root:

-rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 target

becomes:

-rwsr-xr– 1 root cdrom 16048 Aug 7 13:16 target

But racing the chmod means users without group "cdrom" membership can
get the permission to execute "target" just before the chmod, and when
the chmod finishes, the exec reaches brpm_fill_uid(), and performs the
setuid to root, violating the expressed authorization of "only cdrom
group members can setuid to root".

Re-check that we still have execute permissions in case the metadata
has changed. It would be better to keep a copy from the perm-check time,
but until we can do that refactoring, the least-bad option is to do a
full inode_permission() call (under inode lock). It is understood that
this is safe against dead-locks, but hardly optimal.

In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: change DMA direction while mapping reinjected packets

For fragmented packets, ath12k reassembles each fragment as a normal
packet and then reinjects it into HW ring. In this case, the DMA
direction should be DMA_TO_DEVICE, not DMA_FROM_DEVICE. Otherwise,
an invalid payload may be reinjected into the HW and
subsequently delivered to the host.

Given that arbitrary memory can be allocated to the skb buffer,
knowledge about the data contained in the reinjected buffer is lacking.
Consequently, there’s a risk of private information being leaked.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00209-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:

mlxsw: spectrum_acl_erp: Fix object nesting warning

ACLs in Spectrum-2 and newer ASICs can reside in the algorithmic TCAM
(A-TCAM) or in the ordinary circuit TCAM (C-TCAM). The former can
contain more ACLs (i.e., tc filters), but the number of masks in each
region (i.e., tc chain) is limited.

In order to mitigate the effects of the above limitation, the device
allows filters to share a single mask if their masks only differ in up
to 8 consecutive bits. For example, dst_ip/25 can be represented using
dst_ip/24 with a delta of 1 bit. The C-TCAM does not have a limit on the
number of masks being used (and therefore does not support mask
aggregation), but can contain a limited number of filters.

The driver uses the "objagg" library to perform the mask aggregation by
passing it objects that consist of the filter's mask and whether the
filter is to be inserted into the A-TCAM or the C-TCAM since filters in
different TCAMs cannot share a mask.

The set of created objects is dependent on the insertion order of the
filters and is not necessarily optimal. Therefore, the driver will
periodically ask the library to compute a more optimal set ("hints") by
looking at all the existing objects.

When the library asks the driver whether two objects can be aggregated
the driver only compares the provided masks and ignores the A-TCAM /
C-TCAM indication. This is the right thing to do since the goal is to
move as many filters as possible to the A-TCAM. The driver also forbids
two identical masks from being aggregated since this can only happen if
one was intentionally put in the C-TCAM to avoid a conflict in the
A-TCAM.

The above can result in the following set of hints:

H1: {mask X, A-TCAM} -> H2: {mask Y, A-TCAM} // X is Y + delta
H3: {mask Y, C-TCAM} -> H4: {mask Z, A-TCAM} // Y is Z + delta

After getting the hints from the library the driver will start migrating
filters from one region to another while consulting the computed hints
and instructing the device to perform a lookup in both regions during
the transition.

Assuming a filter with mask X is being migrated into the A-TCAM in the
new region, the hints lookup will return H1. Since H2 is the parent of
H1, the library will try to find the object associated with it and
create it if necessary in which case another hints lookup (recursive)
will be performed. This hints lookup for {mask Y, A-TCAM} will either
return H2 or H3 since the driver passes the library an object comparison
function that ignores the A-TCAM / C-TCAM indication.

This can eventually lead to nested objects which are not supported by
the library [1].

Fix by removing the object comparison function from both the driver and
the library as the driver was the only user. That way the lookup will
only return exact matches.

I do not have a reliable reproducer that can reproduce the issue in a
timely manner, but before the fix the issue would reproduce in several
minutes and with the fix it does not reproduce in over an hour.

Note that the current usefulness of the hints is limited because they
include the C-TCAM indication and represent aggregation that cannot
actually happen. This will be addressed in net-next.

[1]
WARNING: CPU: 0 PID: 153 at lib/objagg.c:170 objagg_obj_parent_assign+0xb5/0xd0
Modules linked in:
CPU: 0 PID: 153 Comm: kworker/0:18 Not tainted 6.9.0-rc6-custom-g70fbc2c1c38b #42
Hardware name: Mellanox Technologies Ltd. MSN3700C/VMOD0008, BIOS 5.11 10/10/2018
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
RIP: 0010:objagg_obj_parent_assign+0xb5/0xd0
[…]
Call Trace:

__objagg_obj_get+0x2bb/0x580
objagg_obj_get+0xe/0x80
mlxsw_sp_acl_erp_mask_get+0xb5/0xf0
mlxsw_sp_acl_atcam_entry_add+0xe8/0x3c0
mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0
mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270
mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510
process_one_work+0x151/0x370

In the Linux kernel, the following vulnerability has been resolved:

wifi: cfg80211: handle 2×996 RU allocation in cfg80211_calculate_bitrate_he()

Currently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in
cfg80211_calculate_bitrate_he(), leading to below warning:

kernel: invalid HE MCS: bw:6, ru:6
kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211]

Fix it by handling 2×996 RU allocation in the same way as 160 MHz bandwidth.

In the Linux kernel, the following vulnerability has been resolved:

xfrm: Fix input error path memory access

When there is a misconfiguration of input state slow path
KASAN report error. Fix this error.
west login:
[ 52.987278] eth1: renamed from veth11
[ 53.078814] eth1: renamed from veth21
[ 53.181355] eth1: renamed from veth31
[ 54.921702] ==================================================================
[ 54.922602] BUG: KASAN: wild-memory-access in xfrmi_rcv_cb+0x2d/0x295
[ 54.923393] Read of size 8 at addr 6b6b6b6b00000000 by task ping/512
[ 54.924169]
[ 54.924386] CPU: 0 PID: 512 Comm: ping Not tainted 6.9.0-08574-gcd29a4313a1b #25
[ 54.925290] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 54.926401] Call Trace:
[ 54.926731]
[ 54.927009] dump_stack_lvl+0x2a/0x3b
[ 54.927478] kasan_report+0x84/0xa6
[ 54.927930] ? xfrmi_rcv_cb+0x2d/0x295
[ 54.928410] xfrmi_rcv_cb+0x2d/0x295
[ 54.928872] ? xfrm4_rcv_cb+0x3d/0x5e
[ 54.929354] xfrm4_rcv_cb+0x46/0x5e
[ 54.929804] xfrm_rcv_cb+0x7e/0xa1
[ 54.930240] xfrm_input+0x1b3a/0x1b96
[ 54.930715] ? xfrm_offload+0x41/0x41
[ 54.931182] ? raw_rcv+0x292/0x292
[ 54.931617] ? nf_conntrack_confirm+0xa2/0xa2
[ 54.932158] ? skb_sec_path+0xd/0x3f
[ 54.932610] ? xfrmi_input+0x90/0xce
[ 54.933066] xfrm4_esp_rcv+0x33/0x54
[ 54.933521] ip_protocol_deliver_rcu+0xd7/0x1b2
[ 54.934089] ip_local_deliver_finish+0x110/0x120
[ 54.934659] ? ip_protocol_deliver_rcu+0x1b2/0x1b2
[ 54.935248] NF_HOOK.constprop.0+0xf8/0x138
[ 54.935767] ? ip_sublist_rcv_finish+0x68/0x68
[ 54.936317] ? secure_tcpv6_ts_off+0x23/0x168
[ 54.936859] ? ip_protocol_deliver_rcu+0x1b2/0x1b2
[ 54.937454] ? __xfrm_policy_check2.constprop.0+0x18d/0x18d
[ 54.938135] NF_HOOK.constprop.0+0xf8/0x138
[ 54.938663] ? ip_sublist_rcv_finish+0x68/0x68
[ 54.939220] ? __xfrm_policy_check2.constprop.0+0x18d/0x18d
[ 54.939904] ? ip_local_deliver_finish+0x120/0x120
[ 54.940497] __netif_receive_skb_one_core+0xc9/0x107
[ 54.941121] ? __netif_receive_skb_list_core+0x1c2/0x1c2
[ 54.941771] ? blk_mq_start_stopped_hw_queues+0xc7/0xf9
[ 54.942413] ? blk_mq_start_stopped_hw_queue+0x38/0x38
[ 54.943044] ? virtqueue_get_buf_ctx+0x295/0x46b
[ 54.943618] process_backlog+0xb3/0x187
[ 54.944102] __napi_poll.constprop.0+0x57/0x1a7
[ 54.944669] net_rx_action+0x1cb/0x380
[ 54.945150] ? __napi_poll.constprop.0+0x1a7/0x1a7
[ 54.945744] ? vring_new_virtqueue+0x17a/0x17a
[ 54.946300] ? note_interrupt+0x2cd/0x367
[ 54.946805] handle_softirqs+0x13c/0x2c9
[ 54.947300] do_softirq+0x5f/0x7d
[ 54.947727]
[ 54.948014]
[ 54.948300] __local_bh_enable_ip+0x48/0x62
[ 54.948832] __neigh_event_send+0x3fd/0x4ca
[ 54.949361] neigh_resolve_output+0x1e/0x210
[ 54.949896] ip_finish_output2+0x4bf/0x4f0
[ 54.950410] ? __ip_finish_output+0x171/0x1b8
[ 54.950956] ip_send_skb+0x25/0x57
[ 54.951390] raw_sendmsg+0xf95/0x10c0
[ 54.951850] ? check_new_pages+0x45/0x71
[ 54.952343] ? raw_hash_sk+0x21b/0x21b
[ 54.952815] ? kernel_init_pages+0x42/0x51
[ 54.953337] ? prep_new_page+0x44/0x51
[ 54.953811] ? get_page_from_freelist+0x72b/0x915
[ 54.954390] ? signal_pending_state+0x77/0x77
[ 54.954936] ? preempt_count_sub+0x14/0xb3
[ 54.955450] ? __might_resched+0x8a/0x240
[ 54.955951] ? __might_sleep+0x25/0xa0
[ 54.956424] ? first_zones_zonelist+0x2c/0x43
[ 54.956977] ? __rcu_read_lock+0x2d/0x3a
[ 54.957476] ? __pte_offset_map+0x32/0xa4
[ 54.957980] ? __might_resched+0x8a/0x240
[ 54.958483] ? __might_sleep+0x25/0xa0
[ 54.958963] ? inet_send_prepare+0x54/0x54
[ 54.959478] ? sock_sendmsg_nosec+0x42/0x6c
[ 54.960000] sock_sendmsg_nosec+0x42/0x6c
[ 54.960502] __sys_sendto+0x15d/0x1cc
[ 54.960966] ? __x64_sys_getpeername+0x44/0x44
[ 54.961522] ? __handle_mm_fault+0x679/0xae4
[ 54.962068] ? find_vma+0x6b/0x
—truncated—

In the Linux kernel, the following vulnerability has been resolved:

media: pci: ivtv: Add check for DMA map result

In case DMA fails, 'dma->SG_length' is 0. This value is later used to
access 'dma->SGarray[dma->SG_length – 1]', which will cause out of
bounds access.

Add check to return early on invalid value. Adjust warnings accordingly.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Dell SupportAssist for Home PCs Installer exe version 4.0.3 contains a privilege escalation vulnerability in the installer. A local low-privileged authenticated attacker could potentially exploit this vulnerability, leading to the execution of arbitrary executables on the operating system with elevated privileges.

** UNSUPPORTED WHEN ASSIGNED ** The Apache Helix Front (UI) component contained a hard-coded secret, allowing an attacker to spoof sessions by generating their own fake cookies.

This issue affects Apache Helix Front (UI): all versions.

As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users.

NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

In the Linux kernel, the following vulnerability has been resolved:

s390/fpu: Re-add exception handling in load_fpu_state()

With the recent rewrite of the fpu code exception handling for the
lfpc instruction within load_fpu_state() was erroneously removed.

Add it again to prevent that loading invalid floating point register
values cause an unhandled specification exception.