Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: tipd: Remove WARN_ON in tps6598x_block_read<br /> <br /> Calling tps6598x_block_read with a higher than allowed len can be<br /> handled by just returning an error. There&amp;#39;s no need to crash systems<br /> with panic-on-warn enabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: fix null pointer dereference on pointer cs_desc<br /> <br /> The pointer cs_desc return from snd_usb_find_clock_source could<br /> be null, so there is a potential null pointer dereference issue.<br /> Fix this by adding a null check before dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Update error handler for UCTX and UMEM<br /> <br /> In the fast unload flow, the device state is set to internal error,<br /> which indicates that the driver started the destroy process.<br /> In this case, when a destroy command is being executed, it should return<br /> MLX5_CMD_STAT_OK.<br /> Fix MLX5_CMD_OP_DESTROY_UCTX and MLX5_CMD_OP_DESTROY_UMEM to return OK<br /> instead of EIO.<br /> <br /> This fixes a call trace in the umem release process -<br /> [ 2633.536695] Call Trace:<br /> [ 2633.537518] ib_uverbs_remove_one+0xc3/0x140 [ib_uverbs]<br /> [ 2633.538596] remove_client_context+0x8b/0xd0 [ib_core]<br /> [ 2633.539641] disable_device+0x8c/0x130 [ib_core]<br /> [ 2633.540615] __ib_unregister_device+0x35/0xa0 [ib_core]<br /> [ 2633.541640] ib_unregister_device+0x21/0x30 [ib_core]<br /> [ 2633.542663] __mlx5_ib_remove+0x38/0x90 [mlx5_ib]<br /> [ 2633.543640] auxiliary_bus_remove+0x1e/0x30 [auxiliary]<br /> [ 2633.544661] device_release_driver_internal+0x103/0x1f0<br /> [ 2633.545679] bus_remove_device+0xf7/0x170<br /> [ 2633.546640] device_del+0x181/0x410<br /> [ 2633.547606] mlx5_rescan_drivers_locked.part.10+0x63/0x160 [mlx5_core]<br /> [ 2633.548777] mlx5_unregister_device+0x27/0x40 [mlx5_core]<br /> [ 2633.549841] mlx5_uninit_one+0x21/0xc0 [mlx5_core]<br /> [ 2633.550864] remove_one+0x69/0xe0 [mlx5_core]<br /> [ 2633.551819] pci_device_remove+0x3b/0xc0<br /> [ 2633.552731] device_release_driver_internal+0x103/0x1f0<br /> [ 2633.553746] unbind_store+0xf6/0x130<br /> [ 2633.554657] kernfs_fop_write+0x116/0x190<br /> [ 2633.555567] vfs_write+0xa5/0x1a0<br /> [ 2633.556407] ksys_write+0x4f/0xb0<br /> [ 2633.557233] do_syscall_64+0x5b/0x1a0<br /> [ 2633.558071] entry_SYSCALL_64_after_hwframe+0x65/0xca<br /> [ 2633.559018] RIP: 0033:0x7f9977132648<br /> [ 2633.559821] Code: 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 55 6f 2d 00 8b 00 85 c0 75 17 b8 01 00 00 00 0f 05 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 49 89 d4 55<br /> [ 2633.562332] RSP: 002b:00007fffb1a83888 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> [ 2633.563472] RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007f9977132648<br /> [ 2633.564541] RDX: 000000000000000c RSI: 000055b90546e230 RDI: 0000000000000001<br /> [ 2633.565596] RBP: 000055b90546e230 R08: 00007f9977406860 R09: 00007f9977a54740<br /> [ 2633.566653] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f99774056e0<br /> [ 2633.567692] R13: 000000000000000c R14: 00007f9977400880 R15: 000000000000000c<br /> [ 2633.568725] ---[ end trace 10b4fe52945e544d ]---

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 /> hugetlb, userfaultfd: fix reservation restore on userfaultfd error<br /> <br /> Currently in the is_continue case in hugetlb_mcopy_atomic_pte(), if we<br /> bail out using "goto out_release_unlock;" in the cases where idx &gt;=<br /> size, or !huge_pte_none(), the code will detect that new_pagecache_page<br /> == false, and so call restore_reserve_on_error(). In this case I see<br /> restore_reserve_on_error() delete the reservation, and the following<br /> call to remove_inode_hugepages() will increment h-&gt;resv_hugepages<br /> causing a 100% reproducible leak.<br /> <br /> We should treat the is_continue case similar to adding a page into the<br /> pagecache and set new_pagecache_page to true, to indicate that there is<br /> no reservation to restore on the error path, and we need not call<br /> restore_reserve_on_error(). Rename new_pagecache_page to<br /> page_in_pagecache to make that clear.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: kTLS, Fix crash in RX resync flow<br /> <br /> For the TLS RX resync flow, we maintain a list of TLS contexts<br /> that require some attention, to communicate their resync information<br /> to the HW.<br /> Here we fix list corruptions, by protecting the entries against<br /> movements coming from resync_handle_seq_match(), until their resync<br /> handling in napi is fully completed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: advansys: Fix kernel pointer leak<br /> <br /> Pointers should be printed with %p or %px rather than cast to &amp;#39;unsigned<br /> long&amp;#39; and printed with %lx.<br /> <br /> Change %lx to %p to print the hashed pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/hyperv: Fix NULL deref in set_hv_tscchange_cb() if Hyper-V setup fails<br /> <br /> Check for a valid hv_vp_index array prior to derefencing hv_vp_index when<br /> setting Hyper-V&amp;#39;s TSC change callback. If Hyper-V setup failed in<br /> hyperv_init(), the kernel will still report that it&amp;#39;s running under<br /> Hyper-V, but will have silently disabled nearly all functionality.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000010<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] SMP<br /> CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.15.0-rc2+ #75<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> RIP: 0010:set_hv_tscchange_cb+0x15/0xa0<br /> Code: 04 82 8b 15 12 17 85 01 48 c1 e0 20 48 0d ee 00 01 00 f6 c6 08<br /> ...<br /> Call Trace:<br /> kvm_arch_init+0x17c/0x280<br /> kvm_init+0x31/0x330<br /> vmx_init+0xba/0x13a<br /> do_one_initcall+0x41/0x1c0<br /> kernel_init_freeable+0x1f2/0x23b<br /> kernel_init+0x16/0x120<br /> ret_from_fork+0x22/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> selinux: fix NULL-pointer dereference when hashtab allocation fails<br /> <br /> When the hash table slot array allocation fails in hashtab_init(),<br /> h-&gt;size is left initialized with a non-zero value, but the h-&gt;htable<br /> pointer is NULL. This may then cause a NULL pointer dereference, since<br /> the policydb code relies on the assumption that even after a failed<br /> hashtab_init(), hashtab_map() and hashtab_destroy() can be safely called<br /> on it. Yet, these detect an empty hashtab only by looking at the size.<br /> <br /> Fix this by making sure that hashtab_init() always leaves behind a valid<br /> empty hashtab when the allocation fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: scsi_debug: Fix out-of-bound read in resp_report_tgtpgs()<br /> <br /> The following issue was observed running syzkaller:<br /> <br /> BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:377 [inline]<br /> BUG: KASAN: slab-out-of-bounds in sg_copy_buffer+0x150/0x1c0 lib/scatterlist.c:831<br /> Read of size 2132 at addr ffff8880aea95dc8 by task syz-executor.0/9815<br /> <br /> CPU: 0 PID: 9815 Comm: syz-executor.0 Not tainted 4.19.202-00874-gfc0fe04215a9 #2<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014<br /> Call Trace:<br /> __dump_stack lib/dump_stack.c:77 [inline]<br /> dump_stack+0xe4/0x14a lib/dump_stack.c:118<br /> print_address_description+0x73/0x280 mm/kasan/report.c:253<br /> kasan_report_error mm/kasan/report.c:352 [inline]<br /> kasan_report+0x272/0x370 mm/kasan/report.c:410<br /> memcpy+0x1f/0x50 mm/kasan/kasan.c:302<br /> memcpy include/linux/string.h:377 [inline]<br /> sg_copy_buffer+0x150/0x1c0 lib/scatterlist.c:831<br /> fill_from_dev_buffer+0x14f/0x340 drivers/scsi/scsi_debug.c:1021<br /> resp_report_tgtpgs+0x5aa/0x770 drivers/scsi/scsi_debug.c:1772<br /> schedule_resp+0x464/0x12f0 drivers/scsi/scsi_debug.c:4429<br /> scsi_debug_queuecommand+0x467/0x1390 drivers/scsi/scsi_debug.c:5835<br /> scsi_dispatch_cmd+0x3fc/0x9b0 drivers/scsi/scsi_lib.c:1896<br /> scsi_request_fn+0x1042/0x1810 drivers/scsi/scsi_lib.c:2034<br /> __blk_run_queue_uncond block/blk-core.c:464 [inline]<br /> __blk_run_queue+0x1a4/0x380 block/blk-core.c:484<br /> blk_execute_rq_nowait+0x1c2/0x2d0 block/blk-exec.c:78<br /> sg_common_write.isra.19+0xd74/0x1dc0 drivers/scsi/sg.c:847<br /> sg_write.part.23+0x6e0/0xd00 drivers/scsi/sg.c:716<br /> sg_write+0x64/0xa0 drivers/scsi/sg.c:622<br /> __vfs_write+0xed/0x690 fs/read_write.c:485<br /> kill_bdev:block_device:00000000e138492c<br /> vfs_write+0x184/0x4c0 fs/read_write.c:549<br /> ksys_write+0x107/0x240 fs/read_write.c:599<br /> do_syscall_64+0xc2/0x560 arch/x86/entry/common.c:293<br /> entry_SYSCALL_64_after_hwframe+0x49/0xbe<br /> <br /> We get &amp;#39;alen&amp;#39; from command its type is int. If userspace passes a large<br /> length we will get a negative &amp;#39;alen&amp;#39;.<br /> <br /> Switch n, alen, and rlen to u32.

JFreeChart v1.5.4 was discovered to be vulnerable to ArrayIndexOutOfBounds via the &amp;#39;setSeriesNeedle(int index, int type)&amp;#39; method. NOTE: this is disputed by multiple third parties who believe there was not reasonable evidence to determine the existence of a vulnerability. The submission may have been based on a tool that is not sufficiently robust for vulnerability identification.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: musb: tusb6010: check return value after calling platform_get_resource()<br /> <br /> It will cause null-ptr-deref if platform_get_resource() returns NULL,<br /> we need check the return value.