Vulnerabilities

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 /> 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 /> 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 /> 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 /> 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 /> 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 /> 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 /> bpf: Prevent tailcall infinite loop caused by freplace<br /> <br /> There is a potential infinite loop issue that can occur when using a<br /> combination of tail calls and freplace.<br /> <br /> In an upcoming selftest, the attach target for entry_freplace of<br /> tailcall_freplace.c is subprog_tc of tc_bpf2bpf.c, while the tail call in<br /> entry_freplace leads to entry_tc. This results in an infinite loop:<br /> <br /> entry_tc -&gt; subprog_tc -&gt; entry_freplace --tailcall-&gt; entry_tc.<br /> <br /> The problem arises because the tail_call_cnt in entry_freplace resets to<br /> zero each time entry_freplace is executed, causing the tail call mechanism<br /> to never terminate, eventually leading to a kernel panic.<br /> <br /> To fix this issue, the solution is twofold:<br /> <br /> 1. Prevent updating a program extended by an freplace program to a<br /> prog_array map.<br /> 2. Prevent extending a program that is already part of a prog_array map<br /> with an freplace program.<br /> <br /> This ensures that:<br /> <br /> * If a program or its subprogram has been extended by an freplace program,<br /> it can no longer be updated to a prog_array map.<br /> * If a program has been added to a prog_array map, neither it nor its<br /> subprograms can be extended by an freplace program.<br /> <br /> Moreover, an extension program should not be tailcalled. As such, return<br /> -EINVAL if the program has a type of BPF_PROG_TYPE_EXT when adding it to a<br /> prog_array map.<br /> <br /> Additionally, fix a minor code style issue by replacing eight spaces with a<br /> tab for proper formatting.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dlm: fix possible lkb_resource null dereference<br /> <br /> This patch fixes a possible null pointer dereference when this function is<br /> called from request_lock() as lkb-&gt;lkb_resource is not assigned yet,<br /> only after validate_lock_args() by calling attach_lkb(). Another issue<br /> is that a resource name could be a non printable bytearray and we cannot<br /> assume to be ASCII coded.<br /> <br /> The log functionality is probably never being hit when DLM is used in<br /> normal way and no debug logging is enabled. The null pointer dereference<br /> can only occur on a new created lkb that does not have the resource<br /> assigned yet, it probably never hits the null pointer dereference but we<br /> should be sure that other changes might not change this behaviour and we<br /> actually can hit the mentioned null pointer dereference.<br /> <br /> In this patch we just drop the printout of the resource name, the lkb id<br /> is enough to make a possible connection to a resource name if this<br /> exists.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: check return value of ieee80211_probereq_get() for RNR<br /> <br /> The return value of ieee80211_probereq_get() might be NULL, so check it<br /> before using to avoid NULL pointer access.<br /> <br /> Addresses-Coverity-ID: 1529805 ("Dereference null return value")