Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_set_pipapo: walk over current view on netlink dump<br /> <br /> The generation mask can be updated while netlink dump is in progress.<br /> The pipapo set backend walk iterator cannot rely on it to infer what<br /> view of the datastructure is to be used. Add notation to specify if user<br /> wants to read/update the set.<br /> <br /> Based on patch from Florian Westphal.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: br_netfilter: skip conntrack input hook for promisc packets<br /> <br /> For historical reasons, when bridge device is in promisc mode, packets<br /> that are directed to the taps follow bridge input hook path. This patch<br /> adds a workaround to reset conntrack for these packets.<br /> <br /> Jianbo Liu reports warning splats in their test infrastructure where<br /> cloned packets reach the br_netfilter input hook to confirm the<br /> conntrack object.<br /> <br /> Scratch one bit from BR_INPUT_SKB_CB to annotate that this packet has<br /> reached the input hook because it is passed up to the bridge device to<br /> reach the taps.<br /> <br /> [ 57.571874] WARNING: CPU: 1 PID: 0 at net/bridge/br_netfilter_hooks.c:616 br_nf_local_in+0x157/0x180 [br_netfilter]<br /> [ 57.572749] Modules linked in: xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat xt_addrtype xt_conntrack nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_isc si ib_umad rdma_cm ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core mlx5ctl mlx5_core<br /> [ 57.575158] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0+ #19<br /> [ 57.575700] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> [ 57.576662] RIP: 0010:br_nf_local_in+0x157/0x180 [br_netfilter]<br /> [ 57.577195] Code: fe ff ff 41 bd 04 00 00 00 be 04 00 00 00 e9 4a ff ff ff be 04 00 00 00 48 89 ef e8 f3 a9 3c e1 66 83 ad b4 00 00 00 04 eb 91 0b e9 f1 fe ff ff 0f 0b e9 df fe ff ff 48 89 df e8 b3 53 47 e1<br /> [ 57.578722] RSP: 0018:ffff88885f845a08 EFLAGS: 00010202<br /> [ 57.579207] RAX: 0000000000000002 RBX: ffff88812dfe8000 RCX: 0000000000000000<br /> [ 57.579830] RDX: ffff88885f845a60 RSI: ffff8881022dc300 RDI: 0000000000000000<br /> [ 57.580454] RBP: ffff88885f845a60 R08: 0000000000000001 R09: 0000000000000003<br /> [ 57.581076] R10: 00000000ffff1300 R11: 0000000000000002 R12: 0000000000000000<br /> [ 57.581695] R13: ffff8881047ffe00 R14: ffff888108dbee00 R15: ffff88814519b800<br /> [ 57.582313] FS: 0000000000000000(0000) GS:ffff88885f840000(0000) knlGS:0000000000000000<br /> [ 57.583040] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 57.583564] CR2: 000000c4206aa000 CR3: 0000000103847001 CR4: 0000000000370eb0<br /> [ 57.584194] DR0: 0000000000000000 DR1: 0000000000000000 DR2:<br /> 0000000000000000<br /> [ 57.584820] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:<br /> 0000000000000400<br /> [ 57.585440] Call Trace:<br /> [ 57.585721] <br /> [ 57.585976] ? __warn+0x7d/0x130<br /> [ 57.586323] ? br_nf_local_in+0x157/0x180 [br_netfilter]<br /> [ 57.586811] ? report_bug+0xf1/0x1c0<br /> [ 57.587177] ? handle_bug+0x3f/0x70<br /> [ 57.587539] ? exc_invalid_op+0x13/0x60<br /> [ 57.587929] ? asm_exc_invalid_op+0x16/0x20<br /> [ 57.588336] ? br_nf_local_in+0x157/0x180 [br_netfilter]<br /> [ 57.588825] nf_hook_slow+0x3d/0xd0<br /> [ 57.589188] ? br_handle_vlan+0x4b/0x110<br /> [ 57.589579] br_pass_frame_up+0xfc/0x150<br /> [ 57.589970] ? br_port_flags_change+0x40/0x40<br /> [ 57.590396] br_handle_frame_finish+0x346/0x5e0<br /> [ 57.590837] ? ipt_do_table+0x32e/0x430<br /> [ 57.591221] ? br_handle_local_finish+0x20/0x20<br /> [ 57.591656] br_nf_hook_thresh+0x4b/0xf0 [br_netfilter]<br /> [ 57.592286] ? br_handle_local_finish+0x20/0x20<br /> [ 57.592802] br_nf_pre_routing_finish+0x178/0x480 [br_netfilter]<br /> [ 57.593348] ? br_handle_local_finish+0x20/0x20<br /> [ 57.593782] ? nf_nat_ipv4_pre_routing+0x25/0x60 [nf_nat]<br /> [ 57.594279] br_nf_pre_routing+0x24c/0x550 [br_netfilter]<br /> [ 57.594780] ? br_nf_hook_thresh+0xf0/0xf0 [br_netfilter]<br /> [ 57.595280] br_handle_frame+0x1f3/0x3d0<br /> [ 57.595676] ? br_handle_local_finish+0x20/0x20<br /> [ 57.596118] ? br_handle_frame_finish+0x5e0/0x5e0<br /> [ 57.596566] __netif_receive_skb_core+0x25b/0xfc0<br /> [ 57.597017] ? __napi_build_skb+0x37/0x40<br /> [ 57.597418] __netif_receive_skb_list_core+0xfb/0x220

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()<br /> <br /> nft_unregister_obj() can concurrent with __nft_obj_type_get(),<br /> and there is not any protection when iterate over nf_tables_objects<br /> list in __nft_obj_type_get(). Therefore, there is potential data-race<br /> of nf_tables_objects list entry.<br /> <br /> Use list_for_each_entry_rcu() to iterate over nf_tables_objects<br /> list in __nft_obj_type_get(), and use rcu_read_lock() in the caller<br /> nft_obj_type_get() to protect the entire type query process.

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 /> netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get()<br /> <br /> nft_unregister_expr() can concurrent with __nft_expr_type_get(),<br /> and there is not any protection when iterate over nf_tables_expressions<br /> list in __nft_expr_type_get(). Therefore, there is potential data-race<br /> of nf_tables_expressions list entry.<br /> <br /> Use list_for_each_entry_rcu() to iterate over nf_tables_expressions<br /> list in __nft_expr_type_get(), and use rcu_read_lock() in the caller<br /> nft_expr_type_get() to protect the entire type query process.

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 /> 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.