Vulnerabilities

JFreeChart v1.5.4 was discovered to be vulnerable to ArrayIndexOutOfBounds via the 'setSeriesNeedle(int index, int type)' 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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: core: Improve SCSI abort handling<br /> <br /> The following has been observed on a test setup:<br /> <br /> WARNING: CPU: 4 PID: 250 at drivers/scsi/ufs/ufshcd.c:2737 ufshcd_queuecommand+0x468/0x65c<br /> Call trace:<br /> ufshcd_queuecommand+0x468/0x65c<br /> scsi_send_eh_cmnd+0x224/0x6a0<br /> scsi_eh_test_devices+0x248/0x418<br /> scsi_eh_ready_devs+0xc34/0xe58<br /> scsi_error_handler+0x204/0x80c<br /> kthread+0x150/0x1b4<br /> ret_from_fork+0x10/0x30<br /> <br /> That warning is triggered by the following statement:<br /> <br /> WARN_ON(lrbp-&gt;cmd);<br /> <br /> Fix this warning by clearing lrbp-&gt;cmd from the abort handler.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix memory ordering between normal and ordered work functions<br /> <br /> Ordered work functions aren&amp;#39;t guaranteed to be handled by the same thread<br /> which executed the normal work functions. The only way execution between<br /> normal/ordered functions is synchronized is via the WORK_DONE_BIT,<br /> unfortunately the used bitops don&amp;#39;t guarantee any ordering whatsoever.<br /> <br /> This manifested as seemingly inexplicable crashes on ARM64, where<br /> async_chunk::inode is seen as non-null in async_cow_submit which causes<br /> submit_compressed_extents to be called and crash occurs because<br /> async_chunk::inode suddenly became NULL. The call trace was similar to:<br /> <br /> pc : submit_compressed_extents+0x38/0x3d0<br /> lr : async_cow_submit+0x50/0xd0<br /> sp : ffff800015d4bc20<br /> <br /> <br /> <br /> Call trace:<br /> submit_compressed_extents+0x38/0x3d0<br /> async_cow_submit+0x50/0xd0<br /> run_ordered_work+0xc8/0x280<br /> btrfs_work_helper+0x98/0x250<br /> process_one_work+0x1f0/0x4ac<br /> worker_thread+0x188/0x504<br /> kthread+0x110/0x114<br /> ret_from_fork+0x10/0x18<br /> <br /> Fix this by adding respective barrier calls which ensure that all<br /> accesses preceding setting of WORK_DONE_BIT are strictly ordered before<br /> setting the flag. At the same time add a read barrier after reading of<br /> WORK_DONE_BIT in run_ordered_work which ensures all subsequent loads<br /> would be strictly ordered after reading the bit. This in turn ensures<br /> are all accesses before WORK_DONE_BIT are going to be strictly ordered<br /> before any access that can occur in ordered_func.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf bpf: Avoid memory leak from perf_env__insert_btf()<br /> <br /> perf_env__insert_btf() doesn&amp;#39;t insert if a duplicate BTF id is<br /> encountered and this causes a memory leak. Modify the function to return<br /> a success/error value and then free the memory if insertion didn&amp;#39;t<br /> happen.<br /> <br /> v2. Adds a return -1 when the insertion error occurs in<br /> perf_env__fetch_btf. This doesn&amp;#39;t affect anything as the result is<br /> never checked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: scsi_debug: Fix out-of-bound read in resp_readcap16()<br /> <br /> The following warning was observed running syzkaller:<br /> <br /> [ 3813.830724] sg_write: data in/out 65466/242 bytes for SCSI command 0x9e-- guessing data in;<br /> [ 3813.830724] program syz-executor not setting count and/or reply_len properly<br /> [ 3813.836956] ==================================================================<br /> [ 3813.839465] BUG: KASAN: stack-out-of-bounds in sg_copy_buffer+0x157/0x1e0<br /> [ 3813.841773] Read of size 4096 at addr ffff8883cf80f540 by task syz-executor/1549<br /> [ 3813.846612] Call Trace:<br /> [ 3813.846995] dump_stack+0x108/0x15f<br /> [ 3813.847524] print_address_description+0xa5/0x372<br /> [ 3813.848243] kasan_report.cold+0x236/0x2a8<br /> [ 3813.849439] check_memory_region+0x240/0x270<br /> [ 3813.850094] memcpy+0x30/0x80<br /> [ 3813.850553] sg_copy_buffer+0x157/0x1e0<br /> [ 3813.853032] sg_copy_from_buffer+0x13/0x20<br /> [ 3813.853660] fill_from_dev_buffer+0x135/0x370<br /> [ 3813.854329] resp_readcap16+0x1ac/0x280<br /> [ 3813.856917] schedule_resp+0x41f/0x1630<br /> [ 3813.858203] scsi_debug_queuecommand+0xb32/0x17e0<br /> [ 3813.862699] scsi_dispatch_cmd+0x330/0x950<br /> [ 3813.863329] scsi_request_fn+0xd8e/0x1710<br /> [ 3813.863946] __blk_run_queue+0x10b/0x230<br /> [ 3813.864544] blk_execute_rq_nowait+0x1d8/0x400<br /> [ 3813.865220] sg_common_write.isra.0+0xe61/0x2420<br /> [ 3813.871637] sg_write+0x6c8/0xef0<br /> [ 3813.878853] __vfs_write+0xe4/0x800<br /> [ 3813.883487] vfs_write+0x17b/0x530<br /> [ 3813.884008] ksys_write+0x103/0x270<br /> [ 3813.886268] __x64_sys_write+0x77/0xc0<br /> [ 3813.886841] do_syscall_64+0x106/0x360<br /> [ 3813.887415] entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> <br /> This issue can be reproduced with the following syzkaller log:<br /> <br /> r0 = openat(0xffffffffffffff9c, &amp;(0x7f0000000040)=&amp;#39;./file0\x00&amp;#39;, 0x26e1, 0x0)<br /> r1 = syz_open_procfs(0xffffffffffffffff, &amp;(0x7f0000000000)=&amp;#39;fd/3\x00&amp;#39;)<br /> open_by_handle_at(r1, &amp;(0x7f00000003c0)=ANY=[@ANYRESHEX], 0x602000)<br /> r2 = syz_open_dev$sg(&amp;(0x7f0000000000), 0x0, 0x40782)<br /> write$binfmt_aout(r2, &amp;(0x7f0000000340)=ANY=[@ANYBLOB="00000000deff000000000000000000000000000000000000000000000000000047f007af9e107a41ec395f1bded7be24277a1501ff6196a83366f4e6362bc0ff2b247f68a972989b094b2da4fb3607fcf611a22dd04310d28c75039d"], 0x126)<br /> <br /> In resp_readcap16() we get "int alloc_len" value -1104926854, and then pass<br /> the huge arr_len to fill_from_dev_buffer(), but arr is only 32 bytes. This<br /> leads to OOB in sg_copy_buffer().<br /> <br /> To solve this issue, define alloc_len as u32.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: core: sysfs: Fix hang when device state is set via sysfs<br /> <br /> This fixes a regression added with:<br /> <br /> commit f0f82e2476f6 ("scsi: core: Fix capacity set to zero after<br /> offlinining device")<br /> <br /> The problem is that after iSCSI recovery, iscsid will call into the kernel<br /> to set the dev&amp;#39;s state to running, and with that patch we now call<br /> scsi_rescan_device() with the state_mutex held. If the SCSI error handler<br /> thread is just starting to test the device in scsi_send_eh_cmnd() then it&amp;#39;s<br /> going to try to grab the state_mutex.<br /> <br /> We are then stuck, because when scsi_rescan_device() tries to send its I/O<br /> scsi_queue_rq() calls -&gt; scsi_host_queue_ready() -&gt; scsi_host_in_recovery()<br /> which will return true (the host state is still in recovery) and I/O will<br /> just be requeued. scsi_send_eh_cmnd() will then never be able to grab the<br /> state_mutex to finish error handling.<br /> <br /> To prevent the deadlock move the rescan-related code to after we drop the<br /> state_mutex.<br /> <br /> This also adds a check for if we are already in the running state. This<br /> prevents extra scans and helps the iscsid case where if the transport class<br /> has already onlined the device during its recovery process then we don&amp;#39;t<br /> need userspace to do it again plus possibly block that daemon.