Vulnerabilities

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer()<br /> <br /> In the for statement of lbs_allocate_cmd_buffer(), if the allocation of<br /> cmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to<br /> be freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: ncm: Fix handling of zero block length packets<br /> <br /> While connecting to a Linux host with CDC_NCM_NTB_DEF_SIZE_TX<br /> set to 65536, it has been observed that we receive short packets,<br /> which come at interval of 5-10 seconds sometimes and have block<br /> length zero but still contain 1-2 valid datagrams present.<br /> <br /> According to the NCM spec:<br /> <br /> "If wBlockLength = 0x0000, the block is terminated by a<br /> short packet. In this case, the USB transfer must still<br /> be shorter than dwNtbInMaxSize or dwNtbOutMaxSize. If<br /> exactly dwNtbInMaxSize or dwNtbOutMaxSize bytes are sent,<br /> and the size is a multiple of wMaxPacketSize for the<br /> given pipe, then no ZLP shall be sent.<br /> <br /> wBlockLength= 0x0000 must be used with extreme care, because<br /> of the possibility that the host and device may get out of<br /> sync, and because of test issues.<br /> <br /> wBlockLength = 0x0000 allows the sender to reduce latency by<br /> starting to send a very large NTB, and then shortening it when<br /> the sender discovers that there’s not sufficient data to justify<br /> sending a large NTB"<br /> <br /> However, there is a potential issue with the current implementation,<br /> as it checks for the occurrence of multiple NTBs in a single<br /> giveback by verifying if the leftover bytes to be processed is zero<br /> or not. If the block length reads zero, we would process the same<br /> NTB infintely because the leftover bytes is never zero and it leads<br /> to a crash. Fix this by bailing out if block length reads zero.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vt: fix unicode buffer corruption when deleting characters<br /> <br /> This is the same issue that was fixed for the VGA text buffer in commit<br /> 39cdb68c64d8 ("vt: fix memory overlapping when deleting chars in the<br /> buffer"). The cure is also the same i.e. replace memcpy() with memmove()<br /> due to the overlaping buffers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubifs: Set page uptodate in the correct place<br /> <br /> Page cache reads are lockless, so setting the freshly allocated page<br /> uptodate before we&amp;#39;ve overwritten it with the data it&amp;#39;s supposed to have<br /> in it will allow a simultaneous reader to see old data. Move the call<br /> to SetPageUptodate into ubifs_write_end(), which is after we copied the<br /> new data into the page.