Vulnerabilities

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 /> ibmvnic: Do not reset dql stats on NON_FATAL err<br /> <br /> All ibmvnic resets, make a call to netdev_tx_reset_queue() when<br /> re-opening the device. netdev_tx_reset_queue() resets the num_queued<br /> and num_completed byte counters. These stats are used in Byte Queue<br /> Limit (BQL) algorithms. The difference between these two stats tracks<br /> the number of bytes currently sitting on the physical NIC. ibmvnic<br /> increases the number of queued bytes though calls to<br /> netdev_tx_sent_queue() in the drivers xmit function. When, VIOS reports<br /> that it is done transmitting bytes, the ibmvnic device increases the<br /> number of completed bytes through calls to netdev_tx_completed_queue().<br /> It is important to note that the driver batches its transmit calls and<br /> num_queued is increased every time that an skb is added to the next<br /> batch, not necessarily when the batch is sent to VIOS for transmission.<br /> <br /> Unlike other reset types, a NON FATAL reset will not flush the sub crq<br /> tx buffers. Therefore, it is possible for the batched skb array to be<br /> partially full. So if there is call to netdev_tx_reset_queue() when<br /> re-opening the device, the value of num_queued (0) would not account<br /> for the skb&amp;#39;s that are currently batched. Eventually, when the batch<br /> is sent to VIOS, the call to netdev_tx_completed_queue() would increase<br /> num_completed to a value greater than the num_queued. This causes a<br /> BUG_ON crash:<br /> <br /> ibmvnic 30000002: Firmware reports error, cause: adapter problem.<br /> Starting recovery...<br /> ibmvnic 30000002: tx error 600<br /> ibmvnic 30000002: tx error 600<br /> ibmvnic 30000002: tx error 600<br /> ibmvnic 30000002: tx error 600<br /> ------------[ cut here ]------------<br /> kernel BUG at lib/dynamic_queue_limits.c:27!<br /> Oops: Exception in kernel mode, sig: 5<br /> [....]<br /> NIP dql_completed+0x28/0x1c0<br /> LR ibmvnic_complete_tx.isra.0+0x23c/0x420 [ibmvnic]<br /> Call Trace:<br /> ibmvnic_complete_tx.isra.0+0x3f8/0x420 [ibmvnic] (unreliable)<br /> ibmvnic_interrupt_tx+0x40/0x70 [ibmvnic]<br /> __handle_irq_event_percpu+0x98/0x270<br /> ---[ end trace ]---<br /> <br /> Therefore, do not reset the dql stats when performing a NON_FATAL reset.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubifs: Fix memory leak in alloc_wbufs()<br /> <br /> kmemleak reported a sequence of memory leaks, and show them as following:<br /> <br /> unreferenced object 0xffff8881575f8400 (size 1024):<br /> comm "mount", pid 19625, jiffies 4297119604 (age 20.383s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 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 /> [] __kmalloc+0x4d/0x150<br /> [] ubifs_mount+0x307b/0x7170 [ubifs]<br /> [] legacy_get_tree+0xed/0x1d0<br /> [] vfs_get_tree+0x7d/0x230<br /> [] path_mount+0xdd4/0x17b0<br /> [] __x64_sys_mount+0x1fa/0x270<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> unreferenced object 0xffff8881798a6e00 (size 512):<br /> comm "mount", pid 19677, jiffies 4297121912 (age 37.816s)<br /> hex dump (first 32 bytes):<br /> 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk<br /> 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk<br /> backtrace:<br /> [] __kmalloc+0x4d/0x150<br /> [] ubifs_wbuf_init+0x52/0x480 [ubifs]<br /> [] ubifs_mount+0x31f5/0x7170 [ubifs]<br /> [] legacy_get_tree+0xed/0x1d0<br /> [] vfs_get_tree+0x7d/0x230<br /> [] path_mount+0xdd4/0x17b0<br /> [] __x64_sys_mount+0x1fa/0x270<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> The problem is that the ubifs_wbuf_init() returns an error in the<br /> loop which in the alloc_wbufs(), then the wbuf-&gt;buf and wbuf-&gt;inodes<br /> that were successfully alloced before are not freed.<br /> <br /> Fix it by adding error hanging path in alloc_wbufs() which frees<br /> the memory alloced before when ubifs_wbuf_init() returns an error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: fix potential leak in rtw89_append_probe_req_ie()<br /> <br /> Do `kfree_skb(new)` before `goto out` to prevent potential leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7915: fix memory leak in mt7915_mcu_exit<br /> <br /> Always purge mcu skb queues in mt7915_mcu_exit routine even if<br /> mt7915_firmware_state fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soundwire: qcom: fix storing port config out-of-bounds<br /> <br /> The &amp;#39;qcom_swrm_ctrl-&gt;pconfig&amp;#39; has size of QCOM_SDW_MAX_PORTS (14),<br /> however we index it starting from 1, not 0, to match real port numbers.<br /> This can lead to writing port config past &amp;#39;pconfig&amp;#39; bounds and<br /> overwriting next member of &amp;#39;qcom_swrm_ctrl&amp;#39; struct. Reported also by<br /> smatch:<br /> <br /> drivers/soundwire/qcom.c:1269 qcom_swrm_get_port_config() error: buffer overflow &amp;#39;ctrl-&gt;pconfig&amp;#39; 14

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: iscsi_tcp: Check that sock is valid before iscsi_set_param()<br /> <br /> The validity of sock should be checked before assignment to avoid incorrect<br /> values. Commit 57569c37f0ad ("scsi: iscsi: iscsi_tcp: Fix null-ptr-deref<br /> while calling getpeername()") introduced this change which may lead to<br /> inconsistent values of tcp_sw_conn-&gt;sendpage and conn-&gt;datadgst_en.<br /> <br /> Fix the issue by moving the position of the assignment.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: mcp-2221: prevent UAF in delayed work<br /> <br /> If the device is plugged/unplugged without giving time for mcp_init_work()<br /> to complete, we might kick in the devm free code path and thus have<br /> unavailable struct mcp_2221 while in delayed work.<br /> <br /> Canceling the delayed_work item is enough to solve the issue, because<br /> cancel_delayed_work_sync will prevent the work item to requeue itself.

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.