Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix null pointer dereference in resolve_prog_type() for BPF_PROG_TYPE_EXT<br /> <br /> When loading a EXT program without specifying `attr-&gt;attach_prog_fd`,<br /> the `prog-&gt;aux-&gt;dst_prog` will be null. At this time, calling<br /> resolve_prog_type() anywhere will result in a null pointer dereference.<br /> <br /> Example stack trace:<br /> <br /> [ 8.107863] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004<br /> [ 8.108262] Mem abort info:<br /> [ 8.108384] ESR = 0x0000000096000004<br /> [ 8.108547] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 8.108722] SET = 0, FnV = 0<br /> [ 8.108827] EA = 0, S1PTW = 0<br /> [ 8.108939] FSC = 0x04: level 0 translation fault<br /> [ 8.109102] Data abort info:<br /> [ 8.109203] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> [ 8.109399] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 8.109614] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 8.109836] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101354000<br /> [ 8.110011] [0000000000000004] pgd=0000000000000000, p4d=0000000000000000<br /> [ 8.112624] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP<br /> [ 8.112783] Modules linked in:<br /> [ 8.113120] CPU: 0 PID: 99 Comm: may_access_dire Not tainted 6.10.0-rc3-next-20240613-dirty #1<br /> [ 8.113230] Hardware name: linux,dummy-virt (DT)<br /> [ 8.113390] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 8.113429] pc : may_access_direct_pkt_data+0x24/0xa0<br /> [ 8.113746] lr : add_subprog_and_kfunc+0x634/0x8e8<br /> [ 8.113798] sp : ffff80008283b9f0<br /> [ 8.113813] x29: ffff80008283b9f0 x28: ffff800082795048 x27: 0000000000000001<br /> [ 8.113881] x26: ffff0000c0bb2600 x25: 0000000000000000 x24: 0000000000000000<br /> [ 8.113897] x23: ffff0000c1134000 x22: 000000000001864f x21: ffff0000c1138000<br /> [ 8.113912] x20: 0000000000000001 x19: ffff0000c12b8000 x18: ffffffffffffffff<br /> [ 8.113929] x17: 0000000000000000 x16: 0000000000000000 x15: 0720072007200720<br /> [ 8.113944] x14: 0720072007200720 x13: 0720072007200720 x12: 0720072007200720<br /> [ 8.113958] x11: 0720072007200720 x10: 0000000000f9fca4 x9 : ffff80008021f4e4<br /> [ 8.113991] x8 : 0101010101010101 x7 : 746f72705f6d656d x6 : 000000001e0e0f5f<br /> [ 8.114006] x5 : 000000000001864f x4 : ffff0000c12b8000 x3 : 000000000000001c<br /> [ 8.114020] x2 : 0000000000000002 x1 : 0000000000000000 x0 : 0000000000000000<br /> [ 8.114126] Call trace:<br /> [ 8.114159] may_access_direct_pkt_data+0x24/0xa0<br /> [ 8.114202] bpf_check+0x3bc/0x28c0<br /> [ 8.114214] bpf_prog_load+0x658/0xa58<br /> [ 8.114227] __sys_bpf+0xc50/0x2250<br /> [ 8.114240] __arm64_sys_bpf+0x28/0x40<br /> [ 8.114254] invoke_syscall.constprop.0+0x54/0xf0<br /> [ 8.114273] do_el0_svc+0x4c/0xd8<br /> [ 8.114289] el0_svc+0x3c/0x140<br /> [ 8.114305] el0t_64_sync_handler+0x134/0x150<br /> [ 8.114331] el0t_64_sync+0x168/0x170<br /> [ 8.114477] Code: 7100707f 54000081 f9401c00 f9403800 (b9400403)<br /> [ 8.118672] ---[ end trace 0000000000000000 ]---<br /> <br /> One way to fix it is by forcing `attach_prog_fd` non-empty when<br /> bpf_prog_load(). But this will lead to `libbpf_probe_bpf_prog_type`<br /> API broken which use verifier log to probe prog type and will log<br /> nothing if we reject invalid EXT prog before bpf_check().<br /> <br /> Another way is by adding null check in resolve_prog_type().<br /> <br /> The issue was introduced by commit 4a9c7bbe2ed4 ("bpf: Resolve to<br /> prog-&gt;aux-&gt;dst_prog-&gt;type only for BPF_PROG_TYPE_EXT") which wanted<br /> to correct type resolution for BPF_PROG_TYPE_TRACING programs. Before<br /> that, the type resolution of BPF_PROG_TYPE_EXT prog actually follows<br /> the logic below:<br /> <br /> prog-&gt;aux-&gt;dst_prog ? prog-&gt;aux-&gt;dst_prog-&gt;type : prog-&gt;type;<br /> <br /> It implies that when EXT program is not yet attached to `dst_prog`,<br /> the prog type should be EXT itself. This code worked fine in the past.<br /> So just keep using it.<br /> <br /> Fix this by returning `prog-&gt;type` for BPF_PROG_TYPE_EXT if `dst_prog`<br /> is not present in resolve_prog_type().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bna: adjust &amp;#39;name&amp;#39; buf size of bna_tcb and bna_ccb structures<br /> <br /> To have enough space to write all possible sprintf() args. Currently<br /> &amp;#39;name&amp;#39; size is 16, but the first &amp;#39;%s&amp;#39; specifier may already need at<br /> least 16 characters, since &amp;#39;bnad-&gt;netdev-&gt;name&amp;#39; is used there.<br /> <br /> For &amp;#39;%d&amp;#39; specifiers, assume that they require:<br /> * 1 char for &amp;#39;tx_id + tx_info-&gt;tcb[i]-&gt;id&amp;#39; sum, BNAD_MAX_TXQ_PER_TX is 8<br /> * 2 chars for &amp;#39;rx_id + rx_info-&gt;rx_ctrl[i].ccb-&gt;id&amp;#39;, BNAD_MAX_RXP_PER_RX<br /> is 16<br /> <br /> And replace sprintf with snprintf.<br /> <br /> Detected using the static analysis tool - Svace.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: virt_wifi: avoid reporting connection success with wrong SSID<br /> <br /> When user issues a connection with a different SSID than the one<br /> virt_wifi has advertised, the __cfg80211_connect_result() will<br /> trigger the warning: WARN_ON(bss_not_found).<br /> <br /> The issue is because the connection code in virt_wifi does not<br /> check the SSID from user space (it only checks the BSSID), and<br /> virt_wifi will call cfg80211_connect_result() with WLAN_STATUS_SUCCESS<br /> even if the SSID is different from the one virt_wifi has advertised.<br /> Eventually cfg80211 won&amp;#39;t be able to find the cfg80211_bss and generate<br /> the warning.<br /> <br /> Fixed it by checking the SSID (from user space) in the connection code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: Fix array index mistake in rtw89_sta_info_get_iter()<br /> <br /> In rtw89_sta_info_get_iter() &amp;#39;status-&gt;he_gi&amp;#39; is compared to array size.<br /> But then &amp;#39;rate-&gt;he_gi&amp;#39; is used as array index instead of &amp;#39;status-&gt;he_gi&amp;#39;.<br /> This can lead to go beyond array boundaries in case of &amp;#39;rate-&gt;he_gi&amp;#39; is<br /> not equal to &amp;#39;status-&gt;he_gi&amp;#39; and is bigger than array size. Looks like<br /> "copy-paste" mistake.<br /> <br /> Fix this mistake by replacing &amp;#39;rate-&gt;he_gi&amp;#39; with &amp;#39;status-&gt;he_gi&amp;#39;.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> lib: objagg: Fix general protection fault<br /> <br /> The library supports aggregation of objects into other objects only if<br /> the parent object does not have a parent itself. That is, nesting is not<br /> supported.<br /> <br /> Aggregation happens in two cases: Without and with hints, where hints<br /> are a pre-computed recommendation on how to aggregate the provided<br /> objects.<br /> <br /> Nesting is not possible in the first case due to a check that prevents<br /> it, but in the second case there is no check because the assumption is<br /> that nesting cannot happen when creating objects based on hints. The<br /> violation of this assumption leads to various warnings and eventually to<br /> a general protection fault [1].<br /> <br /> Before fixing the root cause, error out when nesting happens and warn.<br /> <br /> [1]<br /> general protection fault, probably for non-canonical address 0xdead000000000d90: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 1 PID: 1083 Comm: kworker/1:9 Tainted: G W 6.9.0-rc6-custom-gd9b4f1cca7fb #7<br /> Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019<br /> Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work<br /> RIP: 0010:mlxsw_sp_acl_erp_bf_insert+0x25/0x80<br /> [...]<br /> Call Trace:<br /> <br /> mlxsw_sp_acl_atcam_entry_add+0x256/0x3c0<br /> mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0<br /> mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270<br /> mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510<br /> process_one_work+0x151/0x370<br /> worker_thread+0x2cb/0x3e0<br /> kthread+0xd0/0x100<br /> ret_from_fork+0x34/0x50<br /> ret_from_fork_asm+0x1a/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kvm: s390: Reject memory region operations for ucontrol VMs<br /> <br /> This change rejects the KVM_SET_USER_MEMORY_REGION and<br /> KVM_SET_USER_MEMORY_REGION2 ioctls when called on a ucontrol VM.<br /> This is necessary since ucontrol VMs have kvm-&gt;arch.gmap set to 0 and<br /> would thus result in a null pointer dereference further in.<br /> Memory management needs to be performed in userspace and using the<br /> ioctls KVM_S390_UCAS_MAP and KVM_S390_UCAS_UNMAP.<br /> <br /> Also improve s390 specific documentation for KVM_SET_USER_MEMORY_REGION<br /> and KVM_SET_USER_MEMORY_REGION2.<br /> <br /> [frankja@linux.ibm.com: commit message spelling fix, subject prefix fix]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm-raid: Fix WARN_ON_ONCE check for sync_thread in raid_resume<br /> <br /> rm-raid devices will occasionally trigger the following warning when<br /> being resumed after a table load because DM_RECOVERY_RUNNING is set:<br /> <br /> WARNING: CPU: 7 PID: 5660 at drivers/md/dm-raid.c:4105 raid_resume+0xee/0x100 [dm_raid]<br /> <br /> The failing check is:<br /> WARN_ON_ONCE(test_bit(MD_RECOVERY_RUNNING, &amp;mddev-&gt;recovery));<br /> <br /> This check is designed to make sure that the sync thread isn&amp;#39;t<br /> registered, but md_check_recovery can set MD_RECOVERY_RUNNING without<br /> the sync_thread ever getting registered. Instead of checking if<br /> MD_RECOVERY_RUNNING is set, check if sync_thread is non-NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Fix a possible null pointer dereference<br /> <br /> In function lpfc_xcvr_data_show, the memory allocation with kmalloc might<br /> fail, thereby making rdp_context a null pointer. In the following context<br /> and functions that use this pointer, there are dereferencing operations,<br /> leading to null pointer dereference.<br /> <br /> To fix this issue, a null pointer check should be added. If it is null,<br /> use scnprintf to notify the user and return len.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoc: PCM6240: Return directly after a failed devm_kzalloc() in pcmdevice_i2c_probe()<br /> <br /> The value “-ENOMEM” was assigned to the local variable “ret”<br /> in one if branch after a devm_kzalloc() call failed at the beginning.<br /> This error code will trigger then a pcmdevice_remove() call with a passed<br /> null pointer so that an undesirable dereference will be performed.<br /> Thus return the appropriate error code directly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: endpoint: pci-epf-test: Make use of cached &amp;#39;epc_features&amp;#39; in pci_epf_test_core_init()<br /> <br /> Instead of getting the epc_features from pci_epc_get_features() API, use<br /> the cached pci_epf_test::epc_features value to avoid the NULL check. Since<br /> the NULL check is already performed in pci_epf_test_bind(), having one more<br /> check in pci_epf_test_core_init() is redundant and it is not possible to<br /> hit the NULL pointer dereference.<br /> <br /> Also with commit a01e7214bef9 ("PCI: endpoint: Remove "core_init_notifier"<br /> flag"), &amp;#39;epc_features&amp;#39; got dereferenced without the NULL check, leading to<br /> the following false positive Smatch warning:<br /> <br /> drivers/pci/endpoint/functions/pci-epf-test.c:784 pci_epf_test_core_init() error: we previously assumed &amp;#39;epc_features&amp;#39; could be null (see line 747)<br /> <br /> Thus, remove the redundant NULL check and also use the epc_features::<br /> {msix_capable/msi_capable} flags directly to avoid local variables.<br /> <br /> [kwilczynski: commit log]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: Fix the sorting functionality in iio_gts_build_avail_time_table<br /> <br /> The sorting in iio_gts_build_avail_time_table is not working as intended.<br /> It could result in an out-of-bounds access when the time is zero.<br /> <br /> Here are more details:<br /> <br /> 1. When the gts-&gt;itime_table[i].time_us is zero, e.g., the time<br /> sequence is `3, 0, 1`, the inner for-loop will not terminate and do<br /> out-of-bound writes. This is because once `times[j] &gt; new`, the value<br /> `new` will be added in the current position and the `times[j]` will be<br /> moved to `j+1` position, which makes the if-condition always hold.<br /> Meanwhile, idx will be added one, making the loop keep running without<br /> termination and out-of-bound write.<br /> 2. If none of the gts-&gt;itime_table[i].time_us is zero, the elements<br /> will just be copied without being sorted as described in the comment<br /> "Sort times from all tables to one and remove duplicates".<br /> <br /> For more details, please refer to<br /> https://lore.kernel.org/all/6dd0d822-046c-4dd2-9532-79d7ab96ec05@gmail.com.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfs: pass explicit offset/count to trace events<br /> <br /> nfs_folio_length is unsafe to use without having the folio locked and a<br /> check for a NULL -&gt;f_mapping that protects against truncations and can<br /> lead to kernel crashes. E.g. when running xfstests generic/065 with<br /> all nfs trace points enabled.<br /> <br /> Follow the model of the XFS trace points and pass in an explіcit offset<br /> and length. This has the additional benefit that these values can<br /> be more accurate as some of the users touch partial folio ranges.