Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: synclink_gt: Fix null-pointer-dereference in slgt_clean()<br /> <br /> When the driver fails at alloc_hdlcdev(), and then we remove the driver<br /> module, we will get the following splat:<br /> <br /> [ 25.065966] general protection fault, probably for non-canonical address 0xdffffc0000000182: 0000 [#1] PREEMPT SMP KASAN PTI<br /> [ 25.066914] KASAN: null-ptr-deref in range [0x0000000000000c10-0x0000000000000c17]<br /> [ 25.069262] RIP: 0010:detach_hdlc_protocol+0x2a/0x3e0<br /> [ 25.077709] Call Trace:<br /> [ 25.077924] <br /> [ 25.078108] unregister_hdlc_device+0x16/0x30<br /> [ 25.078481] slgt_cleanup+0x157/0x9f0 [synclink_gt]<br /> <br /> Fix this by checking whether the &amp;#39;info-&gt;netdev&amp;#39; is a null pointer first.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> extcon: Modify extcon device to be created after driver data is set<br /> <br /> Currently, someone can invoke the sysfs such as state_show()<br /> intermittently before dev_set_drvdata() is done.<br /> And it can be a cause of kernel Oops because of edev is Null at that time.<br /> So modified the driver registration to after setting drviver data.<br /> <br /> - Oops&amp;#39;s backtrace.<br /> <br /> Backtrace:<br /> [] (state_show) from [] (dev_attr_show)<br /> [] (dev_attr_show) from [] (sysfs_kf_seq_show)<br /> [] (sysfs_kf_seq_show) from [] (kernfs_seq_show)<br /> [] (kernfs_seq_show) from [] (seq_read)<br /> [] (seq_read) from [] (kernfs_fop_read)<br /> [] (kernfs_fop_read) from [] (__vfs_read)<br /> [] (__vfs_read) from [] (vfs_read)<br /> [] (vfs_read) from [] (ksys_read)<br /> [] (ksys_read) from [] (sys_read)<br /> [] (sys_read) from [] (__sys_trace_return)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: staging: rtl8723bs: Fix deadlock in rtw_surveydone_event_callback()<br /> <br /> There is a deadlock in rtw_surveydone_event_callback(),<br /> which is shown below:<br /> <br /> (Thread 1) | (Thread 2)<br /> | _set_timer()<br /> rtw_surveydone_event_callback()| mod_timer()<br /> spin_lock_bh() //(1) | (wait a time)<br /> ... | rtw_scan_timeout_handler()<br /> del_timer_sync() | spin_lock_bh() //(2)<br /> (wait timer to stop) | ...<br /> <br /> We hold pmlmepriv-&gt;lock in position (1) of thread 1 and use<br /> del_timer_sync() to wait timer to stop, but timer handler<br /> also need pmlmepriv-&gt;lock in position (2) of thread 2.<br /> As a result, rtw_surveydone_event_callback() will block forever.<br /> <br /> This patch extracts del_timer_sync() from the protection of<br /> spin_lock_bh(), which could let timer handler to obtain<br /> the needed lock. What`s more, we change spin_lock_bh() in<br /> rtw_scan_timeout_handler() to spin_lock_irq(). Otherwise,<br /> spin_lock_bh() will also cause deadlock() in timer handler.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> char: xillybus: fix a refcount leak in cleanup_dev()<br /> <br /> usb_get_dev is called in xillyusb_probe. So it is better to call<br /> usb_put_dev before xdev is released.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: staging: rtl8192bs: Fix deadlock in rtw_joinbss_event_prehandle()<br /> <br /> There is a deadlock in rtw_joinbss_event_prehandle(), which is shown<br /> below:<br /> <br /> (Thread 1) | (Thread 2)<br /> | _set_timer()<br /> rtw_joinbss_event_prehandle()| mod_timer()<br /> spin_lock_bh() //(1) | (wait a time)<br /> ... | _rtw_join_timeout_handler()<br /> del_timer_sync() | spin_lock_bh() //(2)<br /> (wait timer to stop) | ...<br /> <br /> We hold pmlmepriv-&gt;lock in position (1) of thread 1 and<br /> use del_timer_sync() to wait timer to stop, but timer handler<br /> also need pmlmepriv-&gt;lock in position (2) of thread 2.<br /> As a result, rtw_joinbss_event_prehandle() will block forever.<br /> <br /> This patch extracts del_timer_sync() from the protection of<br /> spin_lock_bh(), which could let timer handler to obtain<br /> the needed lock. What`s more, we change spin_lock_bh() to<br /> spin_lock_irq() in _rtw_join_timeout_handler() in order to<br /> prevent deadlock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8712: fix a potential memory leak in r871xu_drv_init()<br /> <br /> In r871xu_drv_init(), if r8712_init_drv_sw() fails, then the memory<br /> allocated by r8712_alloc_io_queue() in r8712_usb_dvobj_init() is not<br /> properly released as there is no action will be performed by<br /> r8712_usb_dvobj_deinit().<br /> To properly release it, we should call r8712_free_io_queue() in<br /> r8712_usb_dvobj_deinit().<br /> <br /> Besides, in r871xu_dev_remove(), r8712_usb_dvobj_deinit() will be called<br /> by r871x_dev_unload() under condition `padapter-&gt;bup` and<br /> r8712_free_io_queue() is called by r8712_free_drv_sw().<br /> However, r8712_usb_dvobj_deinit() does not rely on `padapter-&gt;bup` and<br /> calling r8712_free_io_queue() in r8712_free_drv_sw() is negative for<br /> better understading the code.<br /> So I move r8712_usb_dvobj_deinit() into r871xu_dev_remove(), and remove<br /> r8712_free_io_queue() from r8712_free_drv_sw().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: initialize registers in nft_do_chain()<br /> <br /> Initialize registers to avoid stack leak into userspace.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Check if modulo is 0 before dividing.<br /> <br /> [How &amp; Why]<br /> If a value of 0 is read, then this will cause a divide-by-0 panic.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: fix possible deadlock when holding Fwb to get inline_data<br /> <br /> 1, mount with wsync.<br /> 2, create a file with O_RDWR, and the request was sent to mds.0:<br /> <br /> ceph_atomic_open()--&gt;<br /> ceph_mdsc_do_request(openc)<br /> finish_open(file, dentry, ceph_open)--&gt;<br /> ceph_open()--&gt;<br /> ceph_init_file()--&gt;<br /> ceph_init_file_info()--&gt;<br /> ceph_uninline_data()--&gt;<br /> {<br /> ...<br /> if (inline_version == 1 || /* initial version, no data */<br /> inline_version == CEPH_INLINE_NONE)<br /> goto out_unlock;<br /> ...<br /> }<br /> <br /> The inline_version will be 1, which is the initial version for the<br /> new create file. And here the ci-&gt;i_inline_version will keep with 1,<br /> it&amp;#39;s buggy.<br /> <br /> 3, buffer write to the file immediately:<br /> <br /> ceph_write_iter()--&gt;<br /> ceph_get_caps(file, need=Fw, want=Fb, ...);<br /> generic_perform_write()--&gt;<br /> a_ops-&gt;write_begin()--&gt;<br /> ceph_write_begin()--&gt;<br /> netfs_write_begin()--&gt;<br /> netfs_begin_read()--&gt;<br /> netfs_rreq_submit_slice()--&gt;<br /> netfs_read_from_server()--&gt;<br /> rreq-&gt;netfs_ops-&gt;issue_read()--&gt;<br /> ceph_netfs_issue_read()--&gt;<br /> {<br /> ...<br /> if (ci-&gt;i_inline_version != CEPH_INLINE_NONE &amp;&amp;<br /> ceph_netfs_issue_op_inline(subreq))<br /> return;<br /> ...<br /> }<br /> ceph_put_cap_refs(ci, Fwb);<br /> <br /> The ceph_netfs_issue_op_inline() will send a getattr(Fsr) request to<br /> mds.1.<br /> <br /> 4, then the mds.1 will request the rd lock for CInode::filelock from<br /> the auth mds.0, the mds.0 will do the CInode::filelock state transation<br /> from excl --&gt; sync, but it need to revoke the Fxwb caps back from the<br /> clients.<br /> <br /> While the kernel client has aleady held the Fwb caps and waiting for<br /> the getattr(Fsr).<br /> <br /> It&amp;#39;s deadlock!<br /> <br /> URL: https://tracker.ceph.com/issues/55377

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nbd: fix io hung while disconnecting device<br /> <br /> In our tests, "qemu-nbd" triggers a io hung:<br /> <br /> INFO: task qemu-nbd:11445 blocked for more than 368 seconds.<br /> Not tainted 5.18.0-rc3-next-20220422-00003-g2176915513ca #884<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:qemu-nbd state:D stack: 0 pid:11445 ppid: 1 flags:0x00000000<br /> Call Trace:<br /> <br /> __schedule+0x480/0x1050<br /> ? _raw_spin_lock_irqsave+0x3e/0xb0<br /> schedule+0x9c/0x1b0<br /> blk_mq_freeze_queue_wait+0x9d/0xf0<br /> ? ipi_rseq+0x70/0x70<br /> blk_mq_freeze_queue+0x2b/0x40<br /> nbd_add_socket+0x6b/0x270 [nbd]<br /> nbd_ioctl+0x383/0x510 [nbd]<br /> blkdev_ioctl+0x18e/0x3e0<br /> __x64_sys_ioctl+0xac/0x120<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7fd8ff706577<br /> RSP: 002b:00007fd8fcdfebf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 0000000040000000 RCX: 00007fd8ff706577<br /> RDX: 000000000000000d RSI: 000000000000ab00 RDI: 000000000000000f<br /> RBP: 000000000000000f R08: 000000000000fbe8 R09: 000055fe497c62b0<br /> R10: 00000002aff20000 R11: 0000000000000246 R12: 000000000000006d<br /> R13: 0000000000000000 R14: 00007ffe82dc5e70 R15: 00007fd8fcdff9c0<br /> <br /> "qemu-ndb -d" will call ioctl &amp;#39;NBD_DISCONNECT&amp;#39; first, however, following<br /> message was found:<br /> <br /> block nbd0: Send disconnect failed -32<br /> <br /> Which indicate that something is wrong with the server. Then,<br /> "qemu-nbd -d" will call ioctl &amp;#39;NBD_CLEAR_SOCK&amp;#39;, however ioctl can&amp;#39;t clear<br /> requests after commit 2516ab1543fd("nbd: only clear the queue on device<br /> teardown"). And in the meantime, request can&amp;#39;t complete through timeout<br /> because nbd_xmit_timeout() will always return &amp;#39;BLK_EH_RESET_TIMER&amp;#39;, which<br /> means such request will never be completed in this situation.<br /> <br /> Now that the flag &amp;#39;NBD_CMD_INFLIGHT&amp;#39; can make sure requests won&amp;#39;t<br /> complete multiple times, switch back to call nbd_clear_sock() in<br /> nbd_clear_sock_ioctl(), so that inflight requests can be cleared.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8712: fix uninit-value in r871xu_drv_init()<br /> <br /> When &amp;#39;tmpU1b&amp;#39; returns from r8712_read8(padapter, EE_9346CR) is 0,<br /> &amp;#39;mac[6]&amp;#39; will not be initialized.<br /> <br /> BUG: KMSAN: uninit-value in r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541<br /> r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541<br /> usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396<br /> really_probe+0x653/0x14b0 drivers/base/dd.c:596<br /> __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752<br /> driver_probe_device drivers/base/dd.c:782 [inline]<br /> __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899<br /> bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427<br /> __device_attach+0x593/0x8e0 drivers/base/dd.c:970<br /> device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017<br /> bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487<br /> device_add+0x1fff/0x26e0 drivers/base/core.c:3405<br /> usb_set_configuration+0x37e9/0x3ed0 drivers/usb/core/message.c:2170<br /> usb_generic_driver_probe+0x13c/0x300 drivers/usb/core/generic.c:238<br /> usb_probe_device+0x309/0x570 drivers/usb/core/driver.c:293<br /> really_probe+0x653/0x14b0 drivers/base/dd.c:596<br /> __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752<br /> driver_probe_device drivers/base/dd.c:782 [inline]<br /> __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899<br /> bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427<br /> __device_attach+0x593/0x8e0 drivers/base/dd.c:970<br /> device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017<br /> bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487<br /> device_add+0x1fff/0x26e0 drivers/base/core.c:3405<br /> usb_new_device+0x1b8e/0x2950 drivers/usb/core/hub.c:2566<br /> hub_port_connect drivers/usb/core/hub.c:5358 [inline]<br /> hub_port_connect_change drivers/usb/core/hub.c:5502 [inline]<br /> port_event drivers/usb/core/hub.c:5660 [inline]<br /> hub_event+0x58e3/0x89e0 drivers/usb/core/hub.c:5742<br /> process_one_work+0xdb6/0x1820 kernel/workqueue.c:2307<br /> worker_thread+0x10b3/0x21e0 kernel/workqueue.c:2454<br /> kthread+0x3c7/0x500 kernel/kthread.c:377<br /> ret_from_fork+0x1f/0x30<br /> <br /> Local variable mac created at:<br /> r871xu_drv_init+0x1771/0x3070 drivers/staging/rtl8712/usb_intf.c:394<br /> usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396<br /> <br /> KMSAN: uninit-value in r871xu_drv_init<br /> https://syzkaller.appspot.com/bug?id=3cd92b1d85428b128503bfa7a250294c9ae00bd8

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