Vulnerabilities

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 /> ALSA: oss: Fix PCM OSS buffer allocation overflow<br /> <br /> We&amp;#39;ve got syzbot reports hitting INT_MAX overflow at vmalloc()<br /> allocation that is called from snd_pcm_plug_alloc(). Although we<br /> apply the restrictions to input parameters, it&amp;#39;s based only on the<br /> hw_params of the underlying PCM device. Since the PCM OSS layer<br /> allocates a temporary buffer for the data conversion, the size may<br /> become unexpectedly large when more channels or higher rates is given;<br /> in the reported case, it went over INT_MAX, hence it hits WARN_ON().<br /> <br /> This patch is an attempt to avoid such an overflow and an allocation<br /> for too large buffers. First off, it adds the limit of 1MB as the<br /> upper bound for period bytes. This must be large enough for all use<br /> cases, and we really don&amp;#39;t want to handle a larger temporary buffer<br /> than this size. The size check is performed at two places, where the<br /> original period bytes is calculated and where the plugin buffer size<br /> is calculated.<br /> <br /> In addition, the driver uses array_size() and array3_size() for<br /> multiplications to catch overflows for the converted period size and<br /> buffer bytes.

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 /> nbd: call genl_unregister_family() first in nbd_cleanup()<br /> <br /> Otherwise there may be race between module removal and the handling of<br /> netlink command, which can lead to the oops as shown below:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000098<br /> Oops: 0002 [#1] SMP PTI<br /> CPU: 1 PID: 31299 Comm: nbd-client Tainted: G E 5.14.0-rc4<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)<br /> RIP: 0010:down_write+0x1a/0x50<br /> Call Trace:<br /> start_creating+0x89/0x130<br /> debugfs_create_dir+0x1b/0x130<br /> nbd_start_device+0x13d/0x390 [nbd]<br /> nbd_genl_connect+0x42f/0x748 [nbd]<br /> genl_family_rcv_msg_doit.isra.0+0xec/0x150<br /> genl_rcv_msg+0xe5/0x1e0<br /> netlink_rcv_skb+0x55/0x100<br /> genl_rcv+0x29/0x40<br /> netlink_unicast+0x1a8/0x250<br /> netlink_sendmsg+0x21b/0x430<br /> ____sys_sendmsg+0x2a4/0x2d0<br /> ___sys_sendmsg+0x81/0xc0<br /> __sys_sendmsg+0x62/0xb0<br /> __x64_sys_sendmsg+0x1f/0x30<br /> do_syscall_64+0x3b/0xc0<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> Modules linked in: nbd(E-)

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nbd: fix race between nbd_alloc_config() and module removal<br /> <br /> When nbd module is being removing, nbd_alloc_config() may be<br /> called concurrently by nbd_genl_connect(), although try_module_get()<br /> will return false, but nbd_alloc_config() doesn&amp;#39;t handle it.<br /> <br /> The race may lead to the leak of nbd_config and its related<br /> resources (e.g, recv_workq) and oops in nbd_read_stat() due<br /> to the unload of nbd module as shown below:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000040<br /> Oops: 0000 [#1] SMP PTI<br /> CPU: 5 PID: 13840 Comm: kworker/u17:33 Not tainted 5.14.0+ #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)<br /> Workqueue: knbd16-recv recv_work [nbd]<br /> RIP: 0010:nbd_read_stat.cold+0x130/0x1a4 [nbd]<br /> Call Trace:<br /> recv_work+0x3b/0xb0 [nbd]<br /> process_one_work+0x1ed/0x390<br /> worker_thread+0x4a/0x3d0<br /> kthread+0x12a/0x150<br /> ret_from_fork+0x22/0x30<br /> <br /> Fixing it by checking the return value of try_module_get()<br /> in nbd_alloc_config(). As nbd_alloc_config() may return ERR_PTR(-ENODEV),<br /> assign nbd-&gt;config only when nbd_alloc_config() succeeds to ensure<br /> the value of nbd-&gt;config is binary (valid or NULL).<br /> <br /> Also adding a debug message to check the reference counter<br /> of nbd_config during module removal.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8712: fix uninit-value in usb_read8() and friends<br /> <br /> When r8712_usbctrl_vendorreq() returns negative, &amp;#39;data&amp;#39; in<br /> usb_read{8,16,32} will not be initialized.<br /> <br /> BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:643 [inline]<br /> BUG: KMSAN: uninit-value in string+0x4ec/0x6f0 lib/vsprintf.c:725<br /> string_nocheck lib/vsprintf.c:643 [inline]<br /> string+0x4ec/0x6f0 lib/vsprintf.c:725<br /> vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806<br /> va_format lib/vsprintf.c:1704 [inline]<br /> pointer+0x18e6/0x1f70 lib/vsprintf.c:2443<br /> vsnprintf+0x1a9b/0x3650 lib/vsprintf.c:2810<br /> vprintk_store+0x537/0x2150 kernel/printk/printk.c:2158<br /> vprintk_emit+0x28b/0xab0 kernel/printk/printk.c:2256<br /> dev_vprintk_emit+0x5ef/0x6d0 drivers/base/core.c:4604<br /> dev_printk_emit+0x1dd/0x21f drivers/base/core.c:4615<br /> __dev_printk+0x3be/0x440 drivers/base/core.c:4627<br /> _dev_info+0x1ea/0x22f drivers/base/core.c:4673<br /> r871xu_drv_init+0x1929/0x3070 drivers/staging/rtl8712/usb_intf.c:401<br /> usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396<br /> really_probe+0x6c7/0x1350 drivers/base/dd.c:621<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+0x6c7/0x1350 drivers/base/dd.c:621<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+0x1b91/0x2950 drivers/usb/core/hub.c:2566<br /> hub_port_connect drivers/usb/core/hub.c:5363 [inline]<br /> hub_port_connect_change drivers/usb/core/hub.c:5507 [inline]<br /> port_event drivers/usb/core/hub.c:5665 [inline]<br /> hub_event+0x58e3/0x89e0 drivers/usb/core/hub.c:5747<br /> process_one_work+0xdb6/0x1820 kernel/workqueue.c:2289<br /> worker_thread+0x10d0/0x2240 kernel/workqueue.c:2436<br /> kthread+0x3c7/0x500 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30<br /> <br /> Local variable data created at:<br /> usb_read8+0x5d/0x130 drivers/staging/rtl8712/usb_ops.c:33<br /> r8712_read8+0xa5/0xd0 drivers/staging/rtl8712/rtl8712_io.c:29<br /> <br /> KMSAN: uninit-value in r871xu_drv_init<br /> https://syzkaller.appspot.com/bug?id=3cd92b1d85428b128503bfa7a250294c9ae00bd8

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: quota: fix loop condition at f2fs_quota_sync()<br /> <br /> cnt should be passed to sb_has_quota_active() instead of type to check<br /> active quota properly.<br /> <br /> Moreover, when the type is -1, the compiler with enough inline knowledge<br /> can discard sb_has_quota_active() check altogether, causing a NULL pointer<br /> dereference at the following inode_lock(dqopt-&gt;files[cnt]):<br /> <br /> [ 2.796010] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0<br /> [ 2.796024] Mem abort info:<br /> [ 2.796025] ESR = 0x96000005<br /> [ 2.796028] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 2.796029] SET = 0, FnV = 0<br /> [ 2.796031] EA = 0, S1PTW = 0<br /> [ 2.796032] Data abort info:<br /> [ 2.796034] ISV = 0, ISS = 0x00000005<br /> [ 2.796035] CM = 0, WnR = 0<br /> [ 2.796046] user pgtable: 4k pages, 39-bit VAs, pgdp=00000003370d1000<br /> [ 2.796048] [00000000000000a0] pgd=0000000000000000, pud=0000000000000000<br /> [ 2.796051] Internal error: Oops: 96000005 [#1] PREEMPT SMP<br /> [ 2.796056] CPU: 7 PID: 640 Comm: f2fs_ckpt-259:7 Tainted: G S 5.4.179-arter97-r8-64666-g2f16e087f9d8 #1<br /> [ 2.796057] Hardware name: Qualcomm Technologies, Inc. Lahaina MTP lemonadep (DT)<br /> [ 2.796059] pstate: 80c00005 (Nzcv daif +PAN +UAO)<br /> [ 2.796065] pc : down_write+0x28/0x70<br /> [ 2.796070] lr : f2fs_quota_sync+0x100/0x294<br /> [ 2.796071] sp : ffffffa3f48ffc30<br /> [ 2.796073] x29: ffffffa3f48ffc30 x28: 0000000000000000<br /> [ 2.796075] x27: ffffffa3f6d718b8 x26: ffffffa415fe9d80<br /> [ 2.796077] x25: ffffffa3f7290048 x24: 0000000000000001<br /> [ 2.796078] x23: 0000000000000000 x22: ffffffa3f7290000<br /> [ 2.796080] x21: ffffffa3f72904a0 x20: ffffffa3f7290110<br /> [ 2.796081] x19: ffffffa3f77a9800 x18: ffffffc020aae038<br /> [ 2.796083] x17: ffffffa40e38e040 x16: ffffffa40e38e6d0<br /> [ 2.796085] x15: ffffffa40e38e6cc x14: ffffffa40e38e6d0<br /> [ 2.796086] x13: 00000000000004f6 x12: 00162c44ff493000<br /> [ 2.796088] x11: 0000000000000400 x10: ffffffa40e38c948<br /> [ 2.796090] x9 : 0000000000000000 x8 : 00000000000000a0<br /> [ 2.796091] x7 : 0000000000000000 x6 : 0000d1060f00002a<br /> [ 2.796093] x5 : ffffffa3f48ff718 x4 : 000000000000000d<br /> [ 2.796094] x3 : 00000000060c0000 x2 : 0000000000000001<br /> [ 2.796096] x1 : 0000000000000000 x0 : 00000000000000a0<br /> [ 2.796098] Call trace:<br /> [ 2.796100] down_write+0x28/0x70<br /> [ 2.796102] f2fs_quota_sync+0x100/0x294<br /> [ 2.796104] block_operations+0x120/0x204<br /> [ 2.796106] f2fs_write_checkpoint+0x11c/0x520<br /> [ 2.796107] __checkpoint_and_complete_reqs+0x7c/0xd34<br /> [ 2.796109] issue_checkpoint_thread+0x6c/0xb8<br /> [ 2.796112] kthread+0x138/0x414<br /> [ 2.796114] ret_from_fork+0x10/0x18<br /> [ 2.796117] Code: aa0803e0 aa1f03e1 52800022 aa0103e9 (c8e97d02)<br /> [ 2.796120] ---[ end trace 96e942e8eb6a0b53 ]---<br /> [ 2.800116] Kernel panic - not syncing: Fatal exception<br /> [ 2.800120] SMP: stopping secondary CPUs