Vulnerabilities

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/cma: Fix rdma_resolve_route() memory leak<br /> <br /> Fix a memory leak when "mda_resolve_route() is called more than once on<br /> the same "rdma_cm_id".<br /> <br /> This is possible if cma_query_handler() triggers the<br /> RDMA_CM_EVENT_ROUTE_ERROR flow which puts the state machine back and<br /> allows rdma_resolve_route() to be called again.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> coresight: tmc-etf: Fix global-out-of-bounds in tmc_update_etf_buffer()<br /> <br /> commit 6f755e85c332 ("coresight: Add helper for inserting synchronization<br /> packets") removed trailing &amp;#39;\0&amp;#39; from barrier_pkt array and updated the<br /> call sites like etb_update_buffer() to have proper checks for barrier_pkt<br /> size before read but missed updating tmc_update_etf_buffer() which still<br /> reads barrier_pkt past the array size resulting in KASAN out-of-bounds<br /> bug. Fix this by adding a check for barrier_pkt size before accessing<br /> like it is done in etb_update_buffer().<br /> <br /> BUG: KASAN: global-out-of-bounds in tmc_update_etf_buffer+0x4b8/0x698<br /> Read of size 4 at addr ffffffd05b7d1030 by task perf/2629<br /> <br /> Call trace:<br /> dump_backtrace+0x0/0x27c<br /> show_stack+0x20/0x2c<br /> dump_stack+0x11c/0x188<br /> print_address_description+0x3c/0x4a4<br /> __kasan_report+0x140/0x164<br /> kasan_report+0x10/0x18<br /> __asan_report_load4_noabort+0x1c/0x24<br /> tmc_update_etf_buffer+0x4b8/0x698<br /> etm_event_stop+0x248/0x2d8<br /> etm_event_del+0x20/0x2c<br /> event_sched_out+0x214/0x6f0<br /> group_sched_out+0xd0/0x270<br /> ctx_sched_out+0x2ec/0x518<br /> __perf_event_task_sched_out+0x4fc/0xe6c<br /> __schedule+0x1094/0x16a0<br /> preempt_schedule_irq+0x88/0x170<br /> arm64_preempt_schedule_irq+0xf0/0x18c<br /> el1_irq+0xe8/0x180<br /> perf_event_exec+0x4d8/0x56c<br /> setup_new_exec+0x204/0x400<br /> load_elf_binary+0x72c/0x18c0<br /> search_binary_handler+0x13c/0x420<br /> load_script+0x500/0x6c4<br /> search_binary_handler+0x13c/0x420<br /> exec_binprm+0x118/0x654<br /> __do_execve_file+0x77c/0xba4<br /> __arm64_compat_sys_execve+0x98/0xac<br /> el0_svc_common+0x1f8/0x5e0<br /> el0_svc_compat_handler+0x84/0xb0<br /> el0_svc_compat+0x10/0x50<br /> <br /> The buggy address belongs to the variable:<br /> barrier_pkt+0x10/0x40<br /> <br /> Memory state around the buggy address:<br /> ffffffd05b7d0f00: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00<br /> ffffffd05b7d0f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> &gt;ffffffd05b7d1000: 00 00 00 00 00 00 fa fa fa fa fa fa 00 00 00 03<br /> ^<br /> ffffffd05b7d1080: fa fa fa fa 00 02 fa fa fa fa fa fa 03 fa fa fa<br /> ffffffd05b7d1100: fa fa fa fa 00 00 00 00 05 fa fa fa fa fa fa fa<br /> ==================================================================

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wl1251: Fix possible buffer overflow in wl1251_cmd_scan<br /> <br /> Function wl1251_cmd_scan calls memcpy without checking the length.<br /> Harden by checking the length is within the maximum allowed size.