Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix WARNING "do not call blocking ops when !TASK_RUNNING"<br /> <br /> wait_event_timeout() will set the state of the current<br /> task to TASK_UNINTERRUPTIBLE, before doing the condition check. This<br /> means that ksmbd_durable_scavenger_alive() will try to acquire the mutex<br /> while already in a sleeping state. The scheduler warns us by giving<br /> the following warning:<br /> <br /> do not call blocking ops when !TASK_RUNNING; state=2 set at<br /> [] prepare_to_wait_event+0x9f/0x6c0<br /> WARNING: CPU: 2 PID: 4147 at kernel/sched/core.c:10099 __might_sleep+0x12f/0x160<br /> <br /> mutex lock is not needed in ksmbd_durable_scavenger_alive().

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: null - Use spin lock instead of mutex<br /> <br /> As the null algorithm may be freed in softirq context through<br /> af_alg, use spin locks instead of mutexes to protect the default<br /> null algorithm.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix kmemleak warning for percpu hashmap<br /> <br /> Vlad Poenaru reported the following kmemleak issue:<br /> <br /> unreferenced object 0x606fd7c44ac8 (size 32):<br /> backtrace (crc 0):<br /> pcpu_alloc_noprof+0x730/0xeb0<br /> bpf_map_alloc_percpu+0x69/0xc0<br /> prealloc_init+0x9d/0x1b0<br /> htab_map_alloc+0x363/0x510<br /> map_create+0x215/0x3a0<br /> __sys_bpf+0x16b/0x3e0<br /> __x64_sys_bpf+0x18/0x20<br /> do_syscall_64+0x7b/0x150<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> Further investigation shows the reason is due to not 8-byte aligned<br /> store of percpu pointer in htab_elem_set_ptr():<br /> *(void __percpu **)(l-&gt;key + key_size) = pptr;<br /> <br /> Note that the whole htab_elem alignment is 8 (for x86_64). If the key_size<br /> is 4, that means pptr is stored in a location which is 4 byte aligned but<br /> not 8 byte aligned. In mm/kmemleak.c, scan_block() scans the memory based<br /> on 8 byte stride, so it won&amp;#39;t detect above pptr, hence reporting the memory<br /> leak.<br /> <br /> In htab_map_alloc(), we already have<br /> <br /> htab-&gt;elem_size = sizeof(struct htab_elem) +<br /> round_up(htab-&gt;map.key_size, 8);<br /> if (percpu)<br /> htab-&gt;elem_size += sizeof(void *);<br /> else<br /> htab-&gt;elem_size += round_up(htab-&gt;map.value_size, 8);<br /> <br /> So storing pptr with 8-byte alignment won&amp;#39;t cause any problem and can fix<br /> kmemleak too.<br /> <br /> The issue can be reproduced with bpf selftest as well:<br /> 1. Enable CONFIG_DEBUG_KMEMLEAK config<br /> 2. Add a getchar() before skel destroy in test_hash_map() in prog_tests/for_each.c.<br /> The purpose is to keep map available so kmemleak can be detected.<br /> 3. run &amp;#39;./test_progs -t for_each/hash_map &amp;&amp;#39; and a kmemleak should be reported.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Keep write operations atomic<br /> <br /> syzbot reported a NULL pointer dereference in __generic_file_write_iter. [1]<br /> <br /> Before the write operation is completed, the user executes ioctl[2] to clear<br /> the compress flag of the file, which causes the is_compressed() judgment to<br /> return 0, further causing the program to enter the wrong process and call the<br /> wrong ops ntfs_aops_cmpr, which triggers the null pointer dereference of<br /> write_begin.<br /> <br /> Use inode lock to synchronize ioctl and write to avoid this case.<br /> <br /> [1]<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> Mem abort info:<br /> ESR = 0x0000000086000006<br /> EC = 0x21: IABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x06: level 2 translation fault<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=000000011896d000<br /> [0000000000000000] pgd=0800000118b44403, p4d=0800000118b44403, pud=0800000117517403, pmd=0000000000000000<br /> Internal error: Oops: 0000000086000006 [#1] PREEMPT SMP<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 6427 Comm: syz-executor347 Not tainted 6.13.0-rc3-syzkaller-g573067a5a685 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024<br /> pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : 0x0<br /> lr : generic_perform_write+0x29c/0x868 mm/filemap.c:4055<br /> sp : ffff80009d4978a0<br /> x29: ffff80009d4979c0 x28: dfff800000000000 x27: ffff80009d497bc8<br /> x26: 0000000000000000 x25: ffff80009d497960 x24: ffff80008ba71c68<br /> x23: 0000000000000000 x22: ffff0000c655dac0 x21: 0000000000001000<br /> x20: 000000000000000c x19: 1ffff00013a92f2c x18: ffff0000e183aa1c<br /> x17: 0004060000000014 x16: ffff800083275834 x15: 0000000000000001<br /> x14: 0000000000000000 x13: 0000000000000001 x12: ffff0000c655dac0<br /> x11: 0000000000ff0100 x10: 0000000000ff0100 x9 : 0000000000000000<br /> x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000<br /> x5 : ffff80009d497980 x4 : ffff80009d497960 x3 : 0000000000001000<br /> x2 : 0000000000000000 x1 : ffff0000e183a928 x0 : ffff0000d60b0fc0<br /> Call trace:<br /> 0x0 (P)<br /> __generic_file_write_iter+0xfc/0x204 mm/filemap.c:4156<br /> ntfs_file_write_iter+0x54c/0x630 fs/ntfs3/file.c:1267<br /> new_sync_write fs/read_write.c:586 [inline]<br /> vfs_write+0x920/0xcf4 fs/read_write.c:679<br /> ksys_write+0x15c/0x26c fs/read_write.c:731<br /> __do_sys_write fs/read_write.c:742 [inline]<br /> __se_sys_write fs/read_write.c:739 [inline]<br /> __arm64_sys_write+0x7c/0x90 fs/read_write.c:739<br /> __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]<br /> invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49<br /> el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132<br /> do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151<br /> el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744<br /> el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762<br /> <br /> [2]<br /> ioctl$FS_IOC_SETFLAGS(r0, 0x40086602, &amp;(0x7f00000000c0)=0x20)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: spi-imx: Add check for spi_imx_setupxfer()<br /> <br /> Add check for the return value of spi_imx_setupxfer().<br /> spi_imx-&gt;rx and spi_imx-&gt;tx function pointer can be NULL when<br /> spi_imx_setupxfer() return error, and make NULL pointer dereference.<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> Call trace:<br /> 0x0<br /> spi_imx_pio_transfer+0x50/0xd8<br /> spi_imx_transfer_one+0x18c/0x858<br /> spi_transfer_one_message+0x43c/0x790<br /> __spi_pump_transfer_message+0x238/0x5d4<br /> __spi_sync+0x2b0/0x454<br /> spi_write_then_read+0x11c/0x200

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udmabuf: fix a buf size overflow issue during udmabuf creation<br /> <br /> by casting size_limit_mb to u64 when calculate pglimit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sound/virtio: Fix cancel_sync warnings on uninitialized work_structs<br /> <br /> Betty reported hitting the following warning:<br /> <br /> [ 8.709131][ T221] WARNING: CPU: 2 PID: 221 at kernel/workqueue.c:4182<br /> ...<br /> [ 8.713282][ T221] Call trace:<br /> [ 8.713365][ T221] __flush_work+0x8d0/0x914<br /> [ 8.713468][ T221] __cancel_work_sync+0xac/0xfc<br /> [ 8.713570][ T221] cancel_work_sync+0x24/0x34<br /> [ 8.713667][ T221] virtsnd_remove+0xa8/0xf8 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276]<br /> [ 8.713868][ T221] virtsnd_probe+0x48c/0x664 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276]<br /> [ 8.714035][ T221] virtio_dev_probe+0x28c/0x390<br /> [ 8.714139][ T221] really_probe+0x1bc/0x4c8<br /> ...<br /> <br /> It seems we&amp;#39;re hitting the error path in virtsnd_probe(), which<br /> triggers a virtsnd_remove() which iterates over the substreams<br /> calling cancel_work_sync() on the elapsed_period work_struct.<br /> <br /> Looking at the code, from earlier in:<br /> virtsnd_probe()-&gt;virtsnd_build_devs()-&gt;virtsnd_pcm_parse_cfg()<br /> <br /> We set snd-&gt;nsubstreams, allocate the snd-&gt;substreams, and if<br /> we then hit an error on the info allocation or something in<br /> virtsnd_ctl_query_info() fails, we will exit without having<br /> initialized the elapsed_period work_struct.<br /> <br /> When that error path unwinds we then call virtsnd_remove()<br /> which as long as the substreams array is allocated, will iterate<br /> through calling cancel_work_sync() on the uninitialized work<br /> struct hitting this warning.<br /> <br /> Takashi Iwai suggested this fix, which initializes the substreams<br /> structure right after allocation, so that if we hit the error<br /> paths we avoid trying to cleanup uninitialized data.<br /> <br /> Note: I have not yet managed to reproduce the issue myself, so<br /> this patch has had limited testing.<br /> <br /> Feedback or thoughts would be appreciated!

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> driver core: fix potential NULL pointer dereference in dev_uevent()<br /> <br /> If userspace reads "uevent" device attribute at the same time as another<br /> threads unbinds the device from its driver, change to dev-&gt;driver from a<br /> valid pointer to NULL may result in crash. Fix this by using READ_ONCE()<br /> when fetching the pointer, and take bus&amp;#39; drivers klist lock to make sure<br /> driver instance will not disappear while we access it.<br /> <br /> Use WRITE_ONCE() when setting the driver pointer to ensure there is no<br /> tearing.

The Event Manager, Events Calendar, Tickets, Registrations – Eventin plugin for WordPress is vulnerable to arbitrary file read in all versions up to, and including, 4.0.26 via the proxy_image() function. This makes it possible for unauthenticated attackers to read the contents of arbitrary files on the server, which can contain sensitive information.

The Wolmart | Multi-Vendor Marketplace WooCommerce Theme theme for WordPress is vulnerable to arbitrary shortcode execution in all versions up to, and including, 1.8.11. This is due to the software allowing users to execute an action that does not properly validate a value before running do_shortcode. This makes it possible for unauthenticated attackers to execute arbitrary shortcodes.

An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().