Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: improve error handling from ext4_dirhash()<br /> <br /> The ext4_dirhash() will *almost* never fail, especially when the hash<br /> tree feature was first introduced. However, with the addition of<br /> support of encrypted, casefolded file names, that function can most<br /> certainly fail today.<br /> <br /> So make sure the callers of ext4_dirhash() properly check for<br /> failures, and reflect the errors back up to their callers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/MCE/AMD: Use an u64 for bank_map<br /> <br /> Thee maximum number of MCA banks is 64 (MAX_NR_BANKS), see<br /> <br /> a0bc32b3cacf ("x86/mce: Increase maximum number of banks to 64").<br /> <br /> However, the bank_map which contains a bitfield of which banks to<br /> initialize is of type unsigned int and that overflows when those bit<br /> numbers are &gt;= 32, leading to UBSAN complaining correctly:<br /> <br /> UBSAN: shift-out-of-bounds in arch/x86/kernel/cpu/mce/amd.c:1365:38<br /> shift exponent 32 is too large for 32-bit type &amp;#39;int&amp;#39;<br /> <br /> Change the bank_map to a u64 and use the proper BIT_ULL() macro when<br /> modifying bits in there.<br /> <br /> [ bp: Rewrite commit message. ]

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 /> 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 /> 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 /> 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.

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 /> 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 /> 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 /> 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 /> 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.