Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> r8169: fix LED-related deadlock on module removal<br /> <br /> Binding devm_led_classdev_register() to the netdev is problematic<br /> because on module removal we get a RTNL-related deadlock. Fix this<br /> by avoiding the device-managed LED functions.<br /> <br /> Note: We can safely call led_classdev_unregister() for a LED even<br /> if registering it failed, because led_classdev_unregister() detects<br /> this and is a no-op in this case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thermal/debugfs: Add missing count increment to thermal_debug_tz_trip_up()<br /> <br /> The count field in struct trip_stats, representing the number of times<br /> the zone temperature was above the trip point, needs to be incremented<br /> in thermal_debug_tz_trip_up(), for two reasons.<br /> <br /> First, if a trip point is crossed on the way up for the first time,<br /> thermal_debug_update_temp() called from update_temperature() does<br /> not see it because it has not been added to trips_crossed[] array<br /> in the thermal zone&amp;#39;s struct tz_debugfs object yet. Therefore, when<br /> thermal_debug_tz_trip_up() is called after that, the trip point&amp;#39;s<br /> count value is 0, and the attempt to divide by it during the average<br /> temperature computation leads to a divide error which causes the kernel<br /> to crash. Setting the count to 1 before the division by incrementing it<br /> fixes this problem.<br /> <br /> Second, if a trip point is crossed on the way up, but it has been<br /> crossed on the way up already before, its count value needs to be<br /> incremented to make a record of the fact that the zone temperature is<br /> above the trip now. Without doing that, if the mitigations applied<br /> after crossing the trip cause the zone temperature to drop below its<br /> threshold, the count will not be updated for this episode at all and<br /> the average temperature in the trip statistics record will be somewhat<br /> higher than it should be.<br /> <br /> Cc :6.8+ # 6.8+

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> userfaultfd: change src_folio after ensuring it&amp;#39;s unpinned in UFFDIO_MOVE<br /> <br /> Commit d7a08838ab74 ("mm: userfaultfd: fix unexpected change to src_folio<br /> when UFFDIO_MOVE fails") moved the src_folio-&gt;{mapping, index} changing to<br /> after clearing the page-table and ensuring that it&amp;#39;s not pinned. This<br /> avoids failure of swapout+migration and possibly memory corruption.<br /> <br /> However, the commit missed fixing it in the huge-page case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/cio: fix race condition during online processing<br /> <br /> A race condition exists in ccw_device_set_online() that can cause the<br /> online process to fail, leaving the affected device in an inconsistent<br /> state. As a result, subsequent attempts to set that device online fail<br /> with return code ENODEV.<br /> <br /> The problem occurs when a path verification request arrives after<br /> a wait for final device state completed, but before the result state<br /> is evaluated.<br /> <br /> Fix this by ensuring that the CCW-device lock is held between<br /> determining final state and checking result state.<br /> <br /> Note that since:<br /> <br /> commit 2297791c92d0 ("s390/cio: dont unregister subchannel from child-drivers")<br /> <br /> path verification requests are much more likely to occur during boot,<br /> resulting in an increased chance of this race condition occurring.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: Fix mirred deadlock on device recursion<br /> <br /> When the mirred action is used on a classful egress qdisc and a packet is<br /> mirrored or redirected to self we hit a qdisc lock deadlock.<br /> See trace below.<br /> <br /> [..... other info removed for brevity....]<br /> [ 82.890906]<br /> [ 82.890906] ============================================<br /> [ 82.890906] WARNING: possible recursive locking detected<br /> [ 82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G W<br /> [ 82.890906] --------------------------------------------<br /> [ 82.890906] ping/418 is trying to acquire lock:<br /> [ 82.890906] ffff888006994110 (&amp;sch-&gt;q.lock){+.-.}-{3:3}, at:<br /> __dev_queue_xmit+0x1778/0x3550<br /> [ 82.890906]<br /> [ 82.890906] but task is already holding lock:<br /> [ 82.890906] ffff888006994110 (&amp;sch-&gt;q.lock){+.-.}-{3:3}, at:<br /> __dev_queue_xmit+0x1778/0x3550<br /> [ 82.890906]<br /> [ 82.890906] other info that might help us debug this:<br /> [ 82.890906] Possible unsafe locking scenario:<br /> [ 82.890906]<br /> [ 82.890906] CPU0<br /> [ 82.890906] ----<br /> [ 82.890906] lock(&amp;sch-&gt;q.lock);<br /> [ 82.890906] lock(&amp;sch-&gt;q.lock);<br /> [ 82.890906]<br /> [ 82.890906] *** DEADLOCK ***<br /> [ 82.890906]<br /> [..... other info removed for brevity....]<br /> <br /> Example setup (eth0-&gt;eth0) to recreate<br /> tc qdisc add dev eth0 root handle 1: htb default 30<br /> tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \<br /> action mirred egress redirect dev eth0<br /> <br /> Another example(eth0-&gt;eth1-&gt;eth0) to recreate<br /> tc qdisc add dev eth0 root handle 1: htb default 30<br /> tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \<br /> action mirred egress redirect dev eth1<br /> <br /> tc qdisc add dev eth1 root handle 1: htb default 30<br /> tc filter add dev eth1 handle 1: protocol ip prio 2 matchall \<br /> action mirred egress redirect dev eth0<br /> <br /> We fix this by adding an owner field (CPU id) to struct Qdisc set after<br /> root qdisc is entered. When the softirq enters it a second time, if the<br /> qdisc owner is the same CPU, the packet is dropped to break the loop.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: fix memleak in map from abort path<br /> <br /> The delete set command does not rely on the transaction object for<br /> element removal, therefore, a combination of delete element + delete set<br /> from the abort path could result in restoring twice the refcount of the<br /> mapping.<br /> <br /> Check for inactive element in the next generation for the delete element<br /> command in the abort path, skip restoring state if next generation bit<br /> has been already cleared. This is similar to the activate logic using<br /> the set walk iterator.<br /> <br /> [ 6170.286929] ------------[ cut here ]------------<br /> [ 6170.286939] WARNING: CPU: 6 PID: 790302 at net/netfilter/nf_tables_api.c:2086 nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]<br /> [ 6170.287071] Modules linked in: [...]<br /> [ 6170.287633] CPU: 6 PID: 790302 Comm: kworker/6:2 Not tainted 6.9.0-rc3+ #365<br /> [ 6170.287768] RIP: 0010:nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]<br /> [ 6170.287886] Code: df 48 8d 7d 58 e8 69 2e 3b df 48 8b 7d 58 e8 80 1b 37 df 48 8d 7d 68 e8 57 2e 3b df 48 8b 7d 68 e8 6e 1b 37 df 48 89 ef eb c4 0b 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 0f<br /> [ 6170.287895] RSP: 0018:ffff888134b8fd08 EFLAGS: 00010202<br /> [ 6170.287904] RAX: 0000000000000001 RBX: ffff888125bffb28 RCX: dffffc0000000000<br /> [ 6170.287912] RDX: 0000000000000003 RSI: ffffffffa20298ab RDI: ffff88811ebe4750<br /> [ 6170.287919] RBP: ffff88811ebe4700 R08: ffff88838e812650 R09: fffffbfff0623a55<br /> [ 6170.287926] R10: ffffffff8311d2af R11: 0000000000000001 R12: ffff888125bffb10<br /> [ 6170.287933] R13: ffff888125bffb10 R14: dead000000000122 R15: dead000000000100<br /> [ 6170.287940] FS: 0000000000000000(0000) GS:ffff888390b00000(0000) knlGS:0000000000000000<br /> [ 6170.287948] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 6170.287955] CR2: 00007fd31fc00710 CR3: 0000000133f60004 CR4: 00000000001706f0<br /> [ 6170.287962] Call Trace:<br /> [ 6170.287967] <br /> [ 6170.287973] ? __warn+0x9f/0x1a0<br /> [ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]<br /> [ 6170.288092] ? report_bug+0x1b1/0x1e0<br /> [ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]<br /> [ 6170.288092] ? report_bug+0x1b1/0x1e0<br /> [ 6170.288104] ? handle_bug+0x3c/0x70<br /> [ 6170.288112] ? exc_invalid_op+0x17/0x40<br /> [ 6170.288120] ? asm_exc_invalid_op+0x1a/0x20<br /> [ 6170.288132] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]<br /> [ 6170.288243] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]<br /> [ 6170.288366] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]<br /> [ 6170.288483] nf_tables_trans_destroy_work+0x588/0x590 [nf_tables]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: restore set elements when delete set fails<br /> <br /> From abort path, nft_mapelem_activate() needs to restore refcounters to<br /> the original state. Currently, it uses the set-&gt;ops-&gt;walk() to iterate<br /> over these set elements. The existing set iterator skips inactive<br /> elements in the next generation, this does not work from the abort path<br /> to restore the original state since it has to skip active elements<br /> instead (not inactive ones).<br /> <br /> This patch moves the check for inactive elements to the set iterator<br /> callback, then it reverses the logic for the .activate case which<br /> needs to skip active elements.<br /> <br /> Toggle next generation bit for elements when delete set command is<br /> invoked and call nft_clear() from .activate (abort) path to restore the<br /> next generation bit.<br /> <br /> The splat below shows an object in mappings memleak:<br /> <br /> [43929.457523] ------------[ cut here ]------------<br /> [43929.457532] WARNING: CPU: 0 PID: 1139 at include/net/netfilter/nf_tables.h:1237 nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]<br /> [...]<br /> [43929.458014] RIP: 0010:nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]<br /> [43929.458076] Code: 83 f8 01 77 ab 49 8d 7c 24 08 e8 37 5e d0 de 49 8b 6c 24 08 48 8d 7d 50 e8 e9 5c d0 de 8b 45 50 8d 50 ff 89 55 50 85 c0 75 86 0b eb 82 0f 0b eb b3 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90<br /> [43929.458081] RSP: 0018:ffff888140f9f4b0 EFLAGS: 00010246<br /> [43929.458086] RAX: 0000000000000000 RBX: ffff8881434f5288 RCX: dffffc0000000000<br /> [43929.458090] RDX: 00000000ffffffff RSI: ffffffffa26d28a7 RDI: ffff88810ecc9550<br /> [43929.458093] RBP: ffff88810ecc9500 R08: 0000000000000001 R09: ffffed10281f3e8f<br /> [43929.458096] R10: 0000000000000003 R11: ffff0000ffff0000 R12: ffff8881434f52a0<br /> [43929.458100] R13: ffff888140f9f5f4 R14: ffff888151c7a800 R15: 0000000000000002<br /> [43929.458103] FS: 00007f0c687c4740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000<br /> [43929.458107] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [43929.458111] CR2: 00007f58dbe5b008 CR3: 0000000123602005 CR4: 00000000001706f0<br /> [43929.458114] Call Trace:<br /> [43929.458118] <br /> [43929.458121] ? __warn+0x9f/0x1a0<br /> [43929.458127] ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]<br /> [43929.458188] ? report_bug+0x1b1/0x1e0<br /> [43929.458196] ? handle_bug+0x3c/0x70<br /> [43929.458200] ? exc_invalid_op+0x17/0x40<br /> [43929.458211] ? nft_setelem_data_deactivate+0xd7/0xf0 [nf_tables]<br /> [43929.458271] ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables]<br /> [43929.458332] nft_mapelem_deactivate+0x24/0x30 [nf_tables]<br /> [43929.458392] nft_rhash_walk+0xdd/0x180 [nf_tables]<br /> [43929.458453] ? __pfx_nft_rhash_walk+0x10/0x10 [nf_tables]<br /> [43929.458512] ? rb_insert_color+0x2e/0x280<br /> [43929.458520] nft_map_deactivate+0xdc/0x1e0 [nf_tables]<br /> [43929.458582] ? __pfx_nft_map_deactivate+0x10/0x10 [nf_tables]<br /> [43929.458642] ? __pfx_nft_mapelem_deactivate+0x10/0x10 [nf_tables]<br /> [43929.458701] ? __rcu_read_unlock+0x46/0x70<br /> [43929.458709] nft_delset+0xff/0x110 [nf_tables]<br /> [43929.458769] nft_flush_table+0x16f/0x460 [nf_tables]<br /> [43929.458830] nf_tables_deltable+0x501/0x580 [nf_tables]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tun: limit printing rate when illegal packet received by tun dev<br /> <br /> vhost_worker will call tun call backs to receive packets. If too many<br /> illegal packets arrives, tun_do_read will keep dumping packet contents.<br /> When console is enabled, it will costs much more cpu time to dump<br /> packet and soft lockup will be detected.<br /> <br /> net_ratelimit mechanism can be used to limit the dumping rate.<br /> <br /> PID: 33036 TASK: ffff949da6f20000 CPU: 23 COMMAND: "vhost-32980"<br /> #0 [fffffe00003fce50] crash_nmi_callback at ffffffff89249253<br /> #1 [fffffe00003fce58] nmi_handle at ffffffff89225fa3<br /> #2 [fffffe00003fceb0] default_do_nmi at ffffffff8922642e<br /> #3 [fffffe00003fced0] do_nmi at ffffffff8922660d<br /> #4 [fffffe00003fcef0] end_repeat_nmi at ffffffff89c01663<br /> [exception RIP: io_serial_in+20]<br /> RIP: ffffffff89792594 RSP: ffffa655314979e8 RFLAGS: 00000002<br /> RAX: ffffffff89792500 RBX: ffffffff8af428a0 RCX: 0000000000000000<br /> RDX: 00000000000003fd RSI: 0000000000000005 RDI: ffffffff8af428a0<br /> RBP: 0000000000002710 R8: 0000000000000004 R9: 000000000000000f<br /> R10: 0000000000000000 R11: ffffffff8acbf64f R12: 0000000000000020<br /> R13: ffffffff8acbf698 R14: 0000000000000058 R15: 0000000000000000<br /> ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018<br /> #5 [ffffa655314979e8] io_serial_in at ffffffff89792594<br /> #6 [ffffa655314979e8] wait_for_xmitr at ffffffff89793470<br /> #7 [ffffa65531497a08] serial8250_console_putchar at ffffffff897934f6<br /> #8 [ffffa65531497a20] uart_console_write at ffffffff8978b605<br /> #9 [ffffa65531497a48] serial8250_console_write at ffffffff89796558<br /> #10 [ffffa65531497ac8] console_unlock at ffffffff89316124<br /> #11 [ffffa65531497b10] vprintk_emit at ffffffff89317c07<br /> #12 [ffffa65531497b68] printk at ffffffff89318306<br /> #13 [ffffa65531497bc8] print_hex_dump at ffffffff89650765<br /> #14 [ffffa65531497ca8] tun_do_read at ffffffffc0b06c27 [tun]<br /> #15 [ffffa65531497d38] tun_recvmsg at ffffffffc0b06e34 [tun]<br /> #16 [ffffa65531497d68] handle_rx at ffffffffc0c5d682 [vhost_net]<br /> #17 [ffffa65531497ed0] vhost_worker at ffffffffc0c644dc [vhost]<br /> #18 [ffffa65531497f10] kthread at ffffffff892d2e72<br /> #19 [ffffa65531497f50] ret_from_fork at ffffffff89c0022f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: nv04: Fix out of bounds access<br /> <br /> When Output Resource (dcb-&gt;or) value is assigned in<br /> fabricate_dcb_output(), there may be out of bounds access to<br /> dac_users array in case dcb-&gt;or is zero because ffs(dcb-&gt;or) is<br /> used as index there.<br /> The &amp;#39;or&amp;#39; argument of fabricate_dcb_output() must be interpreted as a<br /> number of bit to set, not value.<br /> <br /> Utilize macros from &amp;#39;enum nouveau_or&amp;#39; in calls instead of hardcoding.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: mediatek: Do a runtime PM get on controllers during probe<br /> <br /> mt8183-mfgcfg has a mutual dependency with genpd during the probing<br /> stage, which leads to a deadlock in the following call stack:<br /> <br /> CPU0: genpd_lock --&gt; clk_prepare_lock<br /> genpd_power_off_work_fn()<br /> genpd_lock()<br /> generic_pm_domain::power_off()<br /> clk_unprepare()<br /> clk_prepare_lock()<br /> <br /> CPU1: clk_prepare_lock --&gt; genpd_lock<br /> clk_register()<br /> __clk_core_init()<br /> clk_prepare_lock()<br /> clk_pm_runtime_get()<br /> genpd_lock()<br /> <br /> Do a runtime PM get at the probe function to make sure clk_register()<br /> won&amp;#39;t acquire the genpd lock. Instead of only modifying mt8183-mfgcfg,<br /> do this on all mediatek clock controller probings because we don&amp;#39;t<br /> believe this would cause any regression.<br /> <br /> Verified on MT8183 and MT8192 Chromebooks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: Get runtime PM before walking tree for clk_summary<br /> <br /> Similar to the previous commit, we should make sure that all devices are<br /> runtime resumed before printing the clk_summary through debugfs. Failure<br /> to do so would result in a deadlock if the thread is resuming a device<br /> to print clk state and that device is also runtime resuming in another<br /> thread, e.g the screen is turning on and the display driver is starting<br /> up. We remove the calls to clk_pm_runtime_{get,put}() in this path<br /> because they&amp;#39;re superfluous now that we know the devices are runtime<br /> resumed. This also squashes a bug where the return value of<br /> clk_pm_runtime_get() wasn&amp;#39;t checked, leading to an RPM count underflow<br /> on error paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> interconnect: Don&amp;#39;t access req_list while it&amp;#39;s being manipulated<br /> <br /> The icc_lock mutex was split into separate icc_lock and icc_bw_lock<br /> mutexes in [1] to avoid lockdep splats. However, this didn&amp;#39;t adequately<br /> protect access to icc_node::req_list.<br /> <br /> The icc_set_bw() function will eventually iterate over req_list while<br /> only holding icc_bw_lock, but req_list can be modified while only<br /> holding icc_lock. This causes races between icc_set_bw(), of_icc_get(),<br /> and icc_put().<br /> <br /> Example A:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> icc_set_bw(path_a)<br /> mutex_lock(&amp;icc_bw_lock);<br /> icc_put(path_b)<br /> mutex_lock(&amp;icc_lock);<br /> aggregate_requests()<br /> hlist_for_each_entry(r, ...<br /> hlist_del(...<br /> <br /> <br /> Example B:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> icc_set_bw(path_a)<br /> mutex_lock(&amp;icc_bw_lock);<br /> path_b = of_icc_get()<br /> of_icc_get_by_index()<br /> mutex_lock(&amp;icc_lock);<br /> path_find()<br /> path_init()<br /> aggregate_requests()<br /> hlist_for_each_entry(r, ...<br /> hlist_add_head(...<br /> <br /> <br /> Fix this by ensuring icc_bw_lock is always held before manipulating<br /> icc_node::req_list. The additional places icc_bw_lock is held don&amp;#39;t<br /> perform any memory allocations, so we should still be safe from the<br /> original lockdep splats that motivated the separate locks.<br /> <br /> [1] commit af42269c3523 ("interconnect: Fix locking for runpm vs reclaim")