Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: dev: fix skb drop check<br /> <br /> In commit a6d190f8c767 ("can: skb: drop tx skb if in listen only<br /> mode") the priv-&gt;ctrlmode element is read even on virtual CAN<br /> interfaces that do not create the struct can_priv at startup. This<br /> out-of-bounds read may lead to CAN frame drops for virtual CAN<br /> interfaces like vcan and vxcan.<br /> <br /> This patch mainly reverts the original commit and adds a new helper<br /> for CAN interface drivers that provide the required information in<br /> struct can_priv.<br /> <br /> [mkl: patch pch_can, too]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> siox: fix possible memory leak in siox_device_add()<br /> <br /> If device_register() returns error in siox_device_add(),<br /> the name allocated by dev_set_name() need be freed. As<br /> comment of device_register() says, it should use put_device()<br /> to give up the reference in the error path. So fix this<br /> by calling put_device(), then the name can be freed in<br /> kobject_cleanup(), and sdevice is freed in siox_device_release(),<br /> set it to null in error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: clear out_curr if all frag chunks of current msg are pruned<br /> <br /> A crash was reported by Zhen Chen:<br /> <br /> list_del corruption, ffffa035ddf01c18-&gt;next is NULL<br /> WARNING: CPU: 1 PID: 250682 at lib/list_debug.c:49 __list_del_entry_valid+0x59/0xe0<br /> RIP: 0010:__list_del_entry_valid+0x59/0xe0<br /> Call Trace:<br /> sctp_sched_dequeue_common+0x17/0x70 [sctp]<br /> sctp_sched_fcfs_dequeue+0x37/0x50 [sctp]<br /> sctp_outq_flush_data+0x85/0x360 [sctp]<br /> sctp_outq_uncork+0x77/0xa0 [sctp]<br /> sctp_cmd_interpreter.constprop.0+0x164/0x1450 [sctp]<br /> sctp_side_effects+0x37/0xe0 [sctp]<br /> sctp_do_sm+0xd0/0x230 [sctp]<br /> sctp_primitive_SEND+0x2f/0x40 [sctp]<br /> sctp_sendmsg_to_asoc+0x3fa/0x5c0 [sctp]<br /> sctp_sendmsg+0x3d5/0x440 [sctp]<br /> sock_sendmsg+0x5b/0x70<br /> <br /> and in sctp_sched_fcfs_dequeue() it dequeued a chunk from stream<br /> out_curr outq while this outq was empty.<br /> <br /> Normally stream-&gt;out_curr must be set to NULL once all frag chunks of<br /> current msg are dequeued, as we can see in sctp_sched_dequeue_done().<br /> However, in sctp_prsctp_prune_unsent() as it is not a proper dequeue,<br /> sctp_sched_dequeue_done() is not called to do this.<br /> <br /> This patch is to fix it by simply setting out_curr to NULL when the<br /> last frag chunk of current msg is dequeued from out_curr stream in<br /> sctp_prsctp_prune_unsent().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: imx: Add missing .thaw_noirq hook<br /> <br /> The following warning is seen with non-console UART instance when<br /> system hibernates.<br /> <br /> [ 37.371969] ------------[ cut here ]------------<br /> [ 37.376599] uart3_root_clk already disabled<br /> [ 37.380810] WARNING: CPU: 0 PID: 296 at drivers/clk/clk.c:952 clk_core_disable+0xa4/0xb0<br /> ...<br /> [ 37.506986] Call trace:<br /> [ 37.509432] clk_core_disable+0xa4/0xb0<br /> [ 37.513270] clk_disable+0x34/0x50<br /> [ 37.516672] imx_uart_thaw+0x38/0x5c<br /> [ 37.520250] platform_pm_thaw+0x30/0x6c<br /> [ 37.524089] dpm_run_callback.constprop.0+0x3c/0xd4<br /> [ 37.528972] device_resume+0x7c/0x160<br /> [ 37.532633] dpm_resume+0xe8/0x230<br /> [ 37.536036] hibernation_snapshot+0x288/0x430<br /> [ 37.540397] hibernate+0x10c/0x2e0<br /> [ 37.543798] state_store+0xc4/0xd0<br /> [ 37.547203] kobj_attr_store+0x1c/0x30<br /> [ 37.550953] sysfs_kf_write+0x48/0x60<br /> [ 37.554619] kernfs_fop_write_iter+0x118/0x1ac<br /> [ 37.559063] new_sync_write+0xe8/0x184<br /> [ 37.562812] vfs_write+0x230/0x290<br /> [ 37.566214] ksys_write+0x68/0xf4<br /> [ 37.569529] __arm64_sys_write+0x20/0x2c<br /> [ 37.573452] invoke_syscall.constprop.0+0x50/0xf0<br /> [ 37.578156] do_el0_svc+0x11c/0x150<br /> [ 37.581648] el0_svc+0x30/0x140<br /> [ 37.584792] el0t_64_sync_handler+0xe8/0xf0<br /> [ 37.588976] el0t_64_sync+0x1a0/0x1a4<br /> [ 37.592639] ---[ end trace 56e22eec54676d75 ]---<br /> <br /> On hibernating, pm core calls into related hooks in sequence like:<br /> <br /> .freeze<br /> .freeze_noirq<br /> .thaw_noirq<br /> .thaw<br /> <br /> With .thaw_noirq hook being absent, the clock will be disabled in a<br /> unbalanced call which results the warning above.<br /> <br /> imx_uart_freeze()<br /> clk_prepare_enable()<br /> imx_uart_suspend_noirq()<br /> clk_disable()<br /> imx_uart_thaw<br /> clk_disable_unprepare()<br /> <br /> Adding the missing .thaw_noirq hook as imx_uart_resume_noirq() will have<br /> the call sequence corrected as below and thus fix the warning.<br /> <br /> imx_uart_freeze()<br /> clk_prepare_enable()<br /> imx_uart_suspend_noirq()<br /> clk_disable()<br /> imx_uart_resume_noirq()<br /> clk_enable()<br /> imx_uart_thaw<br /> clk_disable_unprepare()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: devicetree: fix null pointer dereferencing in pinctrl_dt_to_map<br /> <br /> Here is the BUG report by KASAN about null pointer dereference:<br /> <br /> BUG: KASAN: null-ptr-deref in strcmp+0x2e/0x50<br /> Read of size 1 at addr 0000000000000000 by task python3/2640<br /> Call Trace:<br /> strcmp<br /> __of_find_property<br /> of_find_property<br /> pinctrl_dt_to_map<br /> <br /> kasprintf() would return NULL pointer when kmalloc() fail to allocate.<br /> So directly return ENOMEM, if kasprintf() return NULL pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: zoned: initialize device&amp;#39;s zone info for seeding<br /> <br /> When performing seeding on a zoned filesystem it is necessary to<br /> initialize each zoned device&amp;#39;s btrfs_zoned_device_info structure,<br /> otherwise mounting the filesystem will cause a NULL pointer dereference.<br /> <br /> This was uncovered by fstests&amp;#39; testcase btrfs/163.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/drv: Fix potential memory leak in drm_dev_init()<br /> <br /> drm_dev_init() will add drm_dev_init_release() as a callback. When<br /> drmm_add_action() failed, the release function won&amp;#39;t be added. As the<br /> result, the ref cnt added by device_get() in drm_dev_init() won&amp;#39;t be put<br /> by drm_dev_init_release(), which leads to the memleak. Use<br /> drmm_add_action_or_reset() instead of drmm_add_action() to prevent<br /> memleak.<br /> <br /> unreferenced object 0xffff88810bc0c800 (size 2048):<br /> comm "modprobe", pid 8322, jiffies 4305809845 (age 15.292s)<br /> hex dump (first 32 bytes):<br /> e8 cc c0 0b 81 88 ff ff ff ff ff ff 00 00 00 00 ................<br /> 20 24 3c 0c 81 88 ff ff 18 c8 c0 0b 81 88 ff ff $

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/scheduler: fix fence ref counting<br /> <br /> We leaked dependency fences when processes were beeing killed.<br /> <br /> Additional to that grab a reference to the last scheduled fence.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hugetlbfs: don&amp;#39;t delete error page from pagecache<br /> <br /> This change is very similar to the change that was made for shmem [1], and<br /> it solves the same problem but for HugeTLBFS instead.<br /> <br /> Currently, when poison is found in a HugeTLB page, the page is removed<br /> from the page cache. That means that attempting to map or read that<br /> hugepage in the future will result in a new hugepage being allocated<br /> instead of notifying the user that the page was poisoned. As [1] states,<br /> this is effectively memory corruption.<br /> <br /> The fix is to leave the page in the page cache. If the user attempts to<br /> use a poisoned HugeTLB page with a syscall, the syscall will fail with<br /> EIO, the same error code that shmem uses. For attempts to map the page,<br /> the thread will get a BUS_MCEERR_AR SIGBUS.<br /> <br /> [1]: commit a76054266661 ("mm: shmem: don&amp;#39;t truncate page if memory failure happens")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: Fix potential null-ptr-deref in drm_vblank_destroy_worker()<br /> <br /> drm_vblank_init() call drmm_add_action_or_reset() with<br /> drm_vblank_init_release() as action. If __drmm_add_action() failed, will<br /> directly call drm_vblank_init_release() with the vblank whose worker is<br /> NULL. As the resule, a null-ptr-deref will happen in<br /> kthread_destroy_worker(). Add the NULL check before calling<br /> drm_vblank_destroy_worker().<br /> <br /> BUG: null-ptr-deref<br /> KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f]<br /> CPU: 5 PID: 961 Comm: modprobe Not tainted 6.0.0-11331-gd465bff130bf-dirty<br /> RIP: 0010:kthread_destroy_worker+0x25/0xb0<br /> Call Trace:<br /> <br /> drm_vblank_init_release+0x124/0x220 [drm]<br /> ? drm_crtc_vblank_restore+0x8b0/0x8b0 [drm]<br /> __drmm_add_action_or_reset+0x41/0x50 [drm]<br /> drm_vblank_init+0x282/0x310 [drm]<br /> vkms_init+0x35f/0x1000 [vkms]<br /> ? 0xffffffffc4508000<br /> ? lock_is_held_type+0xd7/0x130<br /> ? __kmem_cache_alloc_node+0x1c2/0x2b0<br /> ? lock_is_held_type+0xd7/0x130<br /> ? 0xffffffffc4508000<br /> do_one_initcall+0xd0/0x4f0<br /> ...<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ata: libata-transport: fix double ata_host_put() in ata_tport_add()<br /> <br /> In the error path in ata_tport_add(), when calling put_device(),<br /> ata_tport_release() is called, it will put the refcount of &amp;#39;ap-&gt;host&amp;#39;.<br /> <br /> And then ata_host_put() is called again, the refcount is decreased<br /> to 0, ata_host_release() is called, all ports are freed and set to<br /> null.<br /> <br /> When unbinding the device after failure, ata_host_stop() is called<br /> to release the resources, it leads a null-ptr-deref(), because all<br /> the ports all freed and null.<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008<br /> CPU: 7 PID: 18671 Comm: modprobe Kdump: loaded Tainted: G E 6.1.0-rc3+ #8<br /> pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : ata_host_stop+0x3c/0x84 [libata]<br /> lr : release_nodes+0x64/0xd0<br /> Call trace:<br /> ata_host_stop+0x3c/0x84 [libata]<br /> release_nodes+0x64/0xd0<br /> devres_release_all+0xbc/0x1b0<br /> device_unbind_cleanup+0x20/0x70<br /> really_probe+0x158/0x320<br /> __driver_probe_device+0x84/0x120<br /> driver_probe_device+0x44/0x120<br /> __driver_attach+0xb4/0x220<br /> bus_for_each_dev+0x78/0xdc<br /> driver_attach+0x2c/0x40<br /> bus_add_driver+0x184/0x240<br /> driver_register+0x80/0x13c<br /> __pci_register_driver+0x4c/0x60<br /> ahci_pci_driver_init+0x30/0x1000 [ahci]<br /> <br /> Fix this by removing redundant ata_host_put() in the error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix use-after-free bug of ns_writer on remount<br /> <br /> If a nilfs2 filesystem is downgraded to read-only due to metadata<br /> corruption on disk and is remounted read/write, or if emergency read-only<br /> remount is performed, detaching a log writer and synchronizing the<br /> filesystem can be done at the same time.<br /> <br /> In these cases, use-after-free of the log writer (hereinafter<br /> nilfs-&gt;ns_writer) can happen as shown in the scenario below:<br /> <br /> Task1 Task2<br /> -------------------------------- ------------------------------<br /> nilfs_construct_segment<br /> nilfs_segctor_sync<br /> init_wait<br /> init_waitqueue_entry<br /> add_wait_queue<br /> schedule<br /> nilfs_remount (R/W remount case)<br /> nilfs_attach_log_writer<br /> nilfs_detach_log_writer<br /> nilfs_segctor_destroy<br /> kfree<br /> finish_wait<br /> _raw_spin_lock_irqsave<br /> __raw_spin_lock_irqsave<br /> do_raw_spin_lock<br /> debug_spin_lock_before ns_writer is freed by Task2. After Task1<br /> waked up, Task1 accesses nilfs-&gt;ns_writer which is already freed. This<br /> scenario diagram is based on the Shigeru Yoshida&amp;#39;s post [1].<br /> <br /> This patch fixes the issue by not detaching nilfs-&gt;ns_writer on remount so<br /> that this UAF race doesn&amp;#39;t happen. Along with this change, this patch<br /> also inserts a few necessary read-only checks with superblock instance<br /> where only the ns_writer pointer was used to check if the filesystem is<br /> read-only.