Vulnerabilities

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")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: Get runtime PM before walking tree during disable_unused<br /> <br /> Doug reported [1] the following hung task:<br /> <br /> INFO: task swapper/0:1 blocked for more than 122 seconds.<br /> Not tainted 5.15.149-21875-gf795ebc40eb8 #1<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:swapper/0 state:D stack: 0 pid: 1 ppid: 0 flags:0x00000008<br /> Call trace:<br /> __switch_to+0xf4/0x1f4<br /> __schedule+0x418/0xb80<br /> schedule+0x5c/0x10c<br /> rpm_resume+0xe0/0x52c<br /> rpm_resume+0x178/0x52c<br /> __pm_runtime_resume+0x58/0x98<br /> clk_pm_runtime_get+0x30/0xb0<br /> clk_disable_unused_subtree+0x58/0x208<br /> clk_disable_unused_subtree+0x38/0x208<br /> clk_disable_unused_subtree+0x38/0x208<br /> clk_disable_unused_subtree+0x38/0x208<br /> clk_disable_unused_subtree+0x38/0x208<br /> clk_disable_unused+0x4c/0xe4<br /> do_one_initcall+0xcc/0x2d8<br /> do_initcall_level+0xa4/0x148<br /> do_initcalls+0x5c/0x9c<br /> do_basic_setup+0x24/0x30<br /> kernel_init_freeable+0xec/0x164<br /> kernel_init+0x28/0x120<br /> ret_from_fork+0x10/0x20<br /> INFO: task kworker/u16:0:9 blocked for more than 122 seconds.<br /> Not tainted 5.15.149-21875-gf795ebc40eb8 #1<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:kworker/u16:0 state:D stack: 0 pid: 9 ppid: 2 flags:0x00000008<br /> Workqueue: events_unbound deferred_probe_work_func<br /> Call trace:<br /> __switch_to+0xf4/0x1f4<br /> __schedule+0x418/0xb80<br /> schedule+0x5c/0x10c<br /> schedule_preempt_disabled+0x2c/0x48<br /> __mutex_lock+0x238/0x488<br /> __mutex_lock_slowpath+0x1c/0x28<br /> mutex_lock+0x50/0x74<br /> clk_prepare_lock+0x7c/0x9c<br /> clk_core_prepare_lock+0x20/0x44<br /> clk_prepare+0x24/0x30<br /> clk_bulk_prepare+0x40/0xb0<br /> mdss_runtime_resume+0x54/0x1c8<br /> pm_generic_runtime_resume+0x30/0x44<br /> __genpd_runtime_resume+0x68/0x7c<br /> genpd_runtime_resume+0x108/0x1f4<br /> __rpm_callback+0x84/0x144<br /> rpm_callback+0x30/0x88<br /> rpm_resume+0x1f4/0x52c<br /> rpm_resume+0x178/0x52c<br /> __pm_runtime_resume+0x58/0x98<br /> __device_attach+0xe0/0x170<br /> device_initial_probe+0x1c/0x28<br /> bus_probe_device+0x3c/0x9c<br /> device_add+0x644/0x814<br /> mipi_dsi_device_register_full+0xe4/0x170<br /> devm_mipi_dsi_device_register_full+0x28/0x70<br /> ti_sn_bridge_probe+0x1dc/0x2c0<br /> auxiliary_bus_probe+0x4c/0x94<br /> really_probe+0xcc/0x2c8<br /> __driver_probe_device+0xa8/0x130<br /> driver_probe_device+0x48/0x110<br /> __device_attach_driver+0xa4/0xcc<br /> bus_for_each_drv+0x8c/0xd8<br /> __device_attach+0xf8/0x170<br /> device_initial_probe+0x1c/0x28<br /> bus_probe_device+0x3c/0x9c<br /> deferred_probe_work_func+0x9c/0xd8<br /> process_one_work+0x148/0x518<br /> worker_thread+0x138/0x350<br /> kthread+0x138/0x1e0<br /> ret_from_fork+0x10/0x20<br /> <br /> The first thread is walking the clk tree and calling<br /> clk_pm_runtime_get() to power on devices required to read the clk<br /> hardware via struct clk_ops::is_enabled(). This thread holds the clk<br /> prepare_lock, and is trying to runtime PM resume a device, when it finds<br /> that the device is in the process of resuming so the thread schedule()s<br /> away waiting for the device to finish resuming before continuing. The<br /> second thread is runtime PM resuming the same device, but the runtime<br /> resume callback is calling clk_prepare(), trying to grab the<br /> prepare_lock waiting on the first thread.<br /> <br /> This is a classic ABBA deadlock. To properly fix the deadlock, we must<br /> never runtime PM resume or suspend a device with the clk prepare_lock<br /> held. Actually doing that is near impossible today because the global<br /> prepare_lock would have to be dropped in the middle of the tree, the<br /> device runtime PM resumed/suspended, and then the prepare_lock grabbed<br /> again to ensure consistency of the clk tree topology. If anything<br /> changes with the clk tree in the meantime, we&amp;#39;ve lost and will need to<br /> start the operation all over again.<br /> <br /> Luckily, most of the time we&amp;#39;re simply incrementing or decrementing the<br /> runtime PM count on an active device, so we don&amp;#39;t have the chance to<br /> schedule away with the prepare_lock held. Let&amp;#39;s fix this immediate<br /> problem that can be<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: vmk80xx: fix incomplete endpoint checking<br /> <br /> While vmk80xx does have endpoint checking implemented, some things<br /> can fall through the cracks. Depending on the hardware model,<br /> URBs can have either bulk or interrupt type, and current version<br /> of vmk80xx_find_usb_endpoints() function does not take that fully<br /> into account. While this warning does not seem to be too harmful,<br /> at the very least it will crash systems with &amp;#39;panic_on_warn&amp;#39; set on<br /> them.<br /> <br /> Fix the issue found by Syzkaller [1] by somewhat simplifying the<br /> endpoint checking process with usb_find_common_endpoints() and<br /> ensuring that only expected endpoint types are present.<br /> <br /> This patch has not been tested on real hardware.<br /> <br /> [1] Syzkaller report:<br /> usb 1-1: BOGUS urb xfer, pipe 1 != type 3<br /> WARNING: CPU: 0 PID: 781 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503<br /> ...<br /> Call Trace:<br /> <br /> usb_start_wait_urb+0x113/0x520 drivers/usb/core/message.c:59<br /> vmk80xx_reset_device drivers/comedi/drivers/vmk80xx.c:227 [inline]<br /> vmk80xx_auto_attach+0xa1c/0x1a40 drivers/comedi/drivers/vmk80xx.c:818<br /> comedi_auto_config+0x238/0x380 drivers/comedi/drivers.c:1067<br /> usb_probe_interface+0x5cd/0xb00 drivers/usb/core/driver.c:399<br /> ...<br /> <br /> Similar issue also found by Syzkaller:

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: mxs-auart: add spinlock around changing cts state<br /> <br /> The uart_handle_cts_change() function in serial_core expects the caller<br /> to hold uport-&gt;lock. For example, I have seen the below kernel splat,<br /> when the Bluetooth driver is loaded on an i.MX28 board.<br /> <br /> [ 85.119255] ------------[ cut here ]------------<br /> [ 85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec<br /> [ 85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs<br /> [ 85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1<br /> [ 85.151396] Hardware name: Freescale MXS (Device Tree)<br /> [ 85.156679] Workqueue: hci0 hci_power_on [bluetooth]<br /> (...)<br /> [ 85.191765] uart_handle_cts_change from mxs_auart_irq_handle+0x380/0x3f4<br /> [ 85.198787] mxs_auart_irq_handle from __handle_irq_event_percpu+0x88/0x210<br /> (...)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: sysfs: Fix reference leak in sysfs_break_active_protection()<br /> <br /> The sysfs_break_active_protection() routine has an obvious reference<br /> leak in its error path. If the call to kernfs_find_and_get() fails then<br /> kn will be NULL, so the companion sysfs_unbreak_active_protection()<br /> routine won&amp;#39;t get called (and would only cause an access violation by<br /> trying to dereference kn-&gt;parent if it was called). As a result, the<br /> reference to kobj acquired at the start of the function will never be<br /> released.<br /> <br /> Fix the leak by adding an explicit kobject_put() call when kn is NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: tcpm: Correct the PDO counting in pd_set<br /> <br /> Off-by-one errors happen because nr_snk_pdo and nr_src_pdo are<br /> incorrectly added one. The index of the loop is equal to the number of<br /> PDOs to be updated when leaving the loop and it doesn&amp;#39;t need to be added<br /> one.<br /> <br /> When doing the power negotiation, TCPM relies on the "nr_snk_pdo" as<br /> the size of the local sink PDO array to match the Source capabilities<br /> of the partner port. If the off-by-one overflow occurs, a wrong RDO<br /> might be sent and unexpected power transfer might happen such as over<br /> voltage or over current (than expected).<br /> <br /> "nr_src_pdo" is used to set the Rp level when the port is in Source<br /> role. It is also the array size of the local Source capabilities when<br /> filling up the buffer which will be sent as the Source PDOs (such as<br /> in Power Negotiation). If the off-by-one overflow occurs, a wrong Rp<br /> level might be set and wrong Source PDOs will be sent to the partner<br /> port. This could potentially cause over current or port resets.