Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kheaders: Use array declaration instead of char<br /> <br /> Under CONFIG_FORTIFY_SOURCE, memcpy() will check the size of destination<br /> and source buffers. Defining kernel_headers_data as "char" would trip<br /> this check. Since these addresses are treated as byte arrays, define<br /> them as arrays (as done everywhere else).<br /> <br /> This was seen with:<br /> <br /> $ cat /sys/kernel/kheaders.tar.xz &gt;&gt; /dev/null<br /> <br /> detected buffer overflow in memcpy<br /> kernel BUG at lib/string_helpers.c:1027!<br /> ...<br /> RIP: 0010:fortify_panic+0xf/0x20<br /> [...]<br /> Call Trace:<br /> <br /> ikheaders_read+0x45/0x50 [kheaders]<br /> kernfs_fop_read_iter+0x1a4/0x2f0<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/amd: Add a length limitation for the ivrs_acpihid command-line parameter<br /> <br /> The &amp;#39;acpiid&amp;#39; buffer in the parse_ivrs_acpihid function may overflow,<br /> because the string specifier in the format string sscanf()<br /> has no width limitation.<br /> <br /> Found by InfoTeCS on behalf of Linux Verification Center<br /> (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: arm_ffa: Check if ffa_driver remove is present before executing<br /> <br /> Currently ffa_drv-&gt;remove() is called unconditionally from<br /> ffa_device_remove(). Since the driver registration doesn&amp;#39;t check for it<br /> and allows it to be registered without .remove callback, we need to check<br /> for the presence of it before executing it from ffa_device_remove() to<br /> above a NULL pointer dereference like the one below:<br /> <br /> | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> | Mem abort info:<br /> | ESR = 0x0000000086000004<br /> | EC = 0x21: IABT (current EL), IL = 32 bits<br /> | SET = 0, FnV = 0<br /> | EA = 0, S1PTW = 0<br /> | FSC = 0x04: level 0 translation fault<br /> | user pgtable: 4k pages, 48-bit VAs, pgdp=0000000881cc8000<br /> | [0000000000000000] pgd=0000000000000000, p4d=0000000000000000<br /> | Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP<br /> | CPU: 3 PID: 130 Comm: rmmod Not tainted 6.3.0-rc7 #6<br /> | Hardware name: FVP Base RevC (DT)<br /> | pstate: 63402809 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=-c)<br /> | pc : 0x0<br /> | lr : ffa_device_remove+0x20/0x2c<br /> | Call trace:<br /> | 0x0<br /> | device_release_driver_internal+0x16c/0x260<br /> | driver_detach+0x90/0xd0<br /> | bus_remove_driver+0xdc/0x11c<br /> | driver_unregister+0x30/0x54<br /> | ffa_driver_unregister+0x14/0x20<br /> | cleanup_module+0x18/0xeec<br /> | __arm64_sys_delete_module+0x234/0x378<br /> | invoke_syscall+0x40/0x108<br /> | el0_svc_common+0xb4/0xf0<br /> | do_el0_svc+0x30/0xa4<br /> | el0_svc+0x2c/0x7c<br /> | el0t_64_sync_handler+0x84/0xf0<br /> | el0t_64_sync+0x190/0x194

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: mediatek: mtk-svs: Enable the IRQ later<br /> <br /> If the system does not come from reset (like when is booted via<br /> kexec()), the peripheral might triger an IRQ before the data structures<br /> are initialised.<br /> <br /> <br /> [ 0.227710] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000f08<br /> [ 0.227913] Call trace:<br /> [ 0.227918] svs_isr+0x8c/0x538

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommufd: Set end correctly when doing batch carry<br /> <br /> Even though the test suite covers this it somehow became obscured that<br /> this wasn&amp;#39;t working.<br /> <br /> The test iommufd_ioas.mock_domain.access_domain_destory would blow up<br /> rarely.<br /> <br /> end should be set to 1 because this just pushed an item, the carry, to the<br /> pfns list.<br /> <br /> Sometimes the test would blow up with:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] SMP<br /> CPU: 5 PID: 584 Comm: iommufd Not tainted 6.5.0-rc1-dirty #1236<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:batch_unpin+0xa2/0x100 [iommufd]<br /> Code: 17 48 81 fe ff ff 07 00 77 70 48 8b 15 b7 be 97 e2 48 85 d2 74 14 48 8b 14 fa 48 85 d2 74 0b 40 0f b6 f6 48 c1 e6 04 48 01 f2 8b 3a 48 c1 e0 06 89 ca 48 89 de 48 83 e7 f0 48 01 c7 e8 96 dc<br /> RSP: 0018:ffffc90001677a58 EFLAGS: 00010246<br /> RAX: 00007f7e2646f000 RBX: 0000000000000000 RCX: 0000000000000001<br /> RDX: 0000000000000000 RSI: 00000000fefc4c8d RDI: 0000000000fefc4c<br /> RBP: ffffc90001677a80 R08: 0000000000000048 R09: 0000000000000200<br /> R10: 0000000000030b98 R11: ffffffff81f3bb40 R12: 0000000000000001<br /> R13: ffff888101f75800 R14: ffffc90001677ad0 R15: 00000000000001fe<br /> FS: 00007f9323679740(0000) GS:ffff8881ba540000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 0000000105ede003 CR4: 00000000003706a0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? show_regs+0x5c/0x70<br /> ? __die+0x1f/0x60<br /> ? page_fault_oops+0x15d/0x440<br /> ? lock_release+0xbc/0x240<br /> ? exc_page_fault+0x4a4/0x970<br /> ? asm_exc_page_fault+0x27/0x30<br /> ? batch_unpin+0xa2/0x100 [iommufd]<br /> ? batch_unpin+0xba/0x100 [iommufd]<br /> __iopt_area_unfill_domain+0x198/0x430 [iommufd]<br /> ? __mutex_lock+0x8c/0xb80<br /> ? __mutex_lock+0x6aa/0xb80<br /> ? xa_erase+0x28/0x30<br /> ? iopt_table_remove_domain+0x162/0x320 [iommufd]<br /> ? lock_release+0xbc/0x240<br /> iopt_area_unfill_domain+0xd/0x10 [iommufd]<br /> iopt_table_remove_domain+0x195/0x320 [iommufd]<br /> iommufd_hw_pagetable_destroy+0xb3/0x110 [iommufd]<br /> iommufd_object_destroy_user+0x8e/0xf0 [iommufd]<br /> iommufd_device_detach+0xc5/0x140 [iommufd]<br /> iommufd_selftest_destroy+0x1f/0x70 [iommufd]<br /> iommufd_object_destroy_user+0x8e/0xf0 [iommufd]<br /> iommufd_destroy+0x3a/0x50 [iommufd]<br /> iommufd_fops_ioctl+0xfb/0x170 [iommufd]<br /> __x64_sys_ioctl+0x40d/0x9a0<br /> do_syscall_64+0x3c/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86: fix clear_user_rep_good() exception handling annotation<br /> <br /> This code no longer exists in mainline, because it was removed in<br /> commit d2c95f9d6802 ("x86: don&amp;#39;t use REP_GOOD or ERMS for user memory<br /> clearing") upstream.<br /> <br /> However, rather than backport the full range of x86 memory clearing and<br /> copying cleanups, fix the exception table annotation placement for the<br /> final &amp;#39;rep movsb&amp;#39; in clear_user_rep_good(): rather than pointing at the<br /> actual instruction that did the user space access, it pointed to the<br /> register move just before it.<br /> <br /> That made sense from a code flow standpoint, but not from an actual<br /> usage standpoint: it means that if user access takes an exception, the<br /> exception handler won&amp;#39;t actually find the instruction in the exception<br /> tables.<br /> <br /> As a result, rather than fixing it up and returning -EFAULT, it would<br /> then turn it into a kernel oops report instead, something like:<br /> <br /> BUG: unable to handle page fault for address: 0000000020081000<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> ...<br /> RIP: 0010:clear_user_rep_good+0x1c/0x30 arch/x86/lib/clear_page_64.S:147<br /> ...<br /> Call Trace:<br /> __clear_user arch/x86/include/asm/uaccess_64.h:103 [inline]<br /> clear_user arch/x86/include/asm/uaccess_64.h:124 [inline]<br /> iov_iter_zero+0x709/0x1290 lib/iov_iter.c:800<br /> iomap_dio_hole_iter fs/iomap/direct-io.c:389 [inline]<br /> iomap_dio_iter fs/iomap/direct-io.c:440 [inline]<br /> __iomap_dio_rw+0xe3d/0x1cd0 fs/iomap/direct-io.c:601<br /> iomap_dio_rw+0x40/0xa0 fs/iomap/direct-io.c:689<br /> ext4_dio_read_iter fs/ext4/file.c:94 [inline]<br /> ext4_file_read_iter+0x4be/0x690 fs/ext4/file.c:145<br /> call_read_iter include/linux/fs.h:2183 [inline]<br /> do_iter_readv_writev+0x2e0/0x3b0 fs/read_write.c:733<br /> do_iter_read+0x2f2/0x750 fs/read_write.c:796<br /> vfs_readv+0xe5/0x150 fs/read_write.c:916<br /> do_preadv+0x1b6/0x270 fs/read_write.c:1008<br /> __do_sys_preadv2 fs/read_write.c:1070 [inline]<br /> __se_sys_preadv2 fs/read_write.c:1061 [inline]<br /> __x64_sys_preadv2+0xef/0x150 fs/read_write.c:1061<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> which then looks like a filesystem bug rather than the incorrect<br /> exception annotation that it is.<br /> <br /> [ The alternative to this one-liner fix is to take the upstream series<br /> that cleans this all up:<br /> <br /> 68674f94ffc9 ("x86: don&amp;#39;t use REP_GOOD or ERMS for small memory copies")<br /> 20f3337d350c ("x86: don&amp;#39;t use REP_GOOD or ERMS for small memory clearing")<br /> adfcf4231b8c ("x86: don&amp;#39;t use REP_GOOD or ERMS for user memory copies")<br /> * d2c95f9d6802 ("x86: don&amp;#39;t use REP_GOOD or ERMS for user memory clearing")<br /> 3639a535587d ("x86: move stac/clac from user copy routines into callers")<br /> 577e6a7fd50d ("x86: inline the &amp;#39;rep movs&amp;#39; in user copies for the FSRM case")<br /> 8c9b6a88b7e2 ("x86: improve on the non-rep &amp;#39;clear_user&amp;#39; function")<br /> 427fda2c8a49 ("x86: improve on the non-rep &amp;#39;copy_user&amp;#39; function")<br /> * e046fe5a36a9 ("x86: set FSRS automatically on AMD CPUs that have FSRM")<br /> e1f2750edc4a ("x86: remove &amp;#39;zerorest&amp;#39; argument from __copy_user_nocache()")<br /> 034ff37d3407 ("x86: rewrite &amp;#39;__copy_user_nocache&amp;#39; function")<br /> <br /> with either the whole series or at a minimum the two marked commits<br /> being needed to fix this issue ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix invalid free tracking in ext4_xattr_move_to_block()<br /> <br /> In ext4_xattr_move_to_block(), the value of the extended attribute<br /> which we need to move to an external block may be allocated by<br /> kvmalloc() if the value is stored in an external inode. So at the end<br /> of the function the code tried to check if this was the case by<br /> testing entry-&gt;e_value_inum.<br /> <br /> However, at this point, the pointer to the xattr entry is no longer<br /> valid, because it was removed from the original location where it had<br /> been stored. So we could end up calling kvfree() on a pointer which<br /> was not allocated by kvmalloc(); or we could also potentially leak<br /> memory by not freeing the buffer when it should be freed. Fix this by<br /> storing whether it should be freed in a separate variable.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spmi: Add a check for remove callback when removing a SPMI driver<br /> <br /> When removing a SPMI driver, there can be a crash due to NULL pointer<br /> dereference if it does not have a remove callback defined. This is<br /> one such call trace observed when removing the QCOM SPMI PMIC driver:<br /> <br /> dump_backtrace.cfi_jt+0x0/0x8<br /> dump_stack_lvl+0xd8/0x16c<br /> panic+0x188/0x498<br /> __cfi_slowpath+0x0/0x214<br /> __cfi_slowpath+0x1dc/0x214<br /> spmi_drv_remove+0x16c/0x1e0<br /> device_release_driver_internal+0x468/0x79c<br /> driver_detach+0x11c/0x1a0<br /> bus_remove_driver+0xc4/0x124<br /> driver_unregister+0x58/0x84<br /> cleanup_module+0x1c/0xc24 [qcom_spmi_pmic]<br /> __do_sys_delete_module+0x3ec/0x53c<br /> __arm64_sys_delete_module+0x18/0x28<br /> el0_svc_common+0xdc/0x294<br /> el0_svc+0x38/0x9c<br /> el0_sync_handler+0x8c/0xf0<br /> el0_sync+0x1b4/0x1c0<br /> <br /> If a driver has all its resources allocated through devm_() APIs and<br /> does not need any other explicit cleanup, it would not require a<br /> remove callback to be defined. Hence, add a check for remove callback<br /> presence before calling it when removing a SPMI driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> audit: fix possible soft lockup in __audit_inode_child()<br /> <br /> Tracefs or debugfs maybe cause hundreds to thousands of PATH records,<br /> too many PATH records maybe cause soft lockup.<br /> <br /> For example:<br /> 1. CONFIG_KASAN=y &amp;&amp; CONFIG_PREEMPTION=n<br /> 2. auditctl -a exit,always -S open -k key<br /> 3. sysctl -w kernel.watchdog_thresh=5<br /> 4. mkdir /sys/kernel/debug/tracing/instances/test<br /> <br /> There may be a soft lockup as follows:<br /> watchdog: BUG: soft lockup - CPU#45 stuck for 7s! [mkdir:15498]<br /> Kernel panic - not syncing: softlockup: hung tasks<br /> Call trace:<br /> dump_backtrace+0x0/0x30c<br /> show_stack+0x20/0x30<br /> dump_stack+0x11c/0x174<br /> panic+0x27c/0x494<br /> watchdog_timer_fn+0x2bc/0x390<br /> __run_hrtimer+0x148/0x4fc<br /> __hrtimer_run_queues+0x154/0x210<br /> hrtimer_interrupt+0x2c4/0x760<br /> arch_timer_handler_phys+0x48/0x60<br /> handle_percpu_devid_irq+0xe0/0x340<br /> __handle_domain_irq+0xbc/0x130<br /> gic_handle_irq+0x78/0x460<br /> el1_irq+0xb8/0x140<br /> __audit_inode_child+0x240/0x7bc<br /> tracefs_create_file+0x1b8/0x2a0<br /> trace_create_file+0x18/0x50<br /> event_create_dir+0x204/0x30c<br /> __trace_add_new_event+0xac/0x100<br /> event_trace_add_tracer+0xa0/0x130<br /> trace_array_create_dir+0x60/0x140<br /> trace_array_create+0x1e0/0x370<br /> instance_mkdir+0x90/0xd0<br /> tracefs_syscall_mkdir+0x68/0xa0<br /> vfs_mkdir+0x21c/0x34c<br /> do_mkdirat+0x1b4/0x1d4<br /> __arm64_sys_mkdirat+0x4c/0x60<br /> el0_svc_common.constprop.0+0xa8/0x240<br /> do_el0_svc+0x8c/0xc0<br /> el0_svc+0x20/0x30<br /> el0_sync_handler+0xb0/0xb4<br /> el0_sync+0x160/0x180<br /> <br /> Therefore, we add cond_resched() to __audit_inode_child() to fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: essiv - Handle EBUSY correctly<br /> <br /> As it is essiv only handles the special return value of EINPROGERSS,<br /> which means that in all other cases it will free data related to the<br /> request.<br /> <br /> However, as the caller of essiv may specify MAY_BACKLOG, we also need<br /> to expect EBUSY and treat it in the same way. Otherwise backlogged<br /> requests will trigger a use-after-free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/rockchip: dw_hdmi: cleanup drm encoder during unbind<br /> <br /> This fixes a use-after-free crash during rmmod.<br /> <br /> The DRM encoder is embedded inside the larger rockchip_hdmi,<br /> which is allocated with the component. The component memory<br /> gets freed before the main drm device is destroyed. Fix it<br /> by running encoder cleanup before tearing down its container.<br /> <br /> [moved encoder cleanup above clk_disable, similar to bind-error-path]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/bnxt_re: Prevent handling any completions after qp destroy<br /> <br /> HW may generate completions that indicates QP is destroyed.<br /> Driver should not be scheduling any more completion handlers<br /> for this QP, after the QP is destroyed. Since CQs are active<br /> during the QP destroy, driver may still schedule completion<br /> handlers. This can cause a race where the destroy_cq and poll_cq<br /> running simultaneously.<br /> <br /> Snippet of kernel panic while doing bnxt_re driver load unload in loop.<br /> This indicates a poll after the CQ is freed. <br /> <br /> [77786.481636] Call Trace:<br /> [77786.481640]  <br /> [77786.481644]  bnxt_re_poll_cq+0x14a/0x620 [bnxt_re]<br /> [77786.481658]  ? kvm_clock_read+0x14/0x30<br /> [77786.481693]  __ib_process_cq+0x57/0x190 [ib_core]<br /> [77786.481728]  ib_cq_poll_work+0x26/0x80 [ib_core]<br /> [77786.481761]  process_one_work+0x1e5/0x3f0<br /> [77786.481768]  worker_thread+0x50/0x3a0<br /> [77786.481785]  ? __pfx_worker_thread+0x10/0x10<br /> [77786.481790]  kthread+0xe2/0x110<br /> [77786.481794]  ? __pfx_kthread+0x10/0x10<br /> [77786.481797]  ret_from_fork+0x2c/0x50<br /> <br /> To avoid this, complete all completion handlers before returning the<br /> destroy QP. If free_cq is called soon after destroy_qp, IB stack<br /> will cancel the CQ work before invoking the destroy_cq verb and<br /> this will prevent any race mentioned.