Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: tegra: tegra124-emc: Fix potential memory leak<br /> <br /> The tegra and tegra needs to be freed in the error handling path, otherwise<br /> it will be leaked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udf: Do not bother merging very long extents<br /> <br /> When merging very long extents we try to push as much length as possible<br /> to the first extent. However this is unnecessarily complicated and not<br /> really worth the trouble. Furthermore there was a bug in the logic<br /> resulting in corrupting extents in the file as syzbot reproducer shows.<br /> So just don&amp;#39;t bother with the merging of extents that are too long<br /> together.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Unregister devlink params in case interface is down<br /> <br /> Currently, in case an interface is down, mlx5 driver doesn&amp;#39;t<br /> unregister its devlink params, which leads to this WARN[1].<br /> Fix it by unregistering devlink params in that case as well.<br /> <br /> [1]<br /> [ 295.244769 ] WARNING: CPU: 15 PID: 1 at net/core/devlink.c:9042 devlink_free+0x174/0x1fc<br /> [ 295.488379 ] CPU: 15 PID: 1 Comm: shutdown Tainted: G S OE 5.15.0-1017.19.3.g0677e61-bluefield #g0677e61<br /> [ 295.509330 ] Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS 4.2.0.12761 Jun 6 2023<br /> [ 295.543096 ] pc : devlink_free+0x174/0x1fc<br /> [ 295.551104 ] lr : mlx5_devlink_free+0x18/0x2c [mlx5_core]<br /> [ 295.561816 ] sp : ffff80000809b850<br /> [ 295.711155 ] Call trace:<br /> [ 295.716030 ] devlink_free+0x174/0x1fc<br /> [ 295.723346 ] mlx5_devlink_free+0x18/0x2c [mlx5_core]<br /> [ 295.733351 ] mlx5_sf_dev_remove+0x98/0xb0 [mlx5_core]<br /> [ 295.743534 ] auxiliary_bus_remove+0x2c/0x50<br /> [ 295.751893 ] __device_release_driver+0x19c/0x280<br /> [ 295.761120 ] device_release_driver+0x34/0x50<br /> [ 295.769649 ] bus_remove_device+0xdc/0x170<br /> [ 295.777656 ] device_del+0x17c/0x3a4<br /> [ 295.784620 ] mlx5_sf_dev_remove+0x28/0xf0 [mlx5_core]<br /> [ 295.794800 ] mlx5_sf_dev_table_destroy+0x98/0x110 [mlx5_core]<br /> [ 295.806375 ] mlx5_unload+0x34/0xd0 [mlx5_core]<br /> [ 295.815339 ] mlx5_unload_one+0x70/0xe4 [mlx5_core]<br /> [ 295.824998 ] shutdown+0xb0/0xd8 [mlx5_core]<br /> [ 295.833439 ] pci_device_shutdown+0x3c/0xa0<br /> [ 295.841651 ] device_shutdown+0x170/0x340<br /> [ 295.849486 ] __do_sys_reboot+0x1f4/0x2a0<br /> [ 295.857322 ] __arm64_sys_reboot+0x2c/0x40<br /> [ 295.865329 ] invoke_syscall+0x78/0x100<br /> [ 295.872817 ] el0_svc_common.constprop.0+0x54/0x184<br /> [ 295.882392 ] do_el0_svc+0x30/0xac<br /> [ 295.889008 ] el0_svc+0x48/0x160<br /> [ 295.895278 ] el0t_64_sync_handler+0xa4/0x130<br /> [ 295.903807 ] el0t_64_sync+0x1a4/0x1a8<br /> [ 295.911120 ] ---[ end trace 4f1d2381d00d9dce ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ublk: fail to start device if queue setup is interrupted<br /> <br /> In ublk_ctrl_start_dev(), if wait_for_completion_interruptible() is<br /> interrupted by signal, queues aren&amp;#39;t setup successfully yet, so we<br /> have to fail UBLK_CMD_START_DEV, otherwise kernel oops can be triggered.<br /> <br /> Reported by German when working on qemu-storage-deamon which requires<br /> single thread ublk daemon.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> qed: allow sleep in qed_mcp_trace_dump()<br /> <br /> By default, qed_mcp_cmd_and_union() delays 10us at a time in a loop<br /> that can run 500K times, so calls to qed_mcp_nvm_rd_cmd()<br /> may block the current thread for over 5s.<br /> We observed thread scheduling delays over 700ms in production,<br /> with stacktraces pointing to this code as the culprit.<br /> <br /> qed_mcp_trace_dump() is called from ethtool, so sleeping is permitted.<br /> It already can sleep in qed_mcp_halt(), which calls qed_mcp_cmd().<br /> Add a "can sleep" parameter to qed_find_nvram_image() and<br /> qed_nvram_read() so they can sleep during qed_mcp_trace_dump().<br /> qed_mcp_trace_get_meta_info() and qed_mcp_trace_read_meta(),<br /> called only by qed_mcp_trace_dump(), allow these functions to sleep.<br /> I can&amp;#39;t tell if the other caller (qed_grc_dump_mcp_hw_dump()) can sleep,<br /> so keep b_can_sleep set to false when it calls these functions.<br /> <br /> An example stacktrace from a custom warning we added to the kernel<br /> showing a thread that has not scheduled despite long needing resched:<br /> [ 2745.362925,17] ------------[ cut here ]------------<br /> [ 2745.362941,17] WARNING: CPU: 23 PID: 5640 at arch/x86/kernel/irq.c:233 do_IRQ+0x15e/0x1a0()<br /> [ 2745.362946,17] Thread not rescheduled for 744 ms after irq 99<br /> [ 2745.362956,17] Modules linked in: ...<br /> [ 2745.363339,17] CPU: 23 PID: 5640 Comm: lldpd Tainted: P O 4.4.182+ #202104120910+6d1da174272d.61x<br /> [ 2745.363343,17] Hardware name: FOXCONN MercuryB/Quicksilver Controller, BIOS H11P1N09 07/08/2020<br /> [ 2745.363346,17] 0000000000000000 ffff885ec07c3ed8 ffffffff8131eb2f ffff885ec07c3f20<br /> [ 2745.363358,17] ffffffff81d14f64 ffff885ec07c3f10 ffffffff81072ac2 ffff88be98ed0000<br /> [ 2745.363369,17] 0000000000000063 0000000000000174 0000000000000074 0000000000000000<br /> [ 2745.363379,17] Call Trace:<br /> [ 2745.363382,17] [] dump_stack+0x8e/0xcf<br /> [ 2745.363393,17] [] warn_slowpath_common+0x82/0xc0<br /> [ 2745.363398,17] [] warn_slowpath_fmt+0x4c/0x50<br /> [ 2745.363404,17] [] ? rcu_irq_exit+0xae/0xc0<br /> [ 2745.363408,17] [] do_IRQ+0x15e/0x1a0<br /> [ 2745.363413,17] [] common_interrupt+0x89/0x89<br /> [ 2745.363416,17] [] ? delay_tsc+0x24/0x50<br /> [ 2745.363425,17] [] __udelay+0x34/0x40<br /> [ 2745.363457,17] [] qed_mcp_cmd_and_union+0x36f/0x7d0 [qed]<br /> [ 2745.363473,17] [] qed_mcp_nvm_rd_cmd+0x4d/0x90 [qed]<br /> [ 2745.363490,17] [] qed_mcp_trace_dump+0x4a7/0x630 [qed]<br /> [ 2745.363504,17] [] ? qed_fw_asserts_dump+0x1d6/0x1f0 [qed]<br /> [ 2745.363520,17] [] qed_dbg_mcp_trace_get_dump_buf_size+0x37/0x80 [qed]<br /> [ 2745.363536,17] [] qed_dbg_feature_size+0x61/0xa0 [qed]<br /> [ 2745.363551,17] [] qed_dbg_all_data_size+0x247/0x260 [qed]<br /> [ 2745.363560,17] [] qede_get_regs_len+0x30/0x40 [qede]<br /> [ 2745.363566,17] [] ethtool_get_drvinfo+0xe3/0x190<br /> [ 2745.363570,17] [] dev_ethtool+0x1362/0x2140<br /> [ 2745.363575,17] [] ? finish_task_switch+0x76/0x260<br /> [ 2745.363580,17] [] ? __schedule+0x3c6/0x9d0<br /> [ 2745.363585,17] [] ? hrtimer_start_range_ns+0x1d0/0x370<br /> [ 2745.363589,17] [] ? dev_get_by_name_rcu+0x6b/0x90<br /> [ 2745.363594,17] [] dev_ioctl+0xe8/0x710<br /> [ 2745.363599,17] [] sock_do_ioctl+0x48/0x60<br /> [ 2745.363603,17] [] sock_ioctl+0x1c7/0x280<br /> [ 2745.363608,17] [] ? seccomp_phase1+0x83/0x220<br /> [ 2745.363612,17] [] do_vfs_ioctl+0x2b3/0x4e0<br /> [ 2745.363616,17] [] SyS_ioctl+0x41/0x70<br /> [ 2745.363619,17] [] entry_SYSCALL_64_fastpath+0x1e/0x79<br /> [ 2745.363622,17] ---[ end trace f6954aa440266421 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: core: Fix handling of lrbp-&gt;cmd<br /> <br /> ufshcd_queuecommand() may be called two times in a row for a SCSI command<br /> before it is completed. Hence make the following changes:<br /> <br /> - In the functions that submit a command, do not check the old value of<br /> lrbp-&gt;cmd nor clear lrbp-&gt;cmd in error paths.<br /> <br /> - In ufshcd_release_scsi_cmd(), do not clear lrbp-&gt;cmd.<br /> <br /> See also scsi_send_eh_cmnd().<br /> <br /> This commit prevents that the following appears if a command times out:<br /> <br /> WARNING: at drivers/ufs/core/ufshcd.c:2965 ufshcd_queuecommand+0x6f8/0x9a8<br /> Call trace:<br /> ufshcd_queuecommand+0x6f8/0x9a8<br /> scsi_send_eh_cmnd+0x2c0/0x960<br /> scsi_eh_test_devices+0x100/0x314<br /> scsi_eh_ready_devs+0xd90/0x114c<br /> scsi_error_handler+0x2b4/0xb70<br /> kthread+0x16c/0x1e0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix potential null dereference<br /> <br /> The adev-&gt;dm.dc pointer can be NULL and dereferenced in amdgpu_dm_fini()<br /> without checking.<br /> <br /> Add a NULL pointer check before calling dc_dmub_srv_destroy().<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: vsp1: Replace vb2_is_streaming() with vb2_start_streaming_called()<br /> <br /> The vsp1 driver uses the vb2_is_streaming() function in its .buf_queue()<br /> handler to check if the .start_streaming() operation has been called,<br /> and decide whether to just add the buffer to an internal queue, or also<br /> trigger a hardware run. vb2_is_streaming() relies on the vb2_queue<br /> structure&amp;#39;s streaming field, which used to be set only after calling the<br /> .start_streaming() operation.<br /> <br /> Commit a10b21532574 ("media: vb2: add (un)prepare_streaming queue ops")<br /> changed this, setting the .streaming field in vb2_core_streamon() before<br /> enqueuing buffers to the driver and calling .start_streaming(). This<br /> broke the vsp1 driver which now believes that .start_streaming() has<br /> been called when it hasn&amp;#39;t, leading to a crash:<br /> <br /> [ 881.058705] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020<br /> [ 881.067495] Mem abort info:<br /> [ 881.070290] ESR = 0x0000000096000006<br /> [ 881.074042] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 881.079358] SET = 0, FnV = 0<br /> [ 881.082414] EA = 0, S1PTW = 0<br /> [ 881.085558] FSC = 0x06: level 2 translation fault<br /> [ 881.090439] Data abort info:<br /> [ 881.093320] ISV = 0, ISS = 0x00000006<br /> [ 881.097157] CM = 0, WnR = 0<br /> [ 881.100126] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004fa51000<br /> [ 881.106573] [0000000000000020] pgd=080000004f36e003, p4d=080000004f36e003, pud=080000004f7ec003, pmd=0000000000000000<br /> [ 881.117217] Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP<br /> [ 881.123494] Modules linked in: rcar_fdp1 v4l2_mem2mem<br /> [ 881.128572] CPU: 0 PID: 1271 Comm: yavta Tainted: G B 6.2.0-rc1-00023-g6c94e2e99343 #556<br /> [ 881.138061] Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT)<br /> [ 881.145981] pstate: 400000c5 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 881.152951] pc : vsp1_dl_list_add_body+0xa8/0xe0<br /> [ 881.157580] lr : vsp1_dl_list_add_body+0x34/0xe0<br /> [ 881.162206] sp : ffff80000c267710<br /> [ 881.165522] x29: ffff80000c267710 x28: ffff000010938ae8 x27: ffff000013a8dd98<br /> [ 881.172683] x26: ffff000010938098 x25: ffff000013a8dc00 x24: ffff000010ed6ba8<br /> [ 881.179841] x23: ffff00000faa4000 x22: 0000000000000000 x21: 0000000000000020<br /> [ 881.186998] x20: ffff00000faa4000 x19: 0000000000000000 x18: 0000000000000000<br /> [ 881.194154] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000<br /> [ 881.201309] x14: 0000000000000000 x13: 746e696174206c65 x12: ffff70000157043d<br /> [ 881.208465] x11: 1ffff0000157043c x10: ffff70000157043c x9 : dfff800000000000<br /> [ 881.215622] x8 : ffff80000ab821e7 x7 : 00008ffffea8fbc4 x6 : 0000000000000001<br /> [ 881.222779] x5 : ffff80000ab821e0 x4 : ffff70000157043d x3 : 0000000000000020<br /> [ 881.229936] x2 : 0000000000000020 x1 : ffff00000e4f6400 x0 : 0000000000000000<br /> [ 881.237092] Call trace:<br /> [ 881.239542] vsp1_dl_list_add_body+0xa8/0xe0<br /> [ 881.243822] vsp1_video_pipeline_run+0x270/0x2a0<br /> [ 881.248449] vsp1_video_buffer_queue+0x1c0/0x1d0<br /> [ 881.253076] __enqueue_in_driver+0xbc/0x260<br /> [ 881.257269] vb2_start_streaming+0x48/0x200<br /> [ 881.261461] vb2_core_streamon+0x13c/0x280<br /> [ 881.265565] vb2_streamon+0x3c/0x90<br /> [ 881.269064] vsp1_video_streamon+0x2fc/0x3e0<br /> [ 881.273344] v4l_streamon+0x50/0x70<br /> [ 881.276844] __video_do_ioctl+0x2bc/0x5d0<br /> [ 881.280861] video_usercopy+0x2a8/0xc80<br /> [ 881.284704] video_ioctl2+0x20/0x40<br /> [ 881.288201] v4l2_ioctl+0xa4/0xc0<br /> [ 881.291525] __arm64_sys_ioctl+0xe8/0x110<br /> [ 881.295543] invoke_syscall+0x68/0x190<br /> [ 881.299303] el0_svc_common.constprop.0+0x88/0x170<br /> [ 881.304105] do_el0_svc+0x4c/0xf0<br /> [ 881.307430] el0_svc+0x4c/0xa0<br /> [ 881.310494] el0t_64_sync_handler+0xbc/0x140<br /> [ 881.314773] el0t_64_sync+0x190/0x194<br /> [ 881.318450] Code: d50323bf d65f03c0 91008263 f9800071 (885f7c60)<br /> [ 881.324551] ---[ end trace 0000000000000000 ]---<br /> [ 881.329173] note: yavta[1271] exited with preempt_count 1<br /> <br /> A different r<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio_net: Fix error unwinding of XDP initialization<br /> <br /> When initializing XDP in virtnet_open(), some rq xdp initialization<br /> may hit an error causing net device open failed. However, previous<br /> rqs have already initialized XDP and enabled NAPI, which is not the<br /> expected behavior. Need to roll back the previous rq initialization<br /> to avoid leaks in error unwinding of init code.<br /> <br /> Also extract helper functions of disable and enable queue pairs.<br /> Use newly introduced disable helper function in error unwinding and<br /> virtnet_close. Use enable helper function in virtnet_open.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: fix slab-use-after-free in decode_session6<br /> <br /> When the xfrm device is set to the qdisc of the sfb type, the cb field<br /> of the sent skb may be modified during enqueuing. Then,<br /> slab-use-after-free may occur when the xfrm device sends IPv6 packets.<br /> <br /> The stack information is as follows:<br /> BUG: KASAN: slab-use-after-free in decode_session6+0x103f/0x1890<br /> Read of size 1 at addr ffff8881111458ef by task swapper/3/0<br /> CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.4.0-next-20230707 #409<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xd9/0x150<br /> print_address_description.constprop.0+0x2c/0x3c0<br /> kasan_report+0x11d/0x130<br /> decode_session6+0x103f/0x1890<br /> __xfrm_decode_session+0x54/0xb0<br /> xfrmi_xmit+0x173/0x1ca0<br /> dev_hard_start_xmit+0x187/0x700<br /> sch_direct_xmit+0x1a3/0xc30<br /> __qdisc_run+0x510/0x17a0<br /> __dev_queue_xmit+0x2215/0x3b10<br /> neigh_connected_output+0x3c2/0x550<br /> ip6_finish_output2+0x55a/0x1550<br /> ip6_finish_output+0x6b9/0x1270<br /> ip6_output+0x1f1/0x540<br /> ndisc_send_skb+0xa63/0x1890<br /> ndisc_send_rs+0x132/0x6f0<br /> addrconf_rs_timer+0x3f1/0x870<br /> call_timer_fn+0x1a0/0x580<br /> expire_timers+0x29b/0x4b0<br /> run_timer_softirq+0x326/0x910<br /> __do_softirq+0x1d4/0x905<br /> irq_exit_rcu+0xb7/0x120<br /> sysvec_apic_timer_interrupt+0x97/0xc0<br /> <br /> <br /> asm_sysvec_apic_timer_interrupt+0x1a/0x20<br /> RIP: 0010:intel_idle_hlt+0x23/0x30<br /> Code: 1f 84 00 00 00 00 00 f3 0f 1e fa 41 54 41 89 d4 0f 1f 44 00 00 66 90 0f 1f 44 00 00 0f 00 2d c4 9f ab 00 0f 1f 44 00 00 fb f4 44 89 e0 41 5c c3 66 0f 1f 44 00 00 f3 0f 1e fa 41 54 41 89 d4<br /> RSP: 0018:ffffc90000197d78 EFLAGS: 00000246<br /> RAX: 00000000000a83c3 RBX: ffffe8ffffd09c50 RCX: ffffffff8a22d8e5<br /> RDX: 0000000000000001 RSI: ffffffff8d3f8080 RDI: ffffe8ffffd09c50<br /> RBP: ffffffff8d3f8080 R08: 0000000000000001 R09: ffffed1026ba6d9d<br /> R10: ffff888135d36ceb R11: 0000000000000001 R12: 0000000000000001<br /> R13: ffffffff8d3f8100 R14: 0000000000000001 R15: 0000000000000000<br /> cpuidle_enter_state+0xd3/0x6f0<br /> cpuidle_enter+0x4e/0xa0<br /> do_idle+0x2fe/0x3c0<br /> cpu_startup_entry+0x18/0x20<br /> start_secondary+0x200/0x290<br /> secondary_startup_64_no_verify+0x167/0x16b<br /> <br /> Allocated by task 939:<br /> kasan_save_stack+0x22/0x40<br /> kasan_set_track+0x25/0x30<br /> __kasan_slab_alloc+0x7f/0x90<br /> kmem_cache_alloc_node+0x1cd/0x410<br /> kmalloc_reserve+0x165/0x270<br /> __alloc_skb+0x129/0x330<br /> inet6_ifa_notify+0x118/0x230<br /> __ipv6_ifa_notify+0x177/0xbe0<br /> addrconf_dad_completed+0x133/0xe00<br /> addrconf_dad_work+0x764/0x1390<br /> process_one_work+0xa32/0x16f0<br /> worker_thread+0x67d/0x10c0<br /> kthread+0x344/0x440<br /> ret_from_fork+0x1f/0x30<br /> The buggy address belongs to the object at ffff888111145800<br /> which belongs to the cache skbuff_small_head of size 640<br /> The buggy address is located 239 bytes inside of<br /> freed 640-byte region [ffff888111145800, ffff888111145a80)<br /> <br /> As commit f855691975bb ("xfrm6: Fix the nexthdr offset in<br /> _decode_session6.") showed, xfrm_decode_session was originally intended<br /> only for the receive path. IP6CB(skb)-&gt;nhoff is not set during<br /> transmission. Therefore, set the cb field in the skb to 0 before<br /> sending packets.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/amd/iommu_v2: Fix pasid_state refcount dec hit 0 warning on pasid unbind<br /> <br /> When unbinding pasid - a race condition exists vs outstanding page faults.<br /> <br /> To prevent this, the pasid_state object contains a refcount.<br /> * set to 1 on pasid bind<br /> * incremented on each ppr notification start<br /> * decremented on each ppr notification done<br /> * decremented on pasid unbind<br /> <br /> Since refcount_dec assumes that refcount will never reach 0:<br /> the current implementation causes the following to be invoked on<br /> pasid unbind:<br /> REFCOUNT_WARN("decrement hit 0; leaking memory")<br /> <br /> Fix this issue by changing refcount_dec to refcount_dec_and_test<br /> to explicitly handle refcount=1.

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