Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> device property: fix of node refcount leak in fwnode_graph_get_next_endpoint()<br /> <br /> The &amp;#39;parent&amp;#39; returned by fwnode_graph_get_port_parent()<br /> with refcount incremented when &amp;#39;prev&amp;#39; is not NULL, it<br /> needs be put when finish using it.<br /> <br /> Because the parent is const, introduce a new variable to<br /> store the returned fwnode, then put it before returning<br /> from fwnode_graph_get_next_endpoint().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: Fix a buffer overflow in mgmt_mesh_add()<br /> <br /> Smatch Warning:<br /> net/bluetooth/mgmt_util.c:375 mgmt_mesh_add() error: __memcpy()<br /> &amp;#39;mesh_tx-&gt;param&amp;#39; too small (48 vs 50)<br /> <br /> Analysis:<br /> <br /> &amp;#39;mesh_tx-&gt;param&amp;#39; is array of size 48. This is the destination.<br /> u8 param[sizeof(struct mgmt_cp_mesh_send) + 29]; // 19 + 29 = 48.<br /> <br /> But in the caller &amp;#39;mesh_send&amp;#39; we reject only when len &gt; 50.<br /> len &gt; (MGMT_MESH_SEND_SIZE + 31) // 19 + 31 = 50.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: usb: sunplus: Fix potential null-ptr-deref in sp_usb_phy_probe()<br /> <br /> sp_usb_phy_probe() will call platform_get_resource_byname() that may fail<br /> and return NULL. devm_ioremap() will use usbphy-&gt;moon4_res_mem-&gt;start as<br /> input, which may causes null-ptr-deref. Check the ret value of<br /> platform_get_resource_byname() to avoid the null-ptr-deref.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_fs: Prevent race during ffs_ep0_queue_wait<br /> <br /> While performing fast composition switch, there is a possibility that the<br /> process of ffs_ep0_write/ffs_ep0_read get into a race condition<br /> due to ep0req being freed up from functionfs_unbind.<br /> <br /> Consider the scenario that the ffs_ep0_write calls the ffs_ep0_queue_wait<br /> by taking a lock &amp;ffs-&gt;ev.waitq.lock. However, the functionfs_unbind isn&amp;#39;t<br /> bounded so it can go ahead and mark the ep0req to NULL, and since there<br /> is no NULL check in ffs_ep0_queue_wait we will end up in use-after-free.<br /> <br /> Fix this by making a serialized execution between the two functions using<br /> a mutex_lock(ffs-&gt;mutex).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: Fix double increment of client_count in dma_chan_get()<br /> <br /> The first time dma_chan_get() is called for a channel the channel<br /> client_count is incorrectly incremented twice for public channels,<br /> first in balance_ref_count(), and again prior to returning. This<br /> results in an incorrect client count which will lead to the<br /> channel resources not being freed when they should be. A simple<br /> test of repeated module load and unload of async_tx on a Dell<br /> Power Edge R7425 also shows this resulting in a kref underflow<br /> warning.<br /> <br /> [ 124.329662] async_tx: api initialized (async)<br /> [ 129.000627] async_tx: api initialized (async)<br /> [ 130.047839] ------------[ cut here ]------------<br /> [ 130.052472] refcount_t: underflow; use-after-free.<br /> [ 130.057279] WARNING: CPU: 3 PID: 19364 at lib/refcount.c:28<br /> refcount_warn_saturate+0xba/0x110<br /> [ 130.065811] Modules linked in: async_tx(-) rfkill intel_rapl_msr<br /> intel_rapl_common amd64_edac edac_mce_amd ipmi_ssif kvm_amd dcdbas kvm<br /> mgag200 drm_shmem_helper acpi_ipmi irqbypass drm_kms_helper ipmi_si<br /> syscopyarea sysfillrect rapl pcspkr ipmi_devintf sysimgblt fb_sys_fops<br /> k10temp i2c_piix4 ipmi_msghandler acpi_power_meter acpi_cpufreq vfat<br /> fat drm fuse xfs libcrc32c sd_mod t10_pi sg ahci crct10dif_pclmul<br /> libahci crc32_pclmul crc32c_intel ghash_clmulni_intel igb megaraid_sas<br /> i40e libata i2c_algo_bit ccp sp5100_tco dca dm_mirror dm_region_hash<br /> dm_log dm_mod [last unloaded: async_tx]<br /> [ 130.117361] CPU: 3 PID: 19364 Comm: modprobe Kdump: loaded Not<br /> tainted 5.14.0-185.el9.x86_64 #1<br /> [ 130.126091] Hardware name: Dell Inc. PowerEdge R7425/02MJ3T, BIOS<br /> 1.18.0 01/17/2022<br /> [ 130.133806] RIP: 0010:refcount_warn_saturate+0xba/0x110<br /> [ 130.139041] Code: 01 01 e8 6d bd 55 00 0f 0b e9 72 9d 8a 00 80 3d<br /> 26 18 9c 01 00 75 85 48 c7 c7 f8 a3 03 9d c6 05 16 18 9c 01 01 e8 4a<br /> bd 55 00 0b e9 4f 9d 8a 00 80 3d 01 18 9c 01 00 0f 85 5e ff ff ff<br /> 48 c7<br /> [ 130.157807] RSP: 0018:ffffbf98898afe68 EFLAGS: 00010286<br /> [ 130.163036] RAX: 0000000000000000 RBX: ffff9da06028e598 RCX: 0000000000000000<br /> [ 130.170172] RDX: ffff9daf9de26480 RSI: ffff9daf9de198a0 RDI: ffff9daf9de198a0<br /> [ 130.177316] RBP: ffff9da7cddf3970 R08: 0000000000000000 R09: 00000000ffff7fff<br /> [ 130.184459] R10: ffffbf98898afd00 R11: ffffffff9d9e8c28 R12: ffff9da7cddf1970<br /> [ 130.191596] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000<br /> [ 130.198739] FS: 00007f646435c740(0000) GS:ffff9daf9de00000(0000)<br /> knlGS:0000000000000000<br /> [ 130.206832] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 130.212586] CR2: 00007f6463b214f0 CR3: 00000008ab98c000 CR4: 00000000003506e0<br /> [ 130.219729] Call Trace:<br /> [ 130.222192] <br /> [ 130.224305] dma_chan_put+0x10d/0x110<br /> [ 130.227988] dmaengine_put+0x7a/0xa0<br /> [ 130.231575] __do_sys_delete_module.constprop.0+0x178/0x280<br /> [ 130.237157] ? syscall_trace_enter.constprop.0+0x145/0x1d0<br /> [ 130.242652] do_syscall_64+0x5c/0x90<br /> [ 130.246240] ? exc_page_fault+0x62/0x150<br /> [ 130.250178] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [ 130.255243] RIP: 0033:0x7f6463a3f5ab<br /> [ 130.258830] Code: 73 01 c3 48 8b 0d 75 a8 1b 00 f7 d8 64 89 01 48<br /> 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00<br /> 00 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d 45 a8 1b 00 f7 d8 64 89<br /> 01 48<br /> [ 130.277591] RSP: 002b:00007fff22f972c8 EFLAGS: 00000206 ORIG_RAX:<br /> 00000000000000b0<br /> [ 130.285164] RAX: ffffffffffffffda RBX: 000055b6786edd40 RCX: 00007f6463a3f5ab<br /> [ 130.292303] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 000055b6786edda8<br /> [ 130.299443] RBP: 000055b6786edd40 R08: 0000000000000000 R09: 0000000000000000<br /> [ 130.306584] R10: 00007f6463b9eac0 R11: 0000000000000206 R12: 000055b6786edda8<br /> [ 130.313731] R13: 0000000000000000 R14: 000055b6786edda8 R15: 00007fff22f995f8<br /> [ 130.320875] <br /> [ 130.323081] ---[ end trace eff7156d56b5cf25 ]---<br /> <br /> cat /sys/class/dma/dma0chan*/in_use would get the wrong result.<br /> 2<br /> 2<br /> 2<br /> <br /> Test-by: Jie Hai

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> EDAC/highbank: Fix memory leak in highbank_mc_probe()<br /> <br /> When devres_open_group() fails, it returns -ENOMEM without freeing memory<br /> allocated by edac_mc_alloc().<br /> <br /> Call edac_mc_free() on the error handling path to avoid a memory leak.<br /> <br /> [ bp: Massage commit message. ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/uffd: fix pte marker when fork() without fork event<br /> <br /> Patch series "mm: Fixes on pte markers".<br /> <br /> Patch 1 resolves the syzkiller report from Pengfei.<br /> <br /> Patch 2 further harden pte markers when used with the recent swapin error<br /> markers. The major case is we should persist a swapin error marker after<br /> fork(), so child shouldn&amp;#39;t read a corrupted page.<br /> <br /> <br /> This patch (of 2):<br /> <br /> When fork(), dst_vma is not guaranteed to have VM_UFFD_WP even if src may<br /> have it and has pte marker installed. The warning is improper along with<br /> the comment. The right thing is to inherit the pte marker when needed, or<br /> keep the dst pte empty.<br /> <br /> A vague guess is this happened by an accident when there&amp;#39;s the prior patch<br /> to introduce src/dst vma into this helper during the uffd-wp feature got<br /> developed and I probably messed up in the rebase, since if we replace<br /> dst_vma with src_vma the warning &amp; comment it all makes sense too.<br /> <br /> Hugetlb did exactly the right here (copy_hugetlb_page_range()). Fix the<br /> general path.<br /> <br /> Reproducer:<br /> <br /> https://github.com/xupengfe/syzkaller_logs/blob/main/221208_115556_copy_page_range/repro.c<br /> <br /> Bugzilla report: https://bugzilla.kernel.org/show_bug.cgi?id=216808

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fpga: m10bmc-sec: Fix probe rollback<br /> <br /> Handle probe error rollbacks properly to avoid leaks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: imx-sdma: Fix a possible memory leak in sdma_transfer_init<br /> <br /> If the function sdma_load_context() fails, the sdma_desc will be<br /> freed, but the allocated desc-&gt;bd is forgot to be freed.<br /> <br /> We already met the sdma_load_context() failure case and the log as<br /> below:<br /> [ 450.699064] imx-sdma 30bd0000.dma-controller: Timeout waiting for CH0 ready<br /> ...<br /> <br /> In this case, the desc-&gt;bd will not be freed without this change.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs/zmap.c: Fix incorrect offset calculation<br /> <br /> Effective offset to add to length was being incorrectly calculated,<br /> which resulted in iomap-&gt;length being set to 0, triggering a WARN_ON<br /> in iomap_iter_done().<br /> <br /> Fix that, and describe it in comments.<br /> <br /> This was reported as a crash by syzbot under an issue about a warning<br /> encountered in iomap_iter_done(), but unrelated to erofs.<br /> <br /> C reproducer: https://syzkaller.appspot.com/text?tag=ReproC&amp;x=1037a6b2880000<br /> Kernel config: https://syzkaller.appspot.com/text?tag=KernelConfig&amp;x=e2021a61197ebe02<br /> Dashboard link: https://syzkaller.appspot.com/bug?extid=a8e049cd3abd342936b6

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/x86/amd: fix potential integer overflow on shift of a int<br /> <br /> The left shift of int 32 bit integer constant 1 is evaluated using 32 bit<br /> arithmetic and then passed as a 64 bit function argument. In the case where<br /> i is 32 or more this can lead to an overflow. Avoid this by shifting<br /> using the BIT_ULL macro instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: designware: use casting of u64 in clock multiplication to avoid overflow<br /> <br /> In functions i2c_dw_scl_lcnt() and i2c_dw_scl_hcnt() may have overflow<br /> by depending on the values of the given parameters including the ic_clk.<br /> For example in our use case where ic_clk is larger than one million,<br /> multiplication of ic_clk * 4700 will result in 32 bit overflow.<br /> <br /> Add cast of u64 to the calculation to avoid multiplication overflow, and<br /> use the corresponding define for divide.