Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: cx23885: Fix a null-ptr-deref bug in buffer_prepare() and buffer_finish()<br /> <br /> When the driver calls cx23885_risc_buffer() to prepare the buffer, the<br /> function call dma_alloc_coherent may fail, resulting in a empty buffer<br /> risc-&gt;cpu. Later when we free the buffer or access the buffer, null ptr<br /> deref is triggered.<br /> <br /> This bug is similar to the following one:<br /> https://git.linuxtv.org/media_stage.git/commit/?id=2b064d91440b33fba5b452f2d1b31f13ae911d71.<br /> <br /> We believe the bug can be also dynamically triggered from user side.<br /> Similarly, we fix this by checking the return value of cx23885_risc_buffer()<br /> and the value of risc-&gt;cpu before buffer free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> FS: JFS: Fix null-ptr-deref Read in txBegin<br /> <br /> Syzkaller reported an issue where txBegin may be called<br /> on a superblock in a read-only mounted filesystem which leads<br /> to NULL pointer deref. This could be solved by checking if<br /> the filesystem is read-only before calling txBegin, and returning<br /> with appropiate error code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw88: fix memory leak in rtw_usb_probe()<br /> <br /> drivers/net/wireless/realtek/rtw88/usb.c:876 rtw_usb_probe()<br /> warn: &amp;#39;hw&amp;#39; from ieee80211_alloc_hw() not released on lines: 811<br /> <br /> Fix this by modifying return to a goto statement.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hsr: Fix uninit-value access in fill_frame_info()<br /> <br /> Syzbot reports the following uninit-value access problem.<br /> <br /> =====================================================<br /> BUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:601 [inline]<br /> BUG: KMSAN: uninit-value in hsr_forward_skb+0x9bd/0x30f0 net/hsr/hsr_forward.c:616<br /> fill_frame_info net/hsr/hsr_forward.c:601 [inline]<br /> hsr_forward_skb+0x9bd/0x30f0 net/hsr/hsr_forward.c:616<br /> hsr_dev_xmit+0x192/0x330 net/hsr/hsr_device.c:223<br /> __netdev_start_xmit include/linux/netdevice.h:4889 [inline]<br /> netdev_start_xmit include/linux/netdevice.h:4903 [inline]<br /> xmit_one net/core/dev.c:3544 [inline]<br /> dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3560<br /> __dev_queue_xmit+0x34d0/0x52a0 net/core/dev.c:4340<br /> dev_queue_xmit include/linux/netdevice.h:3082 [inline]<br /> packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276<br /> packet_snd net/packet/af_packet.c:3087 [inline]<br /> packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> sock_sendmsg net/socket.c:753 [inline]<br /> __sys_sendto+0x781/0xa30 net/socket.c:2176<br /> __do_sys_sendto net/socket.c:2188 [inline]<br /> __se_sys_sendto net/socket.c:2184 [inline]<br /> __ia32_sys_sendto+0x11f/0x1c0 net/socket.c:2184<br /> do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]<br /> __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178<br /> do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203<br /> do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246<br /> entry_SYSENTER_compat_after_hwframe+0x70/0x82<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767<br /> slab_alloc_node mm/slub.c:3478 [inline]<br /> kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523<br /> kmalloc_reserve+0x148/0x470 net/core/skbuff.c:559<br /> __alloc_skb+0x318/0x740 net/core/skbuff.c:644<br /> alloc_skb include/linux/skbuff.h:1286 [inline]<br /> alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6299<br /> sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2794<br /> packet_alloc_skb net/packet/af_packet.c:2936 [inline]<br /> packet_snd net/packet/af_packet.c:3030 [inline]<br /> packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> sock_sendmsg net/socket.c:753 [inline]<br /> __sys_sendto+0x781/0xa30 net/socket.c:2176<br /> __do_sys_sendto net/socket.c:2188 [inline]<br /> __se_sys_sendto net/socket.c:2184 [inline]<br /> __ia32_sys_sendto+0x11f/0x1c0 net/socket.c:2184<br /> do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]<br /> __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178<br /> do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203<br /> do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246<br /> entry_SYSENTER_compat_after_hwframe+0x70/0x82<br /> <br /> It is because VLAN not yet supported in hsr driver. Return error<br /> when protocol is ETH_P_8021Q in fill_frame_info() now to fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: wait interruptibly for request completions on exit<br /> <br /> WHen the ring exits, cleanup is done and the final cancelation and<br /> waiting on completions is done by io_ring_exit_work. That function is<br /> invoked by kworker, which doesn&amp;#39;t take any signals. Because of that, it<br /> doesn&amp;#39;t really matter if we wait for completions in TASK_INTERRUPTIBLE<br /> or TASK_UNINTERRUPTIBLE state. However, it does matter to the hung task<br /> detection checker!<br /> <br /> Normally we expect cancelations and completions to happen rather<br /> quickly. Some test cases, however, will exit the ring and park the<br /> owning task stopped (eg via SIGSTOP). If the owning task needs to run<br /> task_work to complete requests, then io_ring_exit_work won&amp;#39;t make any<br /> progress until the task is runnable again. Hence io_ring_exit_work can<br /> trigger the hung task detection, which is particularly problematic if<br /> panic-on-hung-task is enabled.<br /> <br /> As the ring exit doesn&amp;#39;t take signals to begin with, have it wait<br /> interruptibly rather than uninterruptibly. io_uring has a separate<br /> stuck-exit warning that triggers independently anyway, so we&amp;#39;re not<br /> really missing anything by making this switch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla4xxx: Add length check when parsing nlattrs<br /> <br /> There are three places that qla4xxx parses nlattrs:<br /> <br /> - qla4xxx_set_chap_entry()<br /> <br /> - qla4xxx_iface_set_param()<br /> <br /> - qla4xxx_sysfs_ddb_set_param()<br /> <br /> and each of them directly converts the nlattr to specific pointer of<br /> structure without length checking. This could be dangerous as those<br /> attributes are not validated and a malformed nlattr (e.g., length 0) could<br /> result in an OOB read that leaks heap dirty data.<br /> <br /> Add the nla_len check before accessing the nlattr data and return EINVAL if<br /> the length check fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vc4: drop all currently held locks if deadlock happens<br /> <br /> If vc4_hdmi_reset_link() returns -EDEADLK, it means that a deadlock<br /> happened in the locking context. This situation should be addressed by<br /> dropping all currently held locks and block until the contended lock<br /> becomes available. Currently, vc4 is not dealing with the deadlock<br /> properly, producing the following output when PROVE_LOCKING is enabled:<br /> <br /> [ 825.612809] ------------[ cut here ]------------<br /> [ 825.612852] WARNING: CPU: 1 PID: 116 at drivers/gpu/drm/drm_modeset_lock.c:276 drm_modeset_drop_locks+0x60/0x68 [drm]<br /> [ 825.613458] Modules linked in: 8021q mrp garp stp llc<br /> raspberrypi_cpufreq brcmfmac brcmutil crct10dif_ce hci_uart cfg80211<br /> btqca btbcm bluetooth vc4 raspberrypi_hwmon snd_soc_hdmi_codec cec<br /> clk_raspberrypi ecdh_generic drm_display_helper ecc rfkill<br /> drm_dma_helper drm_kms_helper pwm_bcm2835 bcm2835_thermal bcm2835_rng<br /> rng_core i2c_bcm2835 drm fuse ip_tables x_tables ipv6<br /> [ 825.613735] CPU: 1 PID: 116 Comm: kworker/1:2 Tainted: G W 6.1.0-rc6-01399-g941aae326315 #3<br /> [ 825.613759] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)<br /> [ 825.613777] Workqueue: events output_poll_execute [drm_kms_helper]<br /> [ 825.614038] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 825.614063] pc : drm_modeset_drop_locks+0x60/0x68 [drm]<br /> [ 825.614603] lr : drm_helper_probe_detect+0x120/0x1b4 [drm_kms_helper]<br /> [ 825.614829] sp : ffff800008313bf0<br /> [ 825.614844] x29: ffff800008313bf0 x28: ffffcd7778b8b000 x27: 0000000000000000<br /> [ 825.614883] x26: 0000000000000001 x25: 0000000000000001 x24: ffff677cc35c2758<br /> [ 825.614920] x23: ffffcd7707d01430 x22: ffffcd7707c3edc7 x21: 0000000000000001<br /> [ 825.614958] x20: 0000000000000000 x19: ffff800008313c10 x18: 000000000000b6d3<br /> [ 825.614995] x17: ffffcd777835e214 x16: ffffcd7777cef870 x15: fffff81000000000<br /> [ 825.615033] x14: 0000000000000000 x13: 0000000000000099 x12: 0000000000000002<br /> [ 825.615070] x11: 72917988020af800 x10: 72917988020af800 x9 : 72917988020af800<br /> [ 825.615108] x8 : ffff677cc665e0a8 x7 : d00a8c180000110c x6 : ffffcd77774c0054<br /> [ 825.615145] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000<br /> [ 825.615181] x2 : ffff677cc55e1880 x1 : ffffcd7777cef8ec x0 : ffff800008313c10<br /> [ 825.615219] Call trace:<br /> [ 825.615232] drm_modeset_drop_locks+0x60/0x68 [drm]<br /> [ 825.615773] drm_helper_probe_detect+0x120/0x1b4 [drm_kms_helper]<br /> [ 825.616003] output_poll_execute+0xe4/0x224 [drm_kms_helper]<br /> [ 825.616233] process_one_work+0x2b4/0x618<br /> [ 825.616264] worker_thread+0x24c/0x464<br /> [ 825.616288] kthread+0xec/0x110<br /> [ 825.616310] ret_from_fork+0x10/0x20<br /> [ 825.616335] irq event stamp: 7634<br /> [ 825.616349] hardirqs last enabled at (7633): [] _raw_spin_unlock_irq+0x3c/0x78<br /> [ 825.616384] hardirqs last disabled at (7634): [] __schedule+0x134/0x9f0<br /> [ 825.616411] softirqs last enabled at (7630): [] local_bh_enable+0x4/0x30 [ipv6]<br /> [ 825.617019] softirqs last disabled at (7618): [] local_bh_disable+0x4/0x30 [ipv6]<br /> [ 825.617586] ---[ end trace 0000000000000000 ]---<br /> <br /> Therefore, deal with the deadlock as suggested by [1], using the<br /> function drm_modeset_backoff().<br /> <br /> [1] https://docs.kernel.org/gpu/drm-kms.html?highlight=kms#kms-locking

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: multitouch: Correct devm device reference for hidinput input_dev name<br /> <br /> Reference the HID device rather than the input device for the devm<br /> allocation of the input_dev name. Referencing the input_dev would lead to a<br /> use-after-free when the input_dev was unregistered and subsequently fires a<br /> uevent that depends on the name. At the point of firing the uevent, the<br /> name would be freed by devres management.<br /> <br /> Use devm_kasprintf to simplify the logic for allocating memory and<br /> formatting the input_dev name string.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/radeon: free iio for atombios when driver shutdown<br /> <br /> Fix below kmemleak when unload radeon driver:<br /> <br /> unreferenced object 0xffff9f8608ede200 (size 512):<br /> comm "systemd-udevd", pid 326, jiffies 4294682822 (age 716.338s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 c4 aa ec aa 14 ab 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] kmem_cache_alloc_trace+0x2f1/0x500<br /> [] atom_parse+0x117/0x230 [radeon]<br /> [] radeon_atombios_init+0xab/0x170 [radeon]<br /> [] si_init+0x57/0x750 [radeon]<br /> [] radeon_device_init+0x559/0x9c0 [radeon]<br /> [] radeon_driver_load_kms+0xc1/0x1a0 [radeon]<br /> [] drm_dev_register+0xdd/0x1d0<br /> [] radeon_pci_probe+0xbd/0x100 [radeon]<br /> [] pci_device_probe+0xe1/0x160<br /> [] really_probe.part.0+0xc1/0x2c0<br /> [] __driver_probe_device+0x96/0x130<br /> [] driver_probe_device+0x24/0xf0<br /> [] __driver_attach+0x77/0x190<br /> [] bus_for_each_dev+0x7f/0xd0<br /> [] driver_attach+0x1e/0x30<br /> [] bus_add_driver+0x12c/0x1e0<br /> <br /> iio was allocated in atom_index_iio() called by atom_parse(),<br /> but it doesn&amp;#39;t got released when the dirver is shutdown.<br /> Fix this kmemleak by free it in radeon_atombios_fini().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: fix potential race condition between napi_init and napi_enable<br /> <br /> A race condition can happen if netdev is registered, but NAPI isn&amp;#39;t<br /> initialized yet, and meanwhile user space starts the netdev that will<br /> enable NAPI. Then, it hits BUG_ON():<br /> <br /> kernel BUG at net/core/dev.c:6423!<br /> invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 0 PID: 417 Comm: iwd Not tainted 6.2.7-slab-dirty #3 eb0f5a8a9d91<br /> Hardware name: LENOVO 21DL/LNVNB161216, BIOS JPCN20WW(V1.06) 09/20/2022<br /> RIP: 0010:napi_enable+0x3f/0x50<br /> Code: 48 89 c2 48 83 e2 f6 f6 81 89 08 00 00 02 74 0d 48 83 ...<br /> RSP: 0018:ffffada1414f3548 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffffa01425802080 RCX: 0000000000000000<br /> RDX: 00000000000002ff RSI: ffffada14e50c614 RDI: ffffa01425808dc0<br /> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000001 R11: 0000000000000100 R12: ffffa01425808f58<br /> R13: 0000000000000000 R14: ffffa01423498940 R15: 0000000000000001<br /> FS: 00007f5577c0a740(0000) GS:ffffa0169fc00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f5577a19972 CR3: 0000000125a7a000 CR4: 0000000000750ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> rtw89_pci_ops_start+0x1c/0x70 [rtw89_pci 6cbc75429515c181cbc386478d5cfb32ffc5a0f8]<br /> rtw89_core_start+0xbe/0x160 [rtw89_core fe07ecb874820b6d778370d4acb6ef8a37847f22]<br /> rtw89_ops_start+0x26/0x40 [rtw89_core fe07ecb874820b6d778370d4acb6ef8a37847f22]<br /> drv_start+0x42/0x100 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2]<br /> ieee80211_do_open+0x311/0x7d0 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2]<br /> ieee80211_open+0x6a/0x90 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2]<br /> __dev_open+0xe0/0x180<br /> __dev_change_flags+0x1da/0x250<br /> dev_change_flags+0x26/0x70<br /> do_setlink+0x37c/0x12c0<br /> ? ep_poll_callback+0x246/0x290<br /> ? __nla_validate_parse+0x61/0xd00<br /> ? __wake_up_common_lock+0x8f/0xd0<br /> <br /> To fix this, follow Jonas&amp;#39; suggestion to switch the order of these<br /> functions and move register netdev to be the last step of PCI probe.<br /> Also, correct the error handling of rtw89_core_register_hw().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Fix potential NULL pointer dereference<br /> <br /> Klocwork tool reported &amp;#39;cur_dsd&amp;#39; may be dereferenced. Add fix to validate<br /> pointer before dereferencing the pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/dasd: Fix potential memleak in dasd_eckd_init()<br /> <br /> `dasd_reserve_req` is allocated before `dasd_vol_info_req`, and it<br /> also needs to be freed before the error returns, just like the other<br /> cases in this function.