Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: fix a double-free in arfs_create_groups<br /> <br /> When `in` allocated by kvzalloc fails, arfs_create_groups will free<br /> ft-&gt;g and return an error. However, arfs_create_table, the only caller of<br /> arfs_create_groups, will hold this error and call to<br /> mlx5e_destroy_flow_table, in which the ft-&gt;g will be freed again.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dpll: fix pin dump crash for rebound module<br /> <br /> When a kernel module is unbound but the pin resources were not entirely<br /> freed (other kernel module instance of the same PCI device have had kept<br /> the reference to that pin), and kernel module is again bound, the pin<br /> properties would not be updated (the properties are only assigned when<br /> memory for the pin is allocated), prop pointer still points to the<br /> kernel module memory of the kernel module which was deallocated on the<br /> unbind.<br /> <br /> If the pin dump is invoked in this state, the result is a kernel crash.<br /> Prevent the crash by storing persistent pin properties in dpll subsystem,<br /> copy the content from the kernel module when pin is allocated, instead of<br /> using memory of the kernel module.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: fix potential sta-link leak<br /> <br /> When a station is allocated, links are added but not<br /> set to valid yet (e.g. during connection to an AP MLD),<br /> we might remove the station without ever marking links<br /> valid, and leak them. Fix that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mvpp2: clear BM pool before initialization<br /> <br /> Register value persist after booting the kernel using<br /> kexec which results in kernel panic. Thus clear the<br /> BM pool registers before initialisation to fix the issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/lima: fix a memleak in lima_heap_alloc<br /> <br /> When lima_vm_map_bo fails, the resources need to be deallocated, or<br /> there will be memleaks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: Fix release of pinned pages when __io_uaddr_map fails<br /> <br /> Looking at the error path of __io_uaddr_map, if we fail after pinning<br /> the pages for any reasons, ret will be set to -EINVAL and the error<br /> handler won&amp;#39;t properly release the pinned pages.<br /> <br /> I didn&amp;#39;t manage to trigger it without forcing a failure, but it can<br /> happen in real life when memory is heavily fragmented.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bcachefs: kvfree bch_fs::snapshots in bch2_fs_snapshots_exit<br /> <br /> bch_fs::snapshots is allocated by kvzalloc in __snapshot_t_mut.<br /> It should be freed by kvfree not kfree.<br /> Or umount will triger:<br /> <br /> [ 406.829178 ] BUG: unable to handle page fault for address: ffffe7b487148008<br /> [ 406.830676 ] #PF: supervisor read access in kernel mode<br /> [ 406.831643 ] #PF: error_code(0x0000) - not-present page<br /> [ 406.832487 ] PGD 0 P4D 0<br /> [ 406.832898 ] Oops: 0000 [#1] PREEMPT SMP PTI<br /> [ 406.833512 ] CPU: 2 PID: 1754 Comm: umount Kdump: loaded Tainted: G OE 6.7.0-rc7-custom+ #90<br /> [ 406.834746 ] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014<br /> [ 406.835796 ] RIP: 0010:kfree+0x62/0x140<br /> [ 406.836197 ] Code: 80 48 01 d8 0f 82 e9 00 00 00 48 c7 c2 00 00 00 80 48 2b 15 78 9f 1f 01 48 01 d0 48 c1 e8 0c 48 c1 e0 06 48 03 05 56 9f 1f 01 8b 50 08 48 89 c7 f6 c2 01 0f 85 b0 00 00 00 66 90 48 8b 07 f6<br /> [ 406.837810 ] RSP: 0018:ffffb9d641607e48 EFLAGS: 00010286<br /> [ 406.838213 ] RAX: ffffe7b487148000 RBX: ffffb9d645200000 RCX: ffffb9d641607dc4<br /> [ 406.838738 ] RDX: 000065bb00000000 RSI: ffffffffc0d88b84 RDI: ffffb9d645200000<br /> [ 406.839217 ] RBP: ffff9a4625d00068 R08: 0000000000000001 R09: 0000000000000001<br /> [ 406.839650 ] R10: 0000000000000001 R11: 000000000000001f R12: ffff9a4625d4da80<br /> [ 406.840055 ] R13: ffff9a4625d00000 R14: ffffffffc0e2eb20 R15: 0000000000000000<br /> [ 406.840451 ] FS: 00007f0a264ffb80(0000) GS:ffff9a4e2d500000(0000) knlGS:0000000000000000<br /> [ 406.840851 ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 406.841125 ] CR2: ffffe7b487148008 CR3: 000000018c4d2000 CR4: 00000000000006f0<br /> [ 406.841464 ] Call Trace:<br /> [ 406.841583 ] <br /> [ 406.841682 ] ? __die+0x1f/0x70<br /> [ 406.841828 ] ? page_fault_oops+0x159/0x470<br /> [ 406.842014 ] ? fixup_exception+0x22/0x310<br /> [ 406.842198 ] ? exc_page_fault+0x1ed/0x200<br /> [ 406.842382 ] ? asm_exc_page_fault+0x22/0x30<br /> [ 406.842574 ] ? bch2_fs_release+0x54/0x280 [bcachefs]<br /> [ 406.842842 ] ? kfree+0x62/0x140<br /> [ 406.842988 ] ? kfree+0x104/0x140<br /> [ 406.843138 ] bch2_fs_release+0x54/0x280 [bcachefs]<br /> [ 406.843390 ] kobject_put+0xb7/0x170<br /> [ 406.843552 ] deactivate_locked_super+0x2f/0xa0<br /> [ 406.843756 ] cleanup_mnt+0xba/0x150<br /> [ 406.843917 ] task_work_run+0x59/0xa0<br /> [ 406.844083 ] exit_to_user_mode_prepare+0x197/0x1a0<br /> [ 406.844302 ] syscall_exit_to_user_mode+0x16/0x40<br /> [ 406.844510 ] do_syscall_64+0x4e/0xf0<br /> [ 406.844675 ] entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> [ 406.844907 ] RIP: 0033:0x7f0a2664e4fb

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: fsl-qdma: Fix a memory leak related to the queue command DMA<br /> <br /> This dma_alloc_coherent() is undone neither in the remove function, nor in<br /> the error handling path of fsl_qdma_probe().<br /> <br /> Switch to the managed version to fix both issues.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: tc358743: register v4l2 async device only after successful setup<br /> <br /> Ensure the device has been setup correctly before registering the v4l2<br /> async device, thus allowing userspace to access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: lis3lv02d_i2c: Fix regulators getting en-/dis-abled twice on suspend/resume<br /> <br /> When not configured for wakeup lis3lv02d_i2c_suspend() will call<br /> lis3lv02d_poweroff() even if the device has already been turned off<br /> by the runtime-suspend handler and if configured for wakeup and<br /> the device is runtime-suspended at this point then it is not turned<br /> back on to serve as a wakeup source.<br /> <br /> Before commit b1b9f7a49440 ("misc: lis3lv02d_i2c: Add missing setting<br /> of the reg_ctrl callback"), lis3lv02d_poweroff() failed to disable<br /> the regulators which as a side effect made calling poweroff() twice ok.<br /> <br /> Now that poweroff() correctly disables the regulators, doing this twice<br /> triggers a WARN() in the regulator core:<br /> <br /> unbalanced disables for regulator-dummy<br /> WARNING: CPU: 1 PID: 92 at drivers/regulator/core.c:2999 _regulator_disable<br /> ...<br /> <br /> Fix lis3lv02d_i2c_suspend() to not call poweroff() a second time if<br /> already runtime-suspended and add a poweron() call when necessary to<br /> make wakeup work.<br /> <br /> lis3lv02d_i2c_resume() has similar issues, with an added weirness that<br /> it always powers on the device if it is runtime suspended, after which<br /> the first runtime-resume will call poweron() again, causing the enabled<br /> count for the regulator to increase by 1 every suspend/resume. These<br /> unbalanced regulator_enable() calls cause the regulator to never<br /> be turned off and trigger the following WARN() on driver unbind:<br /> <br /> WARNING: CPU: 1 PID: 1724 at drivers/regulator/core.c:2396 _regulator_put<br /> <br /> Fix this by making lis3lv02d_i2c_resume() mirror the new suspend().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: Fix page refcounts for unaligned buffers in __bio_release_pages()<br /> <br /> Fix an incorrect number of pages being released for buffers that do not<br /> start at the beginning of a page.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/net: fix overflow check in io_recvmsg_mshot_prep()<br /> <br /> The "controllen" variable is type size_t (unsigned long). Casting it<br /> to int could lead to an integer underflow.<br /> <br /> The check_add_overflow() function considers the type of the destination<br /> which is type int. If we add two positive values and the result cannot<br /> fit in an integer then that&amp;#39;s counted as an overflow.<br /> <br /> However, if we cast "controllen" to an int and it turns negative, then<br /> negative values *can* fit into an int type so there is no overflow.<br /> <br /> Good: 100 + (unsigned long)-4 = 96