Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Handle pairing of E-switch via uplink un/load APIs<br /> <br /> In case user switch a device from switchdev mode to legacy mode, mlx5<br /> first unpair the E-switch and afterwards unload the uplink vport.<br /> From the other hand, in case user remove or reload a device, mlx5<br /> first unload the uplink vport and afterwards unpair the E-switch.<br /> <br /> The latter is causing a bug[1], hence, handle pairing of E-switch as<br /> part of uplink un/load APIs.<br /> <br /> [1]<br /> In case VF_LAG is used, every tc fdb flow is duplicated to the peer<br /> esw. However, the original esw keeps a pointer to this duplicated<br /> flow, not the peer esw.<br /> e.g.: if user create tc fdb flow over esw0, the flow is duplicated<br /> over esw1, in FW/HW, but in SW, esw0 keeps a pointer to the duplicated<br /> flow.<br /> During module unload while a peer tc fdb flow is still offloaded, in<br /> case the first device to be removed is the peer device (esw1 in the<br /> example above), the peer net-dev is destroyed, and so the mlx5e_priv<br /> is memset to 0.<br /> Afterwards, the peer device is trying to unpair himself from the<br /> original device (esw0 in the example above). Unpair API invoke the<br /> original device to clear peer flow from its eswitch (esw0), but the<br /> peer flow, which is stored over the original eswitch (esw0), is<br /> trying to use the peer mlx5e_priv, which is memset to 0 and result in<br /> bellow kernel-oops.<br /> <br /> [ 157.964081 ] BUG: unable to handle page fault for address: 000000000002ce60<br /> [ 157.964662 ] #PF: supervisor read access in kernel mode<br /> [ 157.965123 ] #PF: error_code(0x0000) - not-present page<br /> [ 157.965582 ] PGD 0 P4D 0<br /> [ 157.965866 ] Oops: 0000 [#1] SMP<br /> [ 157.967670 ] RIP: 0010:mlx5e_tc_del_fdb_flow+0x48/0x460 [mlx5_core]<br /> [ 157.976164 ] Call Trace:<br /> [ 157.976437 ] <br /> [ 157.976690 ] __mlx5e_tc_del_fdb_peer_flow+0xe6/0x100 [mlx5_core]<br /> [ 157.977230 ] mlx5e_tc_clean_fdb_peer_flows+0x67/0x90 [mlx5_core]<br /> [ 157.977767 ] mlx5_esw_offloads_unpair+0x2d/0x1e0 [mlx5_core]<br /> [ 157.984653 ] mlx5_esw_offloads_devcom_event+0xbf/0x130 [mlx5_core]<br /> [ 157.985212 ] mlx5_devcom_send_event+0xa3/0xb0 [mlx5_core]<br /> [ 157.985714 ] esw_offloads_disable+0x5a/0x110 [mlx5_core]<br /> [ 157.986209 ] mlx5_eswitch_disable_locked+0x152/0x170 [mlx5_core]<br /> [ 157.986757 ] mlx5_eswitch_disable+0x51/0x80 [mlx5_core]<br /> [ 157.987248 ] mlx5_unload+0x2a/0xb0 [mlx5_core]<br /> [ 157.987678 ] mlx5_uninit_one+0x5f/0xd0 [mlx5_core]<br /> [ 157.988127 ] remove_one+0x64/0xe0 [mlx5_core]<br /> [ 157.988549 ] pci_device_remove+0x31/0xa0<br /> [ 157.988933 ] device_release_driver_internal+0x18f/0x1f0<br /> [ 157.989402 ] driver_detach+0x3f/0x80<br /> [ 157.989754 ] bus_remove_driver+0x70/0xf0<br /> [ 157.990129 ] pci_unregister_driver+0x34/0x90<br /> [ 157.990537 ] mlx5_cleanup+0xc/0x1c [mlx5_core]<br /> [ 157.990972 ] __x64_sys_delete_module+0x15a/0x250<br /> [ 157.991398 ] ? exit_to_user_mode_prepare+0xea/0x110<br /> [ 157.991840 ] do_syscall_64+0x3d/0x90<br /> [ 157.992198 ] entry_SYSCALL_64_after_hwframe+0x46/0xb0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix deadlock when aborting transaction during relocation with scrub<br /> <br /> Before relocating a block group we pause scrub, then do the relocation and<br /> then unpause scrub. The relocation process requires starting and committing<br /> a transaction, and if we have a failure in the critical section of the<br /> transaction commit path (transaction state &gt;= TRANS_STATE_COMMIT_START),<br /> we will deadlock if there is a paused scrub.<br /> <br /> That results in stack traces like the following:<br /> <br /> [42.479] BTRFS info (device sdc): relocating block group 53876686848 flags metadata|raid6<br /> [42.936] BTRFS warning (device sdc): Skipping commit of aborted transaction.<br /> [42.936] ------------[ cut here ]------------<br /> [42.936] BTRFS: Transaction aborted (error -28)<br /> [42.936] WARNING: CPU: 11 PID: 346822 at fs/btrfs/transaction.c:1977 btrfs_commit_transaction+0xcc8/0xeb0 [btrfs]<br /> [42.936] Modules linked in: dm_flakey dm_mod loop btrfs (...)<br /> [42.936] CPU: 11 PID: 346822 Comm: btrfs Tainted: G W 6.3.0-rc2-btrfs-next-127+ #1<br /> [42.936] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> [42.936] RIP: 0010:btrfs_commit_transaction+0xcc8/0xeb0 [btrfs]<br /> [42.936] Code: ff ff 45 8b (...)<br /> [42.936] RSP: 0018:ffffb58649633b48 EFLAGS: 00010282<br /> [42.936] RAX: 0000000000000000 RBX: ffff8be6ef4d5bd8 RCX: 0000000000000000<br /> [42.936] RDX: 0000000000000002 RSI: ffffffffb35e7782 RDI: 00000000ffffffff<br /> [42.936] RBP: ffff8be6ef4d5c98 R08: 0000000000000000 R09: ffffb586496339e8<br /> [42.936] R10: 0000000000000001 R11: 0000000000000001 R12: ffff8be6d38c7c00<br /> [42.936] R13: 00000000ffffffe4 R14: ffff8be6c268c000 R15: ffff8be6ef4d5cf0<br /> [42.936] FS: 00007f381a82b340(0000) GS:ffff8beddfcc0000(0000) knlGS:0000000000000000<br /> [42.936] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [42.936] CR2: 00007f1e35fb7638 CR3: 0000000117680006 CR4: 0000000000370ee0<br /> [42.936] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [42.936] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [42.936] Call Trace:<br /> [42.936] <br /> [42.936] ? start_transaction+0xcb/0x610 [btrfs]<br /> [42.936] prepare_to_relocate+0x111/0x1a0 [btrfs]<br /> [42.936] relocate_block_group+0x57/0x5d0 [btrfs]<br /> [42.936] ? btrfs_wait_nocow_writers+0x25/0xb0 [btrfs]<br /> [42.936] btrfs_relocate_block_group+0x248/0x3c0 [btrfs]<br /> [42.936] ? __pfx_autoremove_wake_function+0x10/0x10<br /> [42.936] btrfs_relocate_chunk+0x3b/0x150 [btrfs]<br /> [42.936] btrfs_balance+0x8ff/0x11d0 [btrfs]<br /> [42.936] ? __kmem_cache_alloc_node+0x14a/0x410<br /> [42.936] btrfs_ioctl+0x2334/0x32c0 [btrfs]<br /> [42.937] ? mod_objcg_state+0xd2/0x360<br /> [42.937] ? refill_obj_stock+0xb0/0x160<br /> [42.937] ? seq_release+0x25/0x30<br /> [42.937] ? __rseq_handle_notify_resume+0x3b5/0x4b0<br /> [42.937] ? percpu_counter_add_batch+0x2e/0xa0<br /> [42.937] ? __x64_sys_ioctl+0x88/0xc0<br /> [42.937] __x64_sys_ioctl+0x88/0xc0<br /> [42.937] do_syscall_64+0x38/0x90<br /> [42.937] entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> [42.937] RIP: 0033:0x7f381a6ffe9b<br /> [42.937] Code: 00 48 89 44 24 (...)<br /> [42.937] RSP: 002b:00007ffd45ecf060 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> [42.937] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f381a6ffe9b<br /> [42.937] RDX: 00007ffd45ecf150 RSI: 00000000c4009420 RDI: 0000000000000003<br /> [42.937] RBP: 0000000000000003 R08: 0000000000000013 R09: 0000000000000000<br /> [42.937] R10: 00007f381a60c878 R11: 0000000000000246 R12: 00007ffd45ed0423<br /> [42.937] R13: 00007ffd45ecf150 R14: 0000000000000000 R15: 00007ffd45ecf148<br /> [42.937] <br /> [42.937] ---[ end trace 0000000000000000 ]---<br /> [42.937] BTRFS: error (device sdc: state A) in cleanup_transaction:1977: errno=-28 No space left<br /> [59.196] INFO: task btrfs:346772 blocked for more than 120 seconds.<br /> [59.196] Tainted: G W 6.3.0-rc2-btrfs-next-127+ #1<br /> [59.196] "echo 0 &gt; /proc/sys/kernel/hung_<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: ov2740: Fix memleak in ov2740_init_controls()<br /> <br /> There is a kmemleak when testing the media/i2c/ov2740.c with bpf mock<br /> device:<br /> <br /> unreferenced object 0xffff8881090e19e0 (size 16):<br /> comm "51-i2c-ov2740", pid 278, jiffies 4294781584 (age 23.613s)<br /> hex dump (first 16 bytes):<br /> 00 f3 7c 0b 81 88 ff ff 80 75 6a 09 81 88 ff ff ..|......uj.....<br /> backtrace:<br /> [] __kmalloc_node+0x44/0x1b0<br /> [] kvmalloc_node+0x34/0x180<br /> [] v4l2_ctrl_handler_init_class+0x11d/0x180<br /> [videodev]<br /> [] ov2740_probe+0x37d/0x84f [ov2740]<br /> [] i2c_device_probe+0x28d/0x680<br /> [] really_probe+0x17c/0x3f0<br /> [] __driver_probe_device+0xe3/0x170<br /> [] device_driver_attach+0x34/0x80<br /> [] bind_store+0x10b/0x1a0<br /> [] drv_attr_store+0x49/0x70<br /> [] sysfs_kf_write+0x8c/0xb0<br /> [] kernfs_fop_write_iter+0x216/0x2e0<br /> [] vfs_write+0x658/0x810<br /> [] ksys_write+0xd6/0x1b0<br /> [] do_syscall_64+0x38/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> ov2740_init_controls() won&amp;#39;t clean all the allocated resources in fail<br /> path, which may causes the memleaks. Add v4l2_ctrl_handler_free() to<br /> prevent memleak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/qaic: Fix slicing memory leak<br /> <br /> The temporary buffer storing slicing configuration data from user is only<br /> freed on error. This is a memory leak. Free the buffer unconditionally.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix BUG_ON condition in btrfs_cancel_balance<br /> <br /> Pausing and canceling balance can race to interrupt balance lead to BUG_ON<br /> panic in btrfs_cancel_balance. The BUG_ON condition in btrfs_cancel_balance<br /> does not take this race scenario into account.<br /> <br /> However, the race condition has no other side effects. We can fix that.<br /> <br /> Reproducing it with panic trace like this:<br /> <br /> kernel BUG at fs/btrfs/volumes.c:4618!<br /> RIP: 0010:btrfs_cancel_balance+0x5cf/0x6a0<br /> Call Trace:<br /> <br /> ? do_nanosleep+0x60/0x120<br /> ? hrtimer_nanosleep+0xb7/0x1a0<br /> ? sched_core_clone_cookie+0x70/0x70<br /> btrfs_ioctl_balance_ctl+0x55/0x70<br /> btrfs_ioctl+0xa46/0xd20<br /> __x64_sys_ioctl+0x7d/0xa0<br /> do_syscall_64+0x38/0x80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Race scenario as follows:<br /> &gt; mutex_unlock(&amp;fs_info-&gt;balance_mutex);<br /> &gt; --------------------<br /> &gt; .......issue pause and cancel req in another thread<br /> &gt; --------------------<br /> &gt; ret = __btrfs_balance(fs_info);<br /> &gt;<br /> &gt; mutex_lock(&amp;fs_info-&gt;balance_mutex);<br /> &gt; if (ret == -ECANCELED &amp;&amp; atomic_read(&amp;fs_info-&gt;balance_pause_req)) {<br /> &gt; btrfs_info(fs_info, "balance: paused");<br /> &gt; btrfs_exclop_balance(fs_info, BTRFS_EXCLOP_BALANCE_PAUSED);<br /> &gt; }

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Collect command failures data only for known commands<br /> <br /> DEVX can issue a general command, which is not used by mlx5 driver.<br /> In case such command is failed, mlx5 is trying to collect the failure<br /> data, However, mlx5 doesn&amp;#39;t create a storage for this command, since<br /> mlx5 doesn&amp;#39;t use it. This lead to array-index-out-of-bounds error.<br /> <br /> Fix it by checking whether the command is known before collecting the<br /> failure data.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> of/fdt: run soc memory setup when early_init_dt_scan_memory fails<br /> <br /> If memory has been found early_init_dt_scan_memory now returns 1. If<br /> it hasn&amp;#39;t found any memory it will return 0, allowing other memory<br /> setup mechanisms to carry on.<br /> <br /> Previously early_init_dt_scan_memory always returned 0 without<br /> distinguishing between any kind of memory setup being done or not. Any<br /> code path after the early_init_dt_scan memory call in the ramips<br /> plat_mem_setup code wouldn&amp;#39;t be executed anymore. Making<br /> early_init_dt_scan_memory the only way to initialize the memory.<br /> <br /> Some boards, including my mt7621 based Cudy X6 board, depend on memory<br /> initialization being done via the soc_info.mem_detect function<br /> pointer. Those wouldn&amp;#39;t be able to obtain memory and panic the kernel<br /> during early bootup with the message "early_init_dt_alloc_memory_arch:<br /> Failed to allocate 12416 bytes align=0x40".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: marvell: prestera: fix handling IPv4 routes with nhid<br /> <br /> Fix handling IPv4 routes referencing a nexthop via its id by replacing<br /> calls to fib_info_nh() with fib_info_nhc().<br /> <br /> Trying to add an IPv4 route referencing a nextop via nhid:<br /> <br /> $ ip link set up swp5<br /> $ ip a a 10.0.0.1/24 dev swp5<br /> $ ip nexthop add dev swp5 id 20 via 10.0.0.2<br /> $ ip route add 10.0.1.0/24 nhid 20<br /> <br /> triggers warnings when trying to handle the route:<br /> <br /> [ 528.805763] ------------[ cut here ]------------<br /> [ 528.810437] WARNING: CPU: 3 PID: 53 at include/net/nexthop.h:468 __prestera_fi_is_direct+0x2c/0x68 [prestera]<br /> [ 528.820434] Modules linked in: prestera_pci act_gact act_police sch_ingress cls_u32 cls_flower prestera arm64_delta_tn48m_dn_led(O) arm64_delta_tn48m_dn_cpld(O) [last unloaded: prestera_pci]<br /> [ 528.837485] CPU: 3 PID: 53 Comm: kworker/u8:3 Tainted: G O 6.4.5 #1<br /> [ 528.845178] Hardware name: delta,tn48m-dn (DT)<br /> [ 528.849641] Workqueue: prestera_ordered __prestera_router_fib_event_work [prestera]<br /> [ 528.857352] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 528.864347] pc : __prestera_fi_is_direct+0x2c/0x68 [prestera]<br /> [ 528.870135] lr : prestera_k_arb_fib_evt+0xb20/0xd50 [prestera]<br /> [ 528.876007] sp : ffff80000b20bc90<br /> [ 528.879336] x29: ffff80000b20bc90 x28: 0000000000000000 x27: ffff0001374d3a48<br /> [ 528.886510] x26: ffff000105604000 x25: ffff000134af8a28 x24: ffff0001374d3800<br /> [ 528.893683] x23: ffff000101c89148 x22: ffff000101c89000 x21: ffff000101c89200<br /> [ 528.900855] x20: ffff00013641fda0 x19: ffff800009d01088 x18: 0000000000000059<br /> [ 528.908027] x17: 0000000000000277 x16: 0000000000000000 x15: 0000000000000000<br /> [ 528.915198] x14: 0000000000000003 x13: 00000000000fe400 x12: 0000000000000000<br /> [ 528.922371] x11: 0000000000000002 x10: 0000000000000aa0 x9 : ffff8000013d2020<br /> [ 528.929543] x8 : 0000000000000018 x7 : 000000007b1703f8 x6 : 000000001ca72f86<br /> [ 528.936715] x5 : 0000000033399ea7 x4 : 0000000000000000 x3 : ffff0001374d3acc<br /> [ 528.943886] x2 : 0000000000000000 x1 : ffff00010200de00 x0 : ffff000134ae3f80<br /> [ 528.951058] Call trace:<br /> [ 528.953516] __prestera_fi_is_direct+0x2c/0x68 [prestera]<br /> [ 528.958952] __prestera_router_fib_event_work+0x100/0x158 [prestera]<br /> [ 528.965348] process_one_work+0x208/0x488<br /> [ 528.969387] worker_thread+0x4c/0x430<br /> [ 528.973068] kthread+0x120/0x138<br /> [ 528.976313] ret_from_fork+0x10/0x20<br /> [ 528.979909] ---[ end trace 0000000000000000 ]---<br /> [ 528.984998] ------------[ cut here ]------------<br /> [ 528.989645] WARNING: CPU: 3 PID: 53 at include/net/nexthop.h:468 __prestera_fi_is_direct+0x2c/0x68 [prestera]<br /> [ 528.999628] Modules linked in: prestera_pci act_gact act_police sch_ingress cls_u32 cls_flower prestera arm64_delta_tn48m_dn_led(O) arm64_delta_tn48m_dn_cpld(O) [last unloaded: prestera_pci]<br /> [ 529.016676] CPU: 3 PID: 53 Comm: kworker/u8:3 Tainted: G W O 6.4.5 #1<br /> [ 529.024368] Hardware name: delta,tn48m-dn (DT)<br /> [ 529.028830] Workqueue: prestera_ordered __prestera_router_fib_event_work [prestera]<br /> [ 529.036539] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 529.043533] pc : __prestera_fi_is_direct+0x2c/0x68 [prestera]<br /> [ 529.049318] lr : __prestera_k_arb_fc_apply+0x280/0x2f8 [prestera]<br /> [ 529.055452] sp : ffff80000b20bc60<br /> [ 529.058781] x29: ffff80000b20bc60 x28: 0000000000000000 x27: ffff0001374d3a48<br /> [ 529.065953] x26: ffff000105604000 x25: ffff000134af8a28 x24: ffff0001374d3800<br /> [ 529.073126] x23: ffff000101c89148 x22: ffff000101c89148 x21: ffff00013641fda0<br /> [ 529.080299] x20: ffff000101c89000 x19: ffff000101c89020 x18: 0000000000000059<br /> [ 529.087471] x17: 0000000000000277 x16: 0000000000000000 x15: 0000000000000000<br /> [ 529.094642] x14: 0000000000000003 x13: 00000000000fe400 x12: 0000000000000000<br /> [ 529.101814] x11: 0000000000000002 x10: 0000000000000aa0 x9 : ffff8000013cee80<br /> [ 529.108985] x8 : 0000000000000018 x7 : 000000007b1703f8 x6 <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> led: qcom-lpg: Fix sleeping in atomic<br /> <br /> lpg_brighness_set() function can sleep, while led&amp;#39;s brightness_set()<br /> callback must be non-blocking. Change LPG driver to use<br /> brightness_set_blocking() instead.<br /> <br /> BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 0, name: swapper/0<br /> preempt_count: 101, expected: 0<br /> INFO: lockdep is turned off.<br /> CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 6.1.0-rc1-00014-gbe99b089c6fc-dirty #85<br /> Hardware name: Qualcomm Technologies, Inc. DB820c (DT)<br /> Call trace:<br /> dump_backtrace.part.0+0xe4/0xf0<br /> show_stack+0x18/0x40<br /> dump_stack_lvl+0x88/0xb4<br /> dump_stack+0x18/0x34<br /> __might_resched+0x170/0x254<br /> __might_sleep+0x48/0x9c<br /> __mutex_lock+0x4c/0x400<br /> mutex_lock_nested+0x2c/0x40<br /> lpg_brightness_single_set+0x40/0x90<br /> led_set_brightness_nosleep+0x34/0x60<br /> led_heartbeat_function+0x80/0x170<br /> call_timer_fn+0xb8/0x340<br /> __run_timers.part.0+0x20c/0x254<br /> run_timer_softirq+0x3c/0x7c<br /> _stext+0x14c/0x578<br /> ____do_softirq+0x10/0x20<br /> call_on_irq_stack+0x2c/0x5c<br /> do_softirq_own_stack+0x1c/0x30<br /> __irq_exit_rcu+0x164/0x170<br /> irq_exit_rcu+0x10/0x40<br /> el1_interrupt+0x38/0x50<br /> el1h_64_irq_handler+0x18/0x2c<br /> el1h_64_irq+0x64/0x68<br /> cpuidle_enter_state+0xc8/0x380<br /> cpuidle_enter+0x38/0x50<br /> do_idle+0x244/0x2d0<br /> cpu_startup_entry+0x24/0x30<br /> rest_init+0x128/0x1a0<br /> arch_post_acpi_subsys_init+0x0/0x18<br /> start_kernel+0x6f4/0x734<br /> __primary_switched+0xbc/0xc4

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix memory leak when build ntlmssp negotiate blob failed<br /> <br /> There is a memory leak when mount cifs:<br /> unreferenced object 0xffff888166059600 (size 448):<br /> comm "mount.cifs", pid 51391, jiffies 4295596373 (age 330.596s)<br /> hex dump (first 32 bytes):<br /> fe 53 4d 42 40 00 00 00 00 00 00 00 01 00 82 00 .SMB@...........<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] mempool_alloc+0xe1/0x260<br /> [] cifs_small_buf_get+0x24/0x60<br /> [] __smb2_plain_req_init+0x32/0x460<br /> [] SMB2_sess_alloc_buffer+0xa4/0x3f0<br /> [] SMB2_sess_auth_rawntlmssp_negotiate+0xf5/0x480<br /> [] SMB2_sess_setup+0x253/0x410<br /> [] cifs_setup_session+0x18f/0x4c0<br /> [] cifs_get_smb_ses+0xae7/0x13c0<br /> [] mount_get_conns+0x7a/0x730<br /> [] cifs_mount+0x103/0xd10<br /> [] cifs_smb3_do_mount+0x1dd/0xc90<br /> [] smb3_get_tree+0x1d5/0x300<br /> [] vfs_get_tree+0x41/0xf0<br /> [] path_mount+0x9b3/0xdd0<br /> [] __x64_sys_mount+0x190/0x1d0<br /> [] do_syscall_64+0x35/0x80<br /> <br /> When build ntlmssp negotiate blob failed, the session setup request<br /> should be freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: dlm: fix race in lowcomms<br /> <br /> This patch fixes a race between queue_work() in<br /> _dlm_lowcomms_commit_msg() and srcu_read_unlock(). The queue_work() can<br /> take the final reference of a dlm_msg and so msg-&gt;idx can contain<br /> garbage which is signaled by the following warning:<br /> <br /> [ 676.237050] ------------[ cut here ]------------<br /> [ 676.237052] WARNING: CPU: 0 PID: 1060 at include/linux/srcu.h:189 dlm_lowcomms_commit_msg+0x41/0x50<br /> [ 676.238945] Modules linked in: dlm_locktorture torture rpcsec_gss_krb5 intel_rapl_msr intel_rapl_common iTCO_wdt iTCO_vendor_support qxl kvm_intel drm_ttm_helper vmw_vsock_virtio_transport kvm vmw_vsock_virtio_transport_common ttm irqbypass crc32_pclmul joydev crc32c_intel serio_raw drm_kms_helper vsock virtio_scsi virtio_console virtio_balloon snd_pcm drm syscopyarea sysfillrect sysimgblt snd_timer fb_sys_fops i2c_i801 lpc_ich snd i2c_smbus soundcore pcspkr<br /> [ 676.244227] CPU: 0 PID: 1060 Comm: lock_torture_wr Not tainted 5.19.0-rc3+ #1546<br /> [ 676.245216] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014<br /> [ 676.246460] RIP: 0010:dlm_lowcomms_commit_msg+0x41/0x50<br /> [ 676.247132] Code: fe ff ff ff 75 24 48 c7 c6 bd 0f 49 bb 48 c7 c7 38 7c 01 bd e8 00 e7 ca ff 89 de 48 c7 c7 60 78 01 bd e8 42 3d cd ff 5b 5d c3 0b eb d8 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48<br /> [ 676.249253] RSP: 0018:ffffa401c18ffc68 EFLAGS: 00010282<br /> [ 676.249855] RAX: 0000000000000001 RBX: 00000000ffff8b76 RCX: 0000000000000006<br /> [ 676.250713] RDX: 0000000000000000 RSI: ffffffffbccf3a10 RDI: ffffffffbcc7b62e<br /> [ 676.251610] RBP: ffffa401c18ffc70 R08: 0000000000000001 R09: 0000000000000001<br /> [ 676.252481] R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000005<br /> [ 676.253421] R13: ffff8b76786ec370 R14: ffff8b76786ec370 R15: ffff8b76786ec480<br /> [ 676.254257] FS: 0000000000000000(0000) GS:ffff8b7777800000(0000) knlGS:0000000000000000<br /> [ 676.255239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 676.255897] CR2: 00005590205d88b8 CR3: 000000017656c003 CR4: 0000000000770ee0<br /> [ 676.256734] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 676.257567] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 676.258397] PKRU: 55555554<br /> [ 676.258729] Call Trace:<br /> [ 676.259063] <br /> [ 676.259354] dlm_midcomms_commit_mhandle+0xcc/0x110<br /> [ 676.259964] queue_bast+0x8b/0xb0<br /> [ 676.260423] grant_pending_locks+0x166/0x1b0<br /> [ 676.261007] _unlock_lock+0x75/0x90<br /> [ 676.261469] unlock_lock.isra.57+0x62/0xa0<br /> [ 676.262009] dlm_unlock+0x21e/0x330<br /> [ 676.262457] ? lock_torture_stats+0x80/0x80 [dlm_locktorture]<br /> [ 676.263183] torture_unlock+0x5a/0x90 [dlm_locktorture]<br /> [ 676.263815] ? preempt_count_sub+0xba/0x100<br /> [ 676.264361] ? complete+0x1d/0x60<br /> [ 676.264777] lock_torture_writer+0xb8/0x150 [dlm_locktorture]<br /> [ 676.265555] kthread+0x10a/0x130<br /> [ 676.266007] ? kthread_complete_and_exit+0x20/0x20<br /> [ 676.266616] ret_from_fork+0x22/0x30<br /> [ 676.267097] <br /> [ 676.267381] irq event stamp: 9579855<br /> [ 676.267824] hardirqs last enabled at (9579863): [] __up_console_sem+0x58/0x60<br /> [ 676.268896] hardirqs last disabled at (9579872): [] __up_console_sem+0x3d/0x60<br /> [ 676.270008] softirqs last enabled at (9579798): [] __do_softirq+0x349/0x4c7<br /> [ 676.271438] softirqs last disabled at (9579897): [] irq_exit_rcu+0xb0/0xf0<br /> [ 676.272796] ---[ end trace 0000000000000000 ]---<br /> <br /> I reproduced this warning with dlm_locktorture test which is currently<br /> not upstream. However this patch fix the issue by make a additional<br /> refcount between dlm_lowcomms_new_msg() and dlm_lowcomms_commit_msg().<br /> In case of the race the kref_put() in dlm_lowcomms_commit_msg() will be<br /> the final put.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_{ldisc,serdev}: check percpu_init_rwsem() failure<br /> <br /> syzbot is reporting NULL pointer dereference at hci_uart_tty_close() [1],<br /> for rcu_sync_enter() is called without rcu_sync_init() due to<br /> hci_uart_tty_open() ignoring percpu_init_rwsem() failure.<br /> <br /> While we are at it, fix that hci_uart_register_device() ignores<br /> percpu_init_rwsem() failure and hci_uart_unregister_device() does not<br /> call percpu_free_rwsem().