Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: validate new SA&amp;#39;s prefixlen using SA family when sel.family is unset<br /> <br /> This expands the validation introduced in commit 07bf7908950a ("xfrm:<br /> Validate address prefix lengths in the xfrm selector.")<br /> <br /> syzbot created an SA with<br /> usersa.sel.family = AF_UNSPEC<br /> usersa.sel.prefixlen_s = 128<br /> usersa.family = AF_INET<br /> <br /> Because of the AF_UNSPEC selector, verify_newsa_info doesn&amp;#39;t put<br /> limits on prefixlen_{s,d}. But then copy_from_user_state sets<br /> x-&gt;sel.family to usersa.family (AF_INET). Do the same conversion in<br /> verify_newsa_info before validating prefixlen_{s,d}, since that&amp;#39;s how<br /> prefixlen is going to be used later on.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: bnep: fix wild-memory-access in proto_unregister<br /> <br /> There&amp;#39;s issue as follows:<br /> KASAN: maybe wild-memory-access in range [0xdead...108-0xdead...10f]<br /> CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G W<br /> RIP: 0010:proto_unregister+0xee/0x400<br /> Call Trace:<br /> <br /> __do_sys_delete_module+0x318/0x580<br /> do_syscall_64+0xc1/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> As bnep_init() ignore bnep_sock_init()&amp;#39;s return value, and bnep_sock_init()<br /> will cleanup all resource. Then when remove bnep module will call<br /> bnep_sock_cleanup() to cleanup sock&amp;#39;s resource.<br /> To solve above issue just return bnep_sock_init()&amp;#39;s return value in<br /> bnep_exit().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: altmode should keep reference to parent<br /> <br /> The altmode device release refers to its parent device, but without keeping<br /> a reference to it.<br /> <br /> When registering the altmode, get a reference to the parent and put it in<br /> the release function.<br /> <br /> Before this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issues<br /> like this:<br /> <br /> [ 43.572860] kobject: &amp;#39;port0.0&amp;#39; (ffff8880057ba008): kobject_release, parent 0000000000000000 (delayed 3000)<br /> [ 43.573532] kobject: &amp;#39;port0.1&amp;#39; (ffff8880057bd008): kobject_release, parent 0000000000000000 (delayed 1000)<br /> [ 43.574407] kobject: &amp;#39;port0&amp;#39; (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000)<br /> [ 43.575059] kobject: &amp;#39;port1.0&amp;#39; (ffff8880057ca008): kobject_release, parent 0000000000000000 (delayed 4000)<br /> [ 43.575908] kobject: &amp;#39;port1.1&amp;#39; (ffff8880057c9008): kobject_release, parent 0000000000000000 (delayed 4000)<br /> [ 43.576908] kobject: &amp;#39;typec&amp;#39; (ffff8880062dbc00): kobject_release, parent 0000000000000000 (delayed 4000)<br /> [ 43.577769] kobject: &amp;#39;port1&amp;#39; (ffff8880057bf008): kobject_release, parent 0000000000000000 (delayed 3000)<br /> [ 46.612867] ==================================================================<br /> [ 46.613402] BUG: KASAN: slab-use-after-free in typec_altmode_release+0x38/0x129<br /> [ 46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48<br /> [ 46.614538]<br /> [ 46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535<br /> [ 46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014<br /> [ 46.616042] Workqueue: events kobject_delayed_cleanup<br /> [ 46.616446] Call Trace:<br /> [ 46.616648] <br /> [ 46.616820] dump_stack_lvl+0x5b/0x7c<br /> [ 46.617112] ? typec_altmode_release+0x38/0x129<br /> [ 46.617470] print_report+0x14c/0x49e<br /> [ 46.617769] ? rcu_read_unlock_sched+0x56/0x69<br /> [ 46.618117] ? __virt_addr_valid+0x19a/0x1ab<br /> [ 46.618456] ? kmem_cache_debug_flags+0xc/0x1d<br /> [ 46.618807] ? typec_altmode_release+0x38/0x129<br /> [ 46.619161] kasan_report+0x8d/0xb4<br /> [ 46.619447] ? typec_altmode_release+0x38/0x129<br /> [ 46.619809] ? process_scheduled_works+0x3cb/0x85f<br /> [ 46.620185] typec_altmode_release+0x38/0x129<br /> [ 46.620537] ? process_scheduled_works+0x3cb/0x85f<br /> [ 46.620907] device_release+0xaf/0xf2<br /> [ 46.621206] kobject_delayed_cleanup+0x13b/0x17a<br /> [ 46.621584] process_scheduled_works+0x4f6/0x85f<br /> [ 46.621955] ? __pfx_process_scheduled_works+0x10/0x10<br /> [ 46.622353] ? hlock_class+0x31/0x9a<br /> [ 46.622647] ? lock_acquired+0x361/0x3c3<br /> [ 46.622956] ? move_linked_works+0x46/0x7d<br /> [ 46.623277] worker_thread+0x1ce/0x291<br /> [ 46.623582] ? __kthread_parkme+0xc8/0xdf<br /> [ 46.623900] ? __pfx_worker_thread+0x10/0x10<br /> [ 46.624236] kthread+0x17e/0x190<br /> [ 46.624501] ? kthread+0xfb/0x190<br /> [ 46.624756] ? __pfx_kthread+0x10/0x10<br /> [ 46.625015] ret_from_fork+0x20/0x40<br /> [ 46.625268] ? __pfx_kthread+0x10/0x10<br /> [ 46.625532] ret_from_fork_asm+0x1a/0x30<br /> [ 46.625805] <br /> [ 46.625953]<br /> [ 46.626056] Allocated by task 678:<br /> [ 46.626287] kasan_save_stack+0x24/0x44<br /> [ 46.626555] kasan_save_track+0x14/0x2d<br /> [ 46.626811] __kasan_kmalloc+0x3f/0x4d<br /> [ 46.627049] __kmalloc_noprof+0x1bf/0x1f0<br /> [ 46.627362] typec_register_port+0x23/0x491<br /> [ 46.627698] cros_typec_probe+0x634/0xbb6<br /> [ 46.628026] platform_probe+0x47/0x8c<br /> [ 46.628311] really_probe+0x20a/0x47d<br /> [ 46.628605] device_driver_attach+0x39/0x72<br /> [ 46.628940] bind_store+0x87/0xd7<br /> [ 46.629213] kernfs_fop_write_iter+0x1aa/0x218<br /> [ 46.629574] vfs_write+0x1d6/0x29b<br /> [ 46.629856] ksys_write+0xcd/0x13b<br /> [ 46.630128] do_syscall_64+0xd4/0x139<br /> [ 46.630420] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 46.630820]<br /> [ 46.630946] Freed by task 48:<br /> [ 46.631182] kasan_save_stack+0x24/0x44<br /> [ 46.631493] kasan_save_track+0x14/0x2d<br /> [ 46.631799] kasan_save_free_info+0x3f/0x4d<br /> [ 46.632144] __kasan_slab_free+0x37/0x45<br /> [ 46.632474]<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix OOBs when building SMB2_IOCTL request<br /> <br /> When using encryption, either enforced by the server or when using<br /> &amp;#39;seal&amp;#39; mount option, the client will squash all compound request buffers<br /> down for encryption into a single iov in smb2_set_next_command().<br /> <br /> SMB2_ioctl_init() allocates a small buffer (448 bytes) to hold the<br /> SMB2_IOCTL request in the first iov, and if the user passes an input<br /> buffer that is greater than 328 bytes, smb2_set_next_command() will<br /> end up writing off the end of @rqst-&gt;iov[0].iov_base as shown below:<br /> <br /> mount.cifs //srv/share /mnt -o ...,seal<br /> ln -s $(perl -e "print(&amp;#39;a&amp;#39;)for 1..1024") /mnt/link<br /> <br /> BUG: KASAN: slab-out-of-bounds in<br /> smb2_set_next_command.cold+0x1d6/0x24c [cifs]<br /> Write of size 4116 at addr ffff8881148fcab8 by task ln/859<br /> <br /> CPU: 1 UID: 0 PID: 859 Comm: ln Not tainted 6.12.0-rc3 #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS<br /> 1.16.3-2.fc40 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x5d/0x80<br /> ? smb2_set_next_command.cold+0x1d6/0x24c [cifs]<br /> print_report+0x156/0x4d9<br /> ? smb2_set_next_command.cold+0x1d6/0x24c [cifs]<br /> ? __virt_addr_valid+0x145/0x310<br /> ? __phys_addr+0x46/0x90<br /> ? smb2_set_next_command.cold+0x1d6/0x24c [cifs]<br /> kasan_report+0xda/0x110<br /> ? smb2_set_next_command.cold+0x1d6/0x24c [cifs]<br /> kasan_check_range+0x10f/0x1f0<br /> __asan_memcpy+0x3c/0x60<br /> smb2_set_next_command.cold+0x1d6/0x24c [cifs]<br /> smb2_compound_op+0x238c/0x3840 [cifs]<br /> ? kasan_save_track+0x14/0x30<br /> ? kasan_save_free_info+0x3b/0x70<br /> ? vfs_symlink+0x1a1/0x2c0<br /> ? do_symlinkat+0x108/0x1c0<br /> ? __pfx_smb2_compound_op+0x10/0x10 [cifs]<br /> ? kmem_cache_free+0x118/0x3e0<br /> ? cifs_get_writable_path+0xeb/0x1a0 [cifs]<br /> smb2_get_reparse_inode+0x423/0x540 [cifs]<br /> ? __pfx_smb2_get_reparse_inode+0x10/0x10 [cifs]<br /> ? rcu_is_watching+0x20/0x50<br /> ? __kmalloc_noprof+0x37c/0x480<br /> ? smb2_create_reparse_symlink+0x257/0x490 [cifs]<br /> ? smb2_create_reparse_symlink+0x38f/0x490 [cifs]<br /> smb2_create_reparse_symlink+0x38f/0x490 [cifs]<br /> ? __pfx_smb2_create_reparse_symlink+0x10/0x10 [cifs]<br /> ? find_held_lock+0x8a/0xa0<br /> ? hlock_class+0x32/0xb0<br /> ? __build_path_from_dentry_optional_prefix+0x19d/0x2e0 [cifs]<br /> cifs_symlink+0x24f/0x960 [cifs]<br /> ? __pfx_make_vfsuid+0x10/0x10<br /> ? __pfx_cifs_symlink+0x10/0x10 [cifs]<br /> ? make_vfsgid+0x6b/0xc0<br /> ? generic_permission+0x96/0x2d0<br /> vfs_symlink+0x1a1/0x2c0<br /> do_symlinkat+0x108/0x1c0<br /> ? __pfx_do_symlinkat+0x10/0x10<br /> ? strncpy_from_user+0xaa/0x160<br /> __x64_sys_symlinkat+0xb9/0xf0<br /> do_syscall_64+0xbb/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f08d75c13bb

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: core: Fix null-ptr-deref in target_alloc_device()<br /> <br /> There is a null-ptr-deref issue reported by KASAN:<br /> <br /> BUG: KASAN: null-ptr-deref in target_alloc_device+0xbc4/0xbe0 [target_core_mod]<br /> ...<br /> kasan_report+0xb9/0xf0<br /> target_alloc_device+0xbc4/0xbe0 [target_core_mod]<br /> core_dev_setup_virtual_lun0+0xef/0x1f0 [target_core_mod]<br /> target_core_init_configfs+0x205/0x420 [target_core_mod]<br /> do_one_initcall+0xdd/0x4e0<br /> ...<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> In target_alloc_device(), if allocing memory for dev queues fails, then<br /> dev will be freed by dev-&gt;transport-&gt;free_device(), but dev-&gt;transport<br /> is not initialized at that time, which will lead to a null pointer<br /> reference problem.<br /> <br /> Fixing this bug by freeing dev with hba-&gt;backend-&gt;ops-&gt;free_device().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Fix shift-out-of-bounds bug<br /> <br /> Fix a shift-out-of-bounds bug reported by UBSAN when running<br /> VM with MTE enabled host kernel.<br /> <br /> UBSAN: shift-out-of-bounds in arch/arm64/kvm/sys_regs.c:1988:14<br /> shift exponent 33 is too large for 32-bit type &amp;#39;int&amp;#39;<br /> CPU: 26 UID: 0 PID: 7629 Comm: qemu-kvm Not tainted 6.12.0-rc2 #34<br /> Hardware name: IEI NF5280R7/Mitchell MB, BIOS 00.00. 2024-10-12 09:28:54 10/14/2024<br /> Call trace:<br /> dump_backtrace+0xa0/0x128<br /> show_stack+0x20/0x38<br /> dump_stack_lvl+0x74/0x90<br /> dump_stack+0x18/0x28<br /> __ubsan_handle_shift_out_of_bounds+0xf8/0x1e0<br /> reset_clidr+0x10c/0x1c8<br /> kvm_reset_sys_regs+0x50/0x1c8<br /> kvm_reset_vcpu+0xec/0x2b0<br /> __kvm_vcpu_set_target+0x84/0x158<br /> kvm_vcpu_set_target+0x138/0x168<br /> kvm_arch_vcpu_ioctl_vcpu_init+0x40/0x2b0<br /> kvm_arch_vcpu_ioctl+0x28c/0x4b8<br /> kvm_vcpu_ioctl+0x4bc/0x7a8<br /> __arm64_sys_ioctl+0xb4/0x100<br /> invoke_syscall+0x70/0x100<br /> el0_svc_common.constprop.0+0x48/0xf0<br /> do_el0_svc+0x24/0x38<br /> el0_svc+0x3c/0x158<br /> el0t_64_sync_handler+0x120/0x130<br /> el0t_64_sync+0x194/0x198

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/core: Disable page allocation in task_tick_mm_cid()<br /> <br /> With KASAN and PREEMPT_RT enabled, calling task_work_add() in<br /> task_tick_mm_cid() may cause the following splat.<br /> <br /> [ 63.696416] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48<br /> [ 63.696416] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 610, name: modprobe<br /> [ 63.696416] preempt_count: 10001, expected: 0<br /> [ 63.696416] RCU nest depth: 1, expected: 1<br /> <br /> This problem is caused by the following call trace.<br /> <br /> sched_tick() [ acquire rq-&gt;__lock ]<br /> -&gt; task_tick_mm_cid()<br /> -&gt; task_work_add()<br /> -&gt; __kasan_record_aux_stack()<br /> -&gt; kasan_save_stack()<br /> -&gt; stack_depot_save_flags()<br /> -&gt; alloc_pages_mpol_noprof()<br /> -&gt; __alloc_pages_noprof()<br /> -&gt; get_page_from_freelist()<br /> -&gt; rmqueue()<br /> -&gt; rmqueue_pcplist()<br /> -&gt; __rmqueue_pcplist()<br /> -&gt; rmqueue_bulk()<br /> -&gt; rt_spin_lock()<br /> <br /> The rq lock is a raw_spinlock_t. We can&amp;#39;t sleep while holding<br /> it. IOW, we can&amp;#39;t call alloc_pages() in stack_depot_save_flags().<br /> <br /> The task_tick_mm_cid() function with its task_work_add() call was<br /> introduced by commit 223baf9d17f2 ("sched: Fix performance regression<br /> introduced by mm_cid") in v6.4 kernel.<br /> <br /> Fortunately, there is a kasan_record_aux_stack_noalloc() variant that<br /> calls stack_depot_save_flags() while not allowing it to allocate<br /> new pages. To allow task_tick_mm_cid() to use task_work without<br /> page allocation, a new TWAF_NO_ALLOC flag is added to enable calling<br /> kasan_record_aux_stack_noalloc() instead of kasan_record_aux_stack()<br /> if set. The task_tick_mm_cid() function is modified to add this new flag.<br /> <br /> The possible downside is the missing stack trace in a KASAN report due<br /> to new page allocation required when task_work_add_noallloc() is called<br /> which should be rare.

Zohocorp ManageEngine EndPoint Central versions 11.3.2416.21 and below, 11.3.2428.9 and below are vulnerable to Arbitrary File Deletion in the agent installed machines.

A flaw was found in Undertow package. Using the FormAuthenticationMechanism, a malicious user could trigger a Denial of Service by sending crafted requests, leading the server to an OutofMemory error, exhausting the server&amp;#39;s memory.

A flaw was found in hibernate-validator&amp;#39;s &amp;#39;isValid&amp;#39; method in the org.hibernate.validator.internal.constraintvalidators.hv.SafeHtmlValidator class, which can be bypassed by omitting the tag ending in a less-than character. Browsers may render an invalid html, allowing HTML injection or Cross-Site-Scripting (XSS) attacks.

HCL BigFix Compliance is affected by unvalidated redirects and forwards. The HOST header can be manipulated by an attacker and as a result, it can poison the web cache and provide back to users being served the page.

HCL BigFix Compliance is vulnerable to the generation of error messages containing sensitive information. Detailed error messages can provide enticement information or expose information about its environment, users, or associated data.