Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: bridge: anx7625: Fix NULL pointer dereference with early IRQ<br /> <br /> If the interrupt occurs before resource initialization is complete, the<br /> interrupt handler/worker may access uninitialized data such as the I2C<br /> tcpc_client device, potentially leading to NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: qcom: q6apm-lpass-dais: Fix NULL pointer dereference if source graph failed<br /> <br /> If earlier opening of source graph fails (e.g. ADSP rejects due to<br /> incorrect audioreach topology), the graph is closed and<br /> "dai_data-&gt;graph[dai-&gt;id]" is assigned NULL. Preparing the DAI for sink<br /> graph continues though and next call to q6apm_lpass_dai_prepare()<br /> receives dai_data-&gt;graph[dai-&gt;id]=NULL leading to NULL pointer<br /> exception:<br /> <br /> qcom-apm gprsvc:service:2:1: Error (1) Processing 0x01001002 cmd<br /> qcom-apm gprsvc:service:2:1: DSP returned error[1001002] 1<br /> q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: fail to start APM port 78<br /> q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC: error at snd_soc_pcm_dai_prepare on TX_CODEC_DMA_TX_3: -22<br /> Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a8<br /> ...<br /> Call trace:<br /> q6apm_graph_media_format_pcm+0x48/0x120 (P)<br /> q6apm_lpass_dai_prepare+0x110/0x1b4<br /> snd_soc_pcm_dai_prepare+0x74/0x108<br /> __soc_pcm_prepare+0x44/0x160<br /> dpcm_be_dai_prepare+0x124/0x1c0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm-stripe: fix a possible integer overflow<br /> <br /> There&amp;#39;s a possible integer overflow in stripe_io_hints if we have too<br /> large chunk size. Test if the overflow happened, and if it did, don&amp;#39;t set<br /> limits-&gt;io_min and limits-&gt;io_opt;

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/s390: Fix memory corruption when using identity domain<br /> <br /> zpci_get_iommu_ctrs() returns counter information to be reported as part<br /> of device statistics; these counters are stored as part of the s390_domain.<br /> The problem, however, is that the identity domain is not backed by an<br /> s390_domain and so the conversion via to_s390_domain() yields a bad address<br /> that is zero&amp;#39;d initially and read on-demand later via a sysfs read.<br /> These counters aren&amp;#39;t necessary for the identity domain; just return NULL<br /> in this case.<br /> <br /> This issue was discovered via KASAN with reports that look like:<br /> BUG: KASAN: global-out-of-bounds in zpci_fmb_enable_device<br /> when using the identity domain for a device on s390.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer<br /> <br /> Since commit 7d5e9737efda ("net: rfkill: gpio: get the name and type from<br /> device property") rfkill_find_type() gets called with the possibly<br /> uninitialized "const char *type_name;" local variable.<br /> <br /> On x86 systems when rfkill-gpio binds to a "BCM4752" or "LNV4752"<br /> acpi_device, the rfkill-&gt;type is set based on the ACPI acpi_device_id:<br /> <br /> rfkill-&gt;type = (unsigned)id-&gt;driver_data;<br /> <br /> and there is no "type" property so device_property_read_string() will fail<br /> and leave type_name uninitialized, leading to a potential crash.<br /> <br /> rfkill_find_type() does accept a NULL pointer, fix the potential crash<br /> by initializing type_name to NULL.<br /> <br /> Note likely sofar this has not been caught because:<br /> <br /> 1. Not many x86 machines actually have a "BCM4752"/"LNV4752" acpi_device<br /> 2. The stack happened to contain NULL where type_name is stored

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: ccp - Always pass in an error pointer to __sev_platform_shutdown_locked()<br /> <br /> When<br /> <br /> 9770b428b1a2 ("crypto: ccp - Move dev_info/err messages for SEV/SNP init and shutdown")<br /> <br /> moved the error messages dumping so that they don&amp;#39;t need to be issued by<br /> the callers, it missed the case where __sev_firmware_shutdown() calls<br /> __sev_platform_shutdown_locked() with a NULL argument which leads to<br /> a NULL ptr deref on the shutdown path, during suspend to disk:<br /> <br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> CPU: 0 UID: 0 PID: 983 Comm: hib.sh Not tainted 6.17.0-rc4+ #1 PREEMPT(voluntary)<br /> Hardware name: Supermicro Super Server/H12SSL-i, BIOS 2.5 09/08/2022<br /> RIP: 0010:__sev_platform_shutdown_locked.cold+0x0/0x21 [ccp]<br /> <br /> That rIP is:<br /> <br /> 00000000000006fd :<br /> 6fd: 8b 13 mov (%rbx),%edx<br /> 6ff: 48 8b 7d 00 mov 0x0(%rbp),%rdi<br /> 703: 89 c1 mov %eax,%ecx<br /> <br /> Code: 74 05 31 ff 41 89 3f 49 8b 3e 89 ea 48 c7 c6 a0 8e 54 a0 41 bf 92 ff ff ff e8 e5 2e 09 e1 c6 05 2a d4 38 00 01 e9 26 af ff ff 13 48 8b 7d 00 89 c1 48 c7 c6 18 90 54 a0 89 44 24 04 e8 c1 2e<br /> RSP: 0018:ffffc90005467d00 EFLAGS: 00010282<br /> RAX: 00000000ffffff92 RBX: 0000000000000000 RCX: 0000000000000000<br /> ^^^^^^^^^^^^^^^^<br /> and %rbx is nice and clean.<br /> <br /> Call Trace:<br /> <br /> __sev_firmware_shutdown.isra.0<br /> sev_dev_destroy<br /> psp_dev_destroy<br /> sp_destroy<br /> pci_device_shutdown<br /> device_shutdown<br /> kernel_power_off<br /> hibernate.cold<br /> state_store<br /> kernfs_fop_write_iter<br /> vfs_write<br /> ksys_write<br /> do_syscall_64<br /> entry_SYSCALL_64_after_hwframe<br /> <br /> Pass in a pointer to the function-local error var in the caller.<br /> <br /> With that addressed, suspending the ccp shows the error properly at<br /> least:<br /> <br /> ccp 0000:47:00.1: sev command 0x2 timed out, disabling PSP<br /> ccp 0000:47:00.1: SEV: failed to SHUTDOWN error 0x0, rc -110<br /> SEV-SNP: Leaking PFN range 0x146800-0x146a00<br /> SEV-SNP: PFN 0x146800 unassigned, dumping non-zero entries in 2M PFN region: [0x146800 - 0x146a00]<br /> ...<br /> ccp 0000:47:00.1: SEV-SNP firmware shutdown failed, rc -16, error 0x0<br /> ACPI: PM: Preparing to enter system sleep state S5<br /> kvm: exiting hardware virtualization<br /> reboot: Power down<br /> <br /> Btw, this driver is crying to be cleaned up to pass in a proper I/O<br /> struct which can be used to store information between the different<br /> functions, otherwise stuff like that will happen in the future again.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: codec: sma1307: Fix memory corruption in sma1307_setting_loaded()<br /> <br /> The sma1307-&gt;set.header_size is how many integers are in the header<br /> (there are 8 of them) but instead of allocating space of 8 integers<br /> we allocate 8 bytes. This leads to memory corruption when we copy data<br /> it on the next line:<br /> <br /> memcpy(sma1307-&gt;set.header, data,<br /> sma1307-&gt;set.header_size * sizeof(int));<br /> <br /> Also since we&amp;#39;re immediately copying over the memory in -&gt;set.header,<br /> there is no need to zero it in the allocator. Use devm_kmalloc_array()<br /> to allocate the memory instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: let recv_done verify data_offset, data_length and remaining_data_length<br /> <br /> This is inspired by the related server fixes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: af_alg - Set merge to zero early in af_alg_sendmsg<br /> <br /> If an error causes af_alg_sendmsg to abort, ctx-&gt;merge may contain<br /> a garbage value from the previous loop. This may then trigger a<br /> crash on the next entry into af_alg_sendmsg when it attempts to do<br /> a merge that can&amp;#39;t be done.<br /> <br /> Fix this by setting ctx-&gt;merge to zero near the start of the loop.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: let smbd_destroy() call disable_work_sync(&amp;info-&gt;post_send_credits_work)<br /> <br /> In smbd_destroy() we may destroy the memory so we better<br /> wait until post_send_credits_work is no longer pending<br /> and will never be started again.<br /> <br /> I actually just hit the case using rxe:<br /> <br /> WARNING: CPU: 0 PID: 138 at drivers/infiniband/sw/rxe/rxe_verbs.c:1032 rxe_post_recv+0x1ee/0x480 [rdma_rxe]<br /> ...<br /> [ 5305.686979] [ T138] smbd_post_recv+0x445/0xc10 [cifs]<br /> [ 5305.687135] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 5305.687149] [ T138] ? __kasan_check_write+0x14/0x30<br /> [ 5305.687185] [ T138] ? __pfx_smbd_post_recv+0x10/0x10 [cifs]<br /> [ 5305.687329] [ T138] ? __pfx__raw_spin_lock_irqsave+0x10/0x10<br /> [ 5305.687356] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 5305.687368] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 5305.687378] [ T138] ? _raw_spin_unlock_irqrestore+0x11/0x60<br /> [ 5305.687389] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 5305.687399] [ T138] ? get_receive_buffer+0x168/0x210 [cifs]<br /> [ 5305.687555] [ T138] smbd_post_send_credits+0x382/0x4b0 [cifs]<br /> [ 5305.687701] [ T138] ? __pfx_smbd_post_send_credits+0x10/0x10 [cifs]<br /> [ 5305.687855] [ T138] ? __pfx___schedule+0x10/0x10<br /> [ 5305.687865] [ T138] ? __pfx__raw_spin_lock_irq+0x10/0x10<br /> [ 5305.687875] [ T138] ? queue_delayed_work_on+0x8e/0xa0<br /> [ 5305.687889] [ T138] process_one_work+0x629/0xf80<br /> [ 5305.687908] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 5305.687917] [ T138] ? __kasan_check_write+0x14/0x30<br /> [ 5305.687933] [ T138] worker_thread+0x87f/0x1570<br /> ...<br /> <br /> It means rxe_post_recv was called after rdma_destroy_qp().<br /> This happened because put_receive_buffer() was triggered<br /> by ib_drain_qp() and called:<br /> queue_work(info-&gt;workqueue, &amp;info-&gt;post_send_credits_work);

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix smbdirect_recv_io leak in smbd_negotiate() error path<br /> <br /> During tests of another unrelated patch I was able to trigger this<br /> error: Objects remaining on __kmem_cache_shutdown()

The Trinity Audio – Text to Speech AI audio player to convert content into audio plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 5.20.2. This is due to missing or incorrect nonce validation in the &amp;#39;/admin/inc/post-management.php&amp;#39; file. This makes it possible for unauthenticated attackers to activate/deactivate posts via a forged request granted they can trick a site administrator into performing an action such as clicking on a link.