Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: give up on paths longer than PATH_MAX<br /> <br /> If the full path to be built by ceph_mdsc_build_path() happens to be<br /> longer than PATH_MAX, then this function will enter an endless (retry)<br /> loop, effectively blocking the whole task. Most of the machine<br /> becomes unusable, making this a very simple and effective DoS<br /> vulnerability.<br /> <br /> I cannot imagine why this retry was ever implemented, but it seems<br /> rather useless and harmful to me. Let&amp;#39;s remove it and fail with<br /> ENAMETOOLONG instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: check iparea_offset and ipv6_prefixes_cnt when receiving proposal msg<br /> <br /> When receiving proposal msg in server, the field iparea_offset<br /> and the field ipv6_prefixes_cnt in proposal msg are from the<br /> remote client and can not be fully trusted. Especially the<br /> field iparea_offset, once exceed the max value, there has the<br /> chance to access wrong address, and crash may happen.<br /> <br /> This patch checks iparea_offset and ipv6_prefixes_cnt before using them.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/fair: Fix NEXT_BUDDY<br /> <br /> Adam reports that enabling NEXT_BUDDY insta triggers a WARN in<br /> pick_next_entity().<br /> <br /> Moving clear_buddies() up before the delayed dequeue bits ensures<br /> no -&gt;next buddy becomes delayed. Further ensure no new -&gt;next buddy<br /> ever starts as delayed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: mpc52xx: Add cancel_work_sync before module remove<br /> <br /> If we remove the module which will call mpc52xx_spi_remove<br /> it will free &amp;#39;ms&amp;#39; through spi_unregister_controller.<br /> while the work ms-&gt;work will be used. The sequence of operations<br /> that may lead to a UAF bug.<br /> <br /> Fix it by ensuring that the work is canceled before proceeding with<br /> the cleanup in mpc52xx_spi_remove.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: use aligned address in copy_user_gigantic_page()<br /> <br /> In current kernel, hugetlb_wp() calls copy_user_large_folio() with the<br /> fault address. Where the fault address may be not aligned with the huge<br /> page size. Then, copy_user_large_folio() may call<br /> copy_user_gigantic_page() with the address, while<br /> copy_user_gigantic_page() requires the address to be huge page size<br /> aligned. So, this may cause memory corruption or information leak,<br /> addtional, use more obvious naming &amp;#39;addr_hint&amp;#39; instead of &amp;#39;addr&amp;#39; for<br /> copy_user_gigantic_page().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: use aligned address in clear_gigantic_page()<br /> <br /> In current kernel, hugetlb_no_page() calls folio_zero_user() with the<br /> fault address. Where the fault address may be not aligned with the huge<br /> page size. Then, folio_zero_user() may call clear_gigantic_page() with<br /> the address, while clear_gigantic_page() requires the address to be huge<br /> page size aligned. So, this may cause memory corruption or information<br /> leak, addtional, use more obvious naming &amp;#39;addr_hint&amp;#39; instead of &amp;#39;addr&amp;#39; for<br /> clear_gigantic_page().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> stackdepot: fix stack_depot_save_flags() in NMI context<br /> <br /> Per documentation, stack_depot_save_flags() was meant to be usable from<br /> NMI context if STACK_DEPOT_FLAG_CAN_ALLOC is unset. However, it still<br /> would try to take the pool_lock in an attempt to save a stack trace in the<br /> current pool (if space is available).<br /> <br /> This could result in deadlock if an NMI is handled while pool_lock is<br /> already held. To avoid deadlock, only try to take the lock in NMI context<br /> and give up if unsuccessful.<br /> <br /> The documentation is fixed to clearly convey this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bcache: revert replacing IS_ERR_OR_NULL with IS_ERR again<br /> <br /> Commit 028ddcac477b ("bcache: Remove unnecessary NULL point check in<br /> node allocations") leads a NULL pointer deference in cache_set_flush().<br /> <br /> 1721 if (!IS_ERR_OR_NULL(c-&gt;root))<br /> 1722 list_add(&amp;c-&gt;root-&gt;list, &amp;c-&gt;btree_cache);<br /> <br /> &gt;From the above code in cache_set_flush(), if previous registration code<br /> fails before allocating c-&gt;root, it is possible c-&gt;root is NULL as what<br /> it is initialized. __bch_btree_node_alloc() never returns NULL but<br /> c-&gt;root is possible to be NULL at above line 1721.<br /> <br /> This patch replaces IS_ERR() by IS_ERR_OR_NULL() to fix this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: check v2_ext_offset/eid_cnt/ism_gid_cnt when receiving proposal msg<br /> <br /> When receiving proposal msg in server, the fields v2_ext_offset/<br /> eid_cnt/ism_gid_cnt in proposal msg are from the remote client<br /> and can not be fully trusted. Especially the field v2_ext_offset,<br /> once exceed the max value, there has the chance to access wrong<br /> address, and crash may happen.<br /> <br /> This patch checks the fields v2_ext_offset/eid_cnt/ism_gid_cnt<br /> before using them.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-rdma: unquiesce admin_q before destroy it<br /> <br /> Kernel will hang on destroy admin_q while we create ctrl failed, such<br /> as following calltrace:<br /> <br /> PID: 23644 TASK: ff2d52b40f439fc0 CPU: 2 COMMAND: "nvme"<br /> #0 [ff61d23de260fb78] __schedule at ffffffff8323bc15<br /> #1 [ff61d23de260fc08] schedule at ffffffff8323c014<br /> #2 [ff61d23de260fc28] blk_mq_freeze_queue_wait at ffffffff82a3dba1<br /> #3 [ff61d23de260fc78] blk_freeze_queue at ffffffff82a4113a<br /> #4 [ff61d23de260fc90] blk_cleanup_queue at ffffffff82a33006<br /> #5 [ff61d23de260fcb0] nvme_rdma_destroy_admin_queue at ffffffffc12686ce<br /> #6 [ff61d23de260fcc8] nvme_rdma_setup_ctrl at ffffffffc1268ced<br /> #7 [ff61d23de260fd28] nvme_rdma_create_ctrl at ffffffffc126919b<br /> #8 [ff61d23de260fd68] nvmf_dev_write at ffffffffc024f362<br /> #9 [ff61d23de260fe38] vfs_write at ffffffff827d5f25<br /> RIP: 00007fda7891d574 RSP: 00007ffe2ef06958 RFLAGS: 00000202<br /> RAX: ffffffffffffffda RBX: 000055e8122a4d90 RCX: 00007fda7891d574<br /> RDX: 000000000000012b RSI: 000055e8122a4d90 RDI: 0000000000000004<br /> RBP: 00007ffe2ef079c0 R8: 000000000000012b R9: 000055e8122a4d90<br /> R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000004<br /> R13: 000055e8122923c0 R14: 000000000000012b R15: 00007fda78a54500<br /> ORIG_RAX: 0000000000000001 CS: 0033 SS: 002b<br /> <br /> This due to we have quiesced admi_q before cancel requests, but forgot<br /> to unquiesce before destroy it, as a result we fail to drain the<br /> pending requests, and hang on blk_mq_freeze_queue_wait() forever. Here<br /> try to reuse nvme_rdma_teardown_admin_queue() to fix this issue and<br /> simplify the code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dma-debug: fix a possible deadlock on radix_lock<br /> <br /> radix_lock() shouldn&amp;#39;t be held while holding dma_hash_entry[idx].lock<br /> otherwise, there&amp;#39;s a possible deadlock scenario when<br /> dma debug API is called holding rq_lock():<br /> <br /> CPU0 CPU1 CPU2<br /> dma_free_attrs()<br /> check_unmap() add_dma_entry() __schedule() //out<br /> (A) rq_lock()<br /> get_hash_bucket()<br /> (A) dma_entry_hash<br /> check_sync()<br /> (A) radix_lock() (W) dma_entry_hash<br /> dma_entry_free()<br /> (W) radix_lock()<br /> // CPU2&amp;#39;s one<br /> (W) rq_lock()<br /> <br /> CPU1 situation can happen when it extending radix tree and<br /> it tries to wake up kswapd via wake_all_kswapd().<br /> <br /> CPU2 situation can happen while perf_event_task_sched_out()<br /> (i.e. dma sync operation is called while deleting perf_event using<br /> etm and etr tmc which are Arm Coresight hwtracing driver backends).<br /> <br /> To remove this possible situation, call dma_entry_free() after<br /> put_hash_bucket() in check_unmap().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: check smcd_v2_ext_offset when receiving proposal msg<br /> <br /> When receiving proposal msg in server, the field smcd_v2_ext_offset in<br /> proposal msg is from the remote client and can not be fully trusted.<br /> Once the value of smcd_v2_ext_offset exceed the max value, there has<br /> the chance to access wrong address, and crash may happen.<br /> <br /> This patch checks the value of smcd_v2_ext_offset before using it.