Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: core: Fix scsi_mode_sense() buffer length handling<br /> <br /> Several problems exist with scsi_mode_sense() buffer length handling:<br /> <br /> 1) The allocation length field of the MODE SENSE(10) command is 16-bits,<br /> occupying bytes 7 and 8 of the CDB. With this command, access to mode<br /> pages larger than 255 bytes is thus possible. However, the CDB<br /> allocation length field is set by assigning len to byte 8 only, thus<br /> truncating buffer length larger than 255.<br /> <br /> 2) If scsi_mode_sense() is called with len smaller than 8 with<br /> sdev-&gt;use_10_for_ms set, or smaller than 4 otherwise, the buffer length<br /> is increased to 8 and 4 respectively, and the buffer is zero filled<br /> with these increased values, thus corrupting the memory following the<br /> buffer.<br /> <br /> Fix these 2 problems by using put_unaligned_be16() to set the allocation<br /> length field of MODE SENSE(10) CDB and by returning an error when len is<br /> too small.<br /> <br /> Furthermore, if len is larger than 255B, always try MODE SENSE(10) first,<br /> even if the device driver did not set sdev-&gt;use_10_for_ms. In case of<br /> invalid opcode error for MODE SENSE(10), access to mode pages larger than<br /> 255 bytes are not retried using MODE SENSE(6). To avoid buffer length<br /> overflows for the MODE_SENSE(10) case, check that len is smaller than 65535<br /> bytes.<br /> <br /> While at it, also fix the folowing:<br /> <br /> * Use get_unaligned_be16() to retrieve the mode data length and block<br /> descriptor length fields of the mode sense reply header instead of using<br /> an open coded calculation.<br /> <br /> * Fix the kdoc dbd argument explanation: the DBD bit stands for Disable<br /> Block Descriptor, which is the opposite of what the dbd argument<br /> description was.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i40e: Fix NULL ptr dereference on VSI filter sync<br /> <br /> Remove the reason of null pointer dereference in sync VSI filters.<br /> Added new I40E_VSI_RELEASING flag to signalize deleting and releasing<br /> of VSI resources to sync this thread with sync filters subtask.<br /> Without this patch it is possible to start update the VSI filter list<br /> after VSI is removed, that&amp;#39;s causing a kernel oops.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: tty_buffer: Fix the softlockup issue in flush_to_ldisc<br /> <br /> When running ltp testcase(ltp/testcases/kernel/pty/pty04.c) with arm64, there is a soft lockup,<br /> which look like this one:<br /> <br /> Workqueue: events_unbound flush_to_ldisc<br /> Call trace:<br /> dump_backtrace+0x0/0x1ec<br /> show_stack+0x24/0x30<br /> dump_stack+0xd0/0x128<br /> panic+0x15c/0x374<br /> watchdog_timer_fn+0x2b8/0x304<br /> __run_hrtimer+0x88/0x2c0<br /> __hrtimer_run_queues+0xa4/0x120<br /> hrtimer_interrupt+0xfc/0x270<br /> arch_timer_handler_phys+0x40/0x50<br /> handle_percpu_devid_irq+0x94/0x220<br /> __handle_domain_irq+0x88/0xf0<br /> gic_handle_irq+0x84/0xfc<br /> el1_irq+0xc8/0x180<br /> slip_unesc+0x80/0x214 [slip]<br /> tty_ldisc_receive_buf+0x64/0x80<br /> tty_port_default_receive_buf+0x50/0x90<br /> flush_to_ldisc+0xbc/0x110<br /> process_one_work+0x1d4/0x4b0<br /> worker_thread+0x180/0x430<br /> kthread+0x11c/0x120<br /> <br /> In the testcase pty04, The first process call the write syscall to send<br /> data to the pty master. At the same time, the workqueue will do the<br /> flush_to_ldisc to pop data in a loop until there is no more data left.<br /> When the sender and workqueue running in different core, the sender sends<br /> data fastly in full time which will result in workqueue doing work in loop<br /> for a long time and occuring softlockup in flush_to_ldisc with kernel<br /> configured without preempt. So I add need_resched check and cond_resched<br /> in the flush_to_ldisc loop to avoid it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: check for null after calling kmemdup<br /> <br /> kmemdup can return a null pointer so need to check for it, otherwise<br /> the null key will be dereferenced later in tipc_crypto_key_xmit as<br /> can be seen in the trace [1].<br /> <br /> <br /> [1] https://syzkaller.appspot.com/bug?id=bca180abb29567b189efdbdb34cbf7ba851c2a58

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: dts: qcom: msm8998: Fix CPU/L2 idle state latency and residency<br /> <br /> The entry/exit latency and minimum residency in state for the idle<br /> states of MSM8998 were ..bad: first of all, for all of them the<br /> timings were written for CPU sleep but the min-residency-us param<br /> was miscalculated (supposedly, while porting this from downstream);<br /> Then, the power collapse states are setting PC on both the CPU<br /> cluster *and* the L2 cache, which have different timings: in the<br /> specific case of L2 the times are higher so these ones should be<br /> taken into account instead of the CPU ones.<br /> <br /> This parameter misconfiguration was not giving particular issues<br /> because on MSM8998 there was no CPU scaling at all, so cluster/L2<br /> power collapse was rarely (if ever) hit.<br /> When CPU scaling is enabled, though, the wrong timings will produce<br /> SoC unstability shown to the user as random, apparently error-less,<br /> sudden reboots and/or lockups.<br /> <br /> This set of parameters are stabilizing the SoC when CPU scaling is<br /> ON and when power collapse is frequently hit.