Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio-net: fix pages leaking when building skb in big mode<br /> <br /> We try to use build_skb() if we had sufficient tailroom. But we forget<br /> to release the unused pages chained via private in big mode which will<br /> leak pages. Fixing this by release the pages after building the skb in<br /> big mode.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> enetc: Fix illegal access when reading affinity_hint<br /> <br /> irq_set_affinity_hit() stores a reference to the cpumask_t<br /> parameter in the irq descriptor, and that reference can be<br /> accessed later from irq_affinity_hint_proc_show(). Since<br /> the cpu_mask parameter passed to irq_set_affinity_hit() has<br /> only temporary storage (it&amp;#39;s on the stack memory), later<br /> accesses to it are illegal. Thus reads from the corresponding<br /> procfs affinity_hint file can result in paging request oops.<br /> <br /> The issue is fixed by the get_cpu_mask() helper, which provides<br /> a permanent storage for the cpumask_t parameter.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/qeth: fix NULL deref in qeth_clear_working_pool_list()<br /> <br /> When qeth_set_online() calls qeth_clear_working_pool_list() to roll<br /> back after an error exit from qeth_hardsetup_card(), we are at risk of<br /> accessing card-&gt;qdio.in_q before it was allocated by<br /> qeth_alloc_qdio_queues() via qeth_mpc_initialize().<br /> <br /> qeth_clear_working_pool_list() then dereferences NULL, and by writing to<br /> queue-&gt;bufs[i].pool_entry scribbles all over the CPU&amp;#39;s lowcore.<br /> Resulting in a crash when those lowcore areas are used next (eg. on<br /> the next machine-check interrupt).<br /> <br /> Such a scenario would typically happen when the device is first set<br /> online and its queues aren&amp;#39;t allocated yet. An early IO error or certain<br /> misconfigs (eg. mismatched transport mode, bad portno) then cause us to<br /> error out from qeth_hardsetup_card() with card-&gt;qdio.in_q still being<br /> NULL.<br /> <br /> Fix it by checking the pointer for NULL before accessing it.<br /> <br /> Note that we also have (rare) paths inside qeth_mpc_initialize() where<br /> a configuration change can cause us to free the existing queues,<br /> expecting that subsequent code will allocate them again. If we then<br /> error out before that re-allocation happens, the same bug occurs.<br /> <br /> Root-caused-by: Heiko Carstens

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: ensure tx skbs always have the MPTCP ext<br /> <br /> Due to signed/unsigned comparison, the expression:<br /> <br /> info-&gt;size_goal - skb-&gt;len &gt; 0<br /> <br /> evaluates to true when the size goal is smaller than the<br /> skb size. That results in lack of tx cache refill, so that<br /> the skb allocated by the core TCP code lacks the required<br /> MPTCP skb extensions.<br /> <br /> Due to the above, syzbot is able to trigger the following WARN_ON():<br /> <br /> WARNING: CPU: 1 PID: 810 at net/mptcp/protocol.c:1366 mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366<br /> Modules linked in:<br /> CPU: 1 PID: 810 Comm: syz-executor.4 Not tainted 5.14.0-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> RIP: 0010:mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366<br /> Code: ff 4c 8b 74 24 50 48 8b 5c 24 58 e9 0f fb ff ff e8 13 44 8b f8 4c 89 e7 45 31 ed e8 98 57 2e fe e9 81 f4 ff ff e8 fe 43 8b f8 0b 41 bd ea ff ff ff e9 6f f4 ff ff 4c 89 e7 e8 b9 8e d2 f8 e9<br /> RSP: 0018:ffffc9000531f6a0 EFLAGS: 00010216<br /> RAX: 000000000000697f RBX: 0000000000000000 RCX: ffffc90012107000<br /> RDX: 0000000000040000 RSI: ffffffff88eac9e2 RDI: 0000000000000003<br /> RBP: ffff888078b15780 R08: 0000000000000000 R09: 0000000000000000<br /> R10: ffffffff88eac017 R11: 0000000000000000 R12: ffff88801de0a280<br /> R13: 0000000000006b58 R14: ffff888066278280 R15: ffff88803c2fe9c0<br /> FS: 00007fd9f866e700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007faebcb2f718 CR3: 00000000267cb000 CR4: 00000000001506e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> __mptcp_push_pending+0x1fb/0x6b0 net/mptcp/protocol.c:1547<br /> mptcp_release_cb+0xfe/0x210 net/mptcp/protocol.c:3003<br /> release_sock+0xb4/0x1b0 net/core/sock.c:3206<br /> sk_stream_wait_memory+0x604/0xed0 net/core/stream.c:145<br /> mptcp_sendmsg+0xc39/0x1bc0 net/mptcp/protocol.c:1749<br /> inet6_sendmsg+0x99/0xe0 net/ipv6/af_inet6.c:643<br /> sock_sendmsg_nosec net/socket.c:704 [inline]<br /> sock_sendmsg+0xcf/0x120 net/socket.c:724<br /> sock_write_iter+0x2a0/0x3e0 net/socket.c:1057<br /> call_write_iter include/linux/fs.h:2163 [inline]<br /> new_sync_write+0x40b/0x640 fs/read_write.c:507<br /> vfs_write+0x7cf/0xae0 fs/read_write.c:594<br /> ksys_write+0x1ee/0x250 fs/read_write.c:647<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x4665f9<br /> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007fd9f866e188 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 000000000056c038 RCX: 00000000004665f9<br /> RDX: 00000000000e7b78 RSI: 0000000020000000 RDI: 0000000000000003<br /> RBP: 00000000004bfcc4 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 000000000056c038<br /> R13: 0000000000a9fb1f R14: 00007fd9f866e300 R15: 0000000000022000<br /> <br /> Fix the issue rewriting the relevant expression to avoid<br /> sign-related problems - note: size_goal is always &gt;= 0.<br /> <br /> Additionally, ensure that the skb in the tx cache always carries<br /> the relevant extension.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mwifiex: bring down link before deleting interface<br /> <br /> We can deadlock when rmmod&amp;#39;ing the driver or going through firmware<br /> reset, because the cfg80211_unregister_wdev() has to bring down the link<br /> for us, ... which then grab the same wiphy lock.<br /> <br /> nl80211_del_interface() already handles a very similar case, with a nice<br /> description:<br /> <br /> /*<br /> * We hold RTNL, so this is safe, without RTNL opencount cannot<br /> * reach 0, and thus the rdev cannot be deleted.<br /> *<br /> * We need to do it for the dev_close(), since that will call<br /> * the netdev notifiers, and we need to acquire the mutex there<br /> * but don&amp;#39;t know if we get there from here or from some other<br /> * place (e.g. "ip link set ... down").<br /> */<br /> mutex_unlock(&amp;rdev-&gt;wiphy.mtx);<br /> ...<br /> <br /> Do similarly for mwifiex teardown, by ensuring we bring the link down<br /> first.<br /> <br /> Sample deadlock trace:<br /> <br /> [ 247.103516] INFO: task rmmod:2119 blocked for more than 123 seconds.<br /> [ 247.110630] Not tainted 5.12.4 #5<br /> [ 247.115796] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> [ 247.124557] task:rmmod state:D stack: 0 pid: 2119 ppid: 2114 flags:0x00400208<br /> [ 247.133905] Call trace:<br /> [ 247.136644] __switch_to+0x130/0x170<br /> [ 247.140643] __schedule+0x714/0xa0c<br /> [ 247.144548] schedule_preempt_disabled+0x88/0xf4<br /> [ 247.149714] __mutex_lock_common+0x43c/0x750<br /> [ 247.154496] mutex_lock_nested+0x5c/0x68<br /> [ 247.158884] cfg80211_netdev_notifier_call+0x280/0x4e0 [cfg80211]<br /> [ 247.165769] raw_notifier_call_chain+0x4c/0x78<br /> [ 247.170742] call_netdevice_notifiers_info+0x68/0xa4<br /> [ 247.176305] __dev_close_many+0x7c/0x138<br /> [ 247.180693] dev_close_many+0x7c/0x10c<br /> [ 247.184893] unregister_netdevice_many+0xfc/0x654<br /> [ 247.190158] unregister_netdevice_queue+0xb4/0xe0<br /> [ 247.195424] _cfg80211_unregister_wdev+0xa4/0x204 [cfg80211]<br /> [ 247.201816] cfg80211_unregister_wdev+0x20/0x2c [cfg80211]<br /> [ 247.208016] mwifiex_del_virtual_intf+0xc8/0x188 [mwifiex]<br /> [ 247.214174] mwifiex_uninit_sw+0x158/0x1b0 [mwifiex]<br /> [ 247.219747] mwifiex_remove_card+0x38/0xa0 [mwifiex]<br /> [ 247.225316] mwifiex_pcie_remove+0xd0/0xe0 [mwifiex_pcie]<br /> [ 247.231451] pci_device_remove+0x50/0xe0<br /> [ 247.235849] device_release_driver_internal+0x110/0x1b0<br /> [ 247.241701] driver_detach+0x5c/0x9c<br /> [ 247.245704] bus_remove_driver+0x84/0xb8<br /> [ 247.250095] driver_unregister+0x3c/0x60<br /> [ 247.254486] pci_unregister_driver+0x2c/0x90<br /> [ 247.259267] cleanup_module+0x18/0xcdc [mwifiex_pcie]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/mm: Fix lockup on kernel exec fault<br /> <br /> The powerpc kernel is not prepared to handle exec faults from kernel.<br /> Especially, the function is_exec_fault() will return &amp;#39;false&amp;#39; when an<br /> exec fault is taken by kernel, because the check is based on reading<br /> current-&gt;thread.regs-&gt;trap which contains the trap from user.<br /> <br /> For instance, when provoking a LKDTM EXEC_USERSPACE test,<br /> current-&gt;thread.regs-&gt;trap is set to SYSCALL trap (0xc00), and<br /> the fault taken by the kernel is not seen as an exec fault by<br /> set_access_flags_filter().<br /> <br /> Commit d7df2443cd5f ("powerpc/mm: Fix spurious segfaults on radix<br /> with autonuma") made it clear and handled it properly. But later on<br /> commit d3ca587404b3 ("powerpc/mm: Fix reporting of kernel execute<br /> faults") removed that handling, introducing test based on error_code.<br /> And here is the problem, because on the 603 all upper bits of SRR1<br /> get cleared when the TLB instruction miss handler bails out to ISI.<br /> <br /> Until commit cbd7e6ca0210 ("powerpc/fault: Avoid heavy<br /> search_exception_tables() verification"), an exec fault from kernel<br /> at a userspace address was indirectly caught by the lack of entry for<br /> that address in the exception tables. But after that commit the<br /> kernel mainly relies on KUAP or on core mm handling to catch wrong<br /> user accesses. Here the access is not wrong, so mm handles it.<br /> It is a minor fault because PAGE_EXEC is not set,<br /> set_access_flags_filter() should set PAGE_EXEC and voila.<br /> But as is_exec_fault() returns false as explained in the beginning,<br /> set_access_flags_filter() bails out without setting PAGE_EXEC flag,<br /> which leads to a forever minor exec fault.<br /> <br /> As the kernel is not prepared to handle such exec faults, the thing to<br /> do is to fire in bad_kernel_fault() for any exec fault taken by the<br /> kernel, as it was prior to commit d3ca587404b3.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubifs: Fix races between xattr_{set|get} and listxattr operations<br /> <br /> UBIFS may occur some problems with concurrent xattr_{set|get} and<br /> listxattr operations, such as assertion failure, memory corruption,<br /> stale xattr value[1].<br /> <br /> Fix it by importing a new rw-lock in @ubifs_inode to serilize write<br /> operations on xattr, concurrent read operations are still effective,<br /> just like ext4.<br /> <br /> [1] https://lore.kernel.org/linux-mtd/20200630130438.141649-1-houtao1@huawei.com

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udf: Fix NULL pointer dereference in udf_symlink function<br /> <br /> In function udf_symlink, epos.bh is assigned with the value returned<br /> by udf_tgetblk. The function udf_tgetblk is defined in udf/misc.c<br /> and returns the value of sb_getblk function that could be NULL.<br /> Then, epos.bh is used without any check, causing a possible<br /> NULL pointer dereference when sb_getblk fails.<br /> <br /> This fix adds a check to validate the value of epos.bh.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/sched: Avoid data corruptions<br /> <br /> Wait for all dependencies of a job to complete before<br /> killing it to avoid data corruptions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> atm: nicstar: Fix possible use-after-free in nicstar_cleanup()<br /> <br /> This module&amp;#39;s remove path calls del_timer(). However, that function<br /> does not wait until the timer handler finishes. This means that the<br /> timer handler may still be running after the driver&amp;#39;s remove function<br /> has finished, which would result in a use-after-free.<br /> <br /> Fix by calling del_timer_sync(), which makes sure the timer handler<br /> has finished, and unable to re-schedule itself.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mISDN: fix possible use-after-free in HFC_cleanup()<br /> <br /> This module&amp;#39;s remove path calls del_timer(). However, that function<br /> does not wait until the timer handler finishes. This means that the<br /> timer handler may still be running after the driver&amp;#39;s remove function<br /> has finished, which would result in a use-after-free.<br /> <br /> Fix by calling del_timer_sync(), which makes sure the timer handler<br /> has finished, and unable to re-schedule itself.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: zr364xx: fix memory leak in zr364xx_start_readpipe<br /> <br /> syzbot reported memory leak in zr364xx driver.<br /> The problem was in non-freed urb in case of<br /> usb_submit_urb() fail.<br /> <br /> backtrace:<br /> [] kmalloc include/linux/slab.h:561 [inline]<br /> [] usb_alloc_urb+0x66/0xe0 drivers/usb/core/urb.c:74<br /> [] zr364xx_start_readpipe+0x78/0x130 drivers/media/usb/zr364xx/zr364xx.c:1022<br /> [] zr364xx_board_init drivers/media/usb/zr364xx/zr364xx.c:1383 [inline]<br /> [] zr364xx_probe+0x6a3/0x851 drivers/media/usb/zr364xx/zr364xx.c:1516<br /> [] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396<br /> [] really_probe+0x159/0x500 drivers/base/dd.c:576