In the Linux kernel, the following vulnerability has been resolved:\n\nNFC: digital: fix possible memory leak in digital_in_send_sdd_req()\n\n'skb' is allocated in digital_in_send_sdd_req(), but not free when\ndigital_in_send_cmd() failed, which will cause memory leak. Fix it\nby freeing 'skb' if digital_in_send_cmd() return failed.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix memory leak in mlx5_core_destroy_cq() error path\n\nPrior to this patch in case mlx5_core_destroy_cq() failed it returns\nwithout completing all destroy operations and that leads to memory leak.\nInstead, complete the destroy flow before return error.\n\nAlso move mlx5_debug_cq_remove() to the beginning of mlx5_core_destroy_cq()\nto be symmetrical with mlx5_core_create_cq().\n\nkmemleak complains on:\n\nunreferenced object 0xc000000038625100 (size 64):\n comm "ethtool", pid 28301, jiffies 4298062946 (age 785.380s)\n hex dump (first 32 bytes):\n 60 01 48 94 00 00 00 c0 b8 05 34 c3 00 00 00 c0 `.H.......4.....\n 02 00 00 00 00 00 00 00 00 db 7d c1 00 00 00 c0 ..........}.....\n backtrace:\n [<000000009e8643cb>] add_res_tree+0xd0/0x270 [mlx5_core]\n [<00000000e7cb8e6c>] mlx5_debug_cq_add+0x5c/0xc0 [mlx5_core]\n [<000000002a12918f>] mlx5_core_create_cq+0x1d0/0x2d0 [mlx5_core]\n [<00000000cef0a696>] mlx5e_create_cq+0x210/0x3f0 [mlx5_core]\n [<000000009c642c26>] mlx5e_open_cq+0xb4/0x130 [mlx5_core]\n [<0000000058dfa578>] mlx5e_ptp_open+0x7f4/0xe10 [mlx5_core]\n [<0000000081839561>] mlx5e_open_channels+0x9cc/0x13e0 [mlx5_core]\n [<0000000009cf05d4>] mlx5e_switch_priv_channels+0xa4/0x230\n[mlx5_core]\n [<0000000042bbedd8>] mlx5e_safe_switch_params+0x14c/0x300\n[mlx5_core]\n [<0000000004bc9db8>] set_pflag_tx_port_ts+0x9c/0x160 [mlx5_core]\n [<00000000a0553443>] mlx5e_set_priv_flags+0xd0/0x1b0 [mlx5_core]\n [<00000000a8f3d84b>] ethnl_set_privflags+0x234/0x2d0\n [<00000000fd27f27c>] genl_family_rcv_msg_doit+0x108/0x1d0\n [<00000000f495e2bb>] genl_family_rcv_msg+0xe4/0x1f0\n [<00000000646c5c2c>] genl_rcv_msg+0x78/0x120\n [<00000000d53e384e>] netlink_rcv_skb+0x74/0x1a0

In the Linux kernel, the following vulnerability has been resolved:\n\niio: adis16475: fix deadlock on frequency set\n\nWith commit 39c024b51b560\n("iio: adis16475: improve sync scale mode handling"), two deadlocks were\nintroduced:\n 1) The call to 'adis_write_reg_16()' was not changed to it's unlocked\n version.\n 2) The lock was not being released on the success path of the function.\n\nThis change fixes both these issues.

In the Linux kernel, the following vulnerability has been resolved:\n\nxhci: Fix command ring pointer corruption while aborting a command\n\nThe command ring pointer is located at [6:63] bits of the command\nring control register (CRCR). All the control bits like command stop,\nabort are located at [0:3] bits. While aborting a command, we read the\nCRCR and set the abort bit and write to the CRCR. The read will always\ngive command ring pointer as all zeros. So we essentially write only\nthe control bits. Since we split the 64 bit write into two 32 bit writes,\nthere is a possibility of xHC command ring stopped before the upper\ndword (all zeros) is written. If that happens, xHC updates the upper\ndword of its internal command ring pointer with all zeros. Next time,\nwhen the command ring is restarted, we see xHC memory access failures.\nFix this issue by only writing to the lower dword of CRCR where all\ncontrol bits are located.

In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/64s: Fix unrecoverable MCE calling async handler from NMI\n\nThe machine check handler is not considered NMI on 64s. The early\nhandler is the true NMI handler, and then it schedules the\nmachine_check_exception handler to run when interrupts are enabled.\n\nThis works fine except the case of an unrecoverable MCE, where the true\nNMI is taken when MSR[RI] is clear, it can not recover, so it calls\nmachine_check_exception directly so something might be done about it.\n\nCalling an async handler from NMI context can result in irq state and\nother things getting corrupted. This can also trigger the BUG at\n arch/powerpc/include/asm/interrupt.h:168\n BUG_ON(!arch_irq_disabled_regs(regs) && !(regs->msr & MSR_EE));\n\nFix this by making an _async version of the handler which is called\nin the normal case, and a NMI version that is called for unrecoverable\ninterrupts.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: iscsi: Fix iscsi_task use after free\n\nCommit d39df158518c ("scsi: iscsi: Have abort handler get ref to conn")\nadded iscsi_get_conn()/iscsi_put_conn() calls during abort handling but\nthen also changed the handling of the case where we detect an already\ncompleted task where we now end up doing a goto to the common put/cleanup\ncode. This results in a iscsi_task use after free, because the common\ncleanup code will do a put on the iscsi_task.\n\nThis reverts the goto and moves the iscsi_get_conn() to after we've checked\nif the iscsi_task is valid.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: fix a potential ttm->sg memory leak\n\nMemory is allocated for ttm->sg by kmalloc in kfd_mem_dmamap_userptr,\nbut isn't freed by kfree in kfd_mem_dmaunmap_userptr. Free it!

In the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: fix NULL deref in fifo_set_limit()\n\nsyzbot reported another NULL deref in fifo_set_limit() [1]\n\nI could repro the issue with :\n\nunshare -n\ntc qd add dev lo root handle 1:0 tbf limit 200000 burst 70000 rate 100Mbit\ntc qd replace dev lo parent 1:0 pfifo_fast\ntc qd change dev lo root handle 1:0 tbf limit 300000 burst 70000 rate 100Mbit\n\npfifo_fast does not have a change() operation.\nMake fifo_set_limit() more robust about this.\n\n[1]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\nPGD 1cf99067 P4D 1cf99067 PUD 7ca49067 PMD 0\nOops: 0010 [#1] PREEMPT SMP KASAN\nCPU: 1 PID: 14443 Comm: syz-executor959 Not tainted 5.15.0-rc3-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nRIP: 0010:0x0\nCode: Unable to access opcode bytes at RIP 0xffffffffffffffd6.\nRSP: 0018:ffffc9000e2f7310 EFLAGS: 00010246\nRAX: dffffc0000000000 RBX: ffffffff8d6ecc00 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: ffff888024c27910 RDI: ffff888071e34000\nRBP: ffff888071e34000 R08: 0000000000000001 R09: ffffffff8fcfb947\nR10: 0000000000000001 R11: 0000000000000000 R12: ffff888024c27910\nR13: ffff888071e34018 R14: 0000000000000000 R15: ffff88801ef74800\nFS: 00007f321d897700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffffffffffffd6 CR3: 00000000722c3000 CR4: 00000000003506e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n fifo_set_limit net/sched/sch_fifo.c:242 [inline]\n fifo_set_limit+0x198/0x210 net/sched/sch_fifo.c:227\n tbf_change+0x6ec/0x16d0 net/sched/sch_tbf.c:418\n qdisc_change net/sched/sch_api.c:1332 [inline]\n tc_modify_qdisc+0xd9a/0x1a60 net/sched/sch_api.c:1634\n rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5572\n netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504\n netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]\n netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1340\n netlink_sendmsg+0x86d/0xdb0 net/netlink/af_netlink.c:1929\n sock_sendmsg_nosec net/socket.c:704 [inline]\n sock_sendmsg+0xcf/0x120 net/socket.c:724\n ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409\n ___sys_sendmsg+0xf3/0x170 net/socket.c:2463\n __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae

In the Linux kernel, the following vulnerability has been resolved:\n\nlibbpf: Fix memory leak in strset\n\nFree struct strset itself, not just its internal parts.

In the Linux kernel, the following vulnerability has been resolved:\n\nphy: mdio: fix memory leak\n\nSyzbot reported memory leak in MDIO bus interface, the problem was in\nwrong state logic.\n\nMDIOBUS_ALLOCATED indicates 2 states:\n 1. Bus is only allocated\n 2. Bus allocated and __mdiobus_register() fails, but\n device_register() was called\n\nIn case of device_register() has been called we should call put_device()\nto correctly free the memory allocated for this device, but mdiobus_free()\ncalls just kfree(dev) in case of MDIOBUS_ALLOCATED state\n\nTo avoid this behaviour we need to set bus->state to MDIOBUS_UNREGISTERED\n_before_ calling device_register(), because put_device() should be\ncalled even in case of device_register() failure.

In the Linux kernel, the following vulnerability has been resolved:\n\niwlwifi: mvm: Fix possible NULL dereference\n\nIn __iwl_mvm_remove_time_event() check that 'te_data->vif' is NULL\nbefore dereferencing it.

In the Linux kernel, the following vulnerability has been resolved:\n\nipack: ipoctal: fix module reference leak\n\nA reference to the carrier module was taken on every open but was only\nreleased once when the final reference to the tty struct was dropped.\n\nFix this by taking the module reference and initialising the tty driver\ndata when installing the tty.

In the Linux kernel, the following vulnerability has been resolved:\n\nipack: ipoctal: fix stack information leak\n\nThe tty driver name is used also after registering the driver and must\nspecifically not be allocated on the stack to avoid leaking information\nto user space (or triggering an oops).\n\nDrivers should not try to encode topology information in the tty device\nname but this one snuck in through staging without anyone noticing and\nanother driver has since copied this malpractice.\n\nFixing the ABI is a separate issue, but this at least plugs the security\nhole.

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/hfi1: Fix kernel pointer leak\n\nPointers should be printed with %p or %px rather than cast to 'unsigned\nlong long' and printed with %llx. Change %llx to %p to print the secured\npointer.

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/cma: Ensure rdma_addr_cancel() happens before issuing more requests\n\nThe FSM can run in a circle allowing rdma_resolve_ip() to be called twice\non the same id_priv. While this cannot happen without going through the\nwork, it violates the invariant that the same address resolution\nbackground request cannot be active twice.\n\n CPU 1 CPU 2\n\nrdma_resolve_addr():\n RDMA_CM_IDLE -> RDMA_CM_ADDR_QUERY\n rdma_resolve_ip(addr_handler) #1\n\n process_one_req(): for #1\n addr_handler():\n RDMA_CM_ADDR_QUERY -> RDMA_CM_ADDR_BOUND\n mutex_unlock(&id_priv->handler_mutex);\n [.. handler still running ..]\n\nrdma_resolve_addr():\n RDMA_CM_ADDR_BOUND -> RDMA_CM_ADDR_QUERY\n rdma_resolve_ip(addr_handler)\n !! two requests are now on the req_list\n\nrdma_destroy_id():\n destroy_id_handler_unlock():\n _destroy_id():\n cma_cancel_operation():\n rdma_addr_cancel()\n\n // process_one_req() self removes it\n spin_lock_bh(&lock);\n cancel_delayed_work(&req->work);\n if (!list_empty(&req->list)) == true\n\n ! rdma_addr_cancel() returns after process_on_req #1 is done\n\n kfree(id_priv)\n\n process_one_req(): for #2\n addr_handler():\n mutex_lock(&id_priv->handler_mutex);\n !! Use after free on id_priv\n\nrdma_addr_cancel() expects there to be one req on the list and only\ncancels the first one. The self-removal behavior of the work only happens\nafter the handler has returned. This yields a situations where the\nreq_list can have two reqs for the same "handle" but rdma_addr_cancel()\nonly cancels the first one.\n\nThe second req remains active beyond rdma_destroy_id() and will\nuse-after-free id_priv once it inevitably triggers.\n\nFix this by remembering if the id_priv has called rdma_resolve_ip() and\nalways cancel before calling it again. This ensures the req_list never\ngets more than one item in it and doesn't cost anything in the normal flow\nthat never uses this strange error path.

In the Linux kernel, the following vulnerability has been resolved:\n\nblktrace: Fix uaf in blk_trace access after removing by sysfs\n\nThere is an use-after-free problem triggered by following process:\n\n P1(sda) P2(sdb)\n echo 0 > /sys/block/sdb/trace/enable\n blk_trace_remove_queue\n synchronize_rcu\n blk_trace_free\n relay_close\nrcu_read_lock\n__blk_add_trace\n trace_note_tsk\n (Iterate running_trace_list)\n relay_close_buf\n relay_destroy_buf\n kfree(buf)\n trace_note(sdb's bt)\n relay_reserve\n buf->offset <- nullptr deference (use-after-free) !!!\nrcu_read_unlock\n\n[ 502.714379] BUG: kernel NULL pointer dereference, address:\n0000000000000010\n[ 502.715260] #PF: supervisor read access in kernel mode\n[ 502.715903] #PF: error_code(0x0000) - not-present page\n[ 502.716546] PGD 103984067 P4D 103984067 PUD 17592b067 PMD 0\n[ 502.717252] Oops: 0000 [#1] SMP\n[ 502.720308] RIP: 0010:trace_note.isra.0+0x86/0x360\n[ 502.732872] Call Trace:\n[ 502.733193] __blk_add_trace.cold+0x137/0x1a3\n[ 502.733734] blk_add_trace_rq+0x7b/0xd0\n[ 502.734207] blk_add_trace_rq_issue+0x54/0xa0\n[ 502.734755] blk_mq_start_request+0xde/0x1b0\n[ 502.735287] scsi_queue_rq+0x528/0x1140\n...\n[ 502.742704] sg_new_write.isra.0+0x16e/0x3e0\n[ 502.747501] sg_ioctl+0x466/0x1100\n\nReproduce method:\n ioctl(/dev/sda, BLKTRACESETUP, blk_user_trace_setup[buf_size=127])\n ioctl(/dev/sda, BLKTRACESTART)\n ioctl(/dev/sdb, BLKTRACESETUP, blk_user_trace_setup[buf_size=127])\n ioctl(/dev/sdb, BLKTRACESTART)\n\n echo 0 > /sys/block/sdb/trace/enable &\n // Add delay(mdelay/msleep) before kernel enters blk_trace_free()\n\n ioctl$SG_IO(/dev/sda, SG_IO, ...)\n // Enters trace_note_tsk() after blk_trace_free() returned\n // Use mdelay in rcu region rather than msleep(which may schedule out)\n\nRemove blk_trace from running_list before calling blk_trace_free() by\nsysfs if blk_trace is at Blktrace_running state.

In the Linux kernel, the following vulnerability has been resolved:\n\nnexthop: Fix memory leaks in nexthop notification chain listeners\n\nsyzkaller discovered memory leaks [1] that can be reduced to the\nfollowing commands:\n\n # ip nexthop add id 1 blackhole\n # devlink dev reload pci/0000:06:00.0\n\nAs part of the reload flow, mlxsw will unregister its netdevs and then\nunregister from the nexthop notification chain. Before unregistering\nfrom the notification chain, mlxsw will receive delete notifications for\nnexthop objects using netdevs registered by mlxsw or their uppers. mlxsw\nwill not receive notifications for nexthops using netdevs that are not\ndismantled as part of the reload flow. For example, the blackhole\nnexthop above that internally uses the loopback netdev as its nexthop\ndevice.\n\nOne way to fix this problem is to have listeners flush their nexthop\ntables after unregistering from the notification chain. This is\nerror-prone as evident by this patch and also not symmetric with the\nregistration path where a listener receives a dump of all the existing\nnexthops.\n\nTherefore, fix this problem by replaying delete notifications for the\nlistener being unregistered. This is symmetric to the registration path\nand also consistent with the netdev notification chain.\n\nThe above means that unregister_nexthop_notifier(), like\nregister_nexthop_notifier(), will have to take RTNL in order to iterate\nover the existing nexthops and that any callers of the function cannot\nhold RTNL. This is true for mlxsw and netdevsim, but not for the VXLAN\ndriver. To avoid a deadlock, change the latter to unregister its nexthop\nlistener without holding RTNL, making it symmetric to the registration\npath.\n\n[1]\nunreferenced object 0xffff88806173d600 (size 512):\n comm "syz-executor.0", pid 1290, jiffies 4295583142 (age 143.507s)\n hex dump (first 32 bytes):\n 41 9d 1e 60 80 88 ff ff 08 d6 73 61 80 88 ff ff A..`......sa....\n 08 d6 73 61 80 88 ff ff 01 00 00 00 00 00 00 00 ..sa............\n backtrace:\n [<ffffffff81a6b576>] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline]\n [<ffffffff81a6b576>] slab_post_alloc_hook+0x96/0x490 mm/slab.h:522\n [<ffffffff81a716d3>] slab_alloc_node mm/slub.c:3206 [inline]\n [<ffffffff81a716d3>] slab_alloc mm/slub.c:3214 [inline]\n [<ffffffff81a716d3>] kmem_cache_alloc_trace+0x163/0x370 mm/slub.c:3231\n [<ffffffff82e8681a>] kmalloc include/linux/slab.h:591 [inline]\n [<ffffffff82e8681a>] kzalloc include/linux/slab.h:721 [inline]\n [<ffffffff82e8681a>] mlxsw_sp_nexthop_obj_group_create drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:4918 [inline]\n [<ffffffff82e8681a>] mlxsw_sp_nexthop_obj_new drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:5054 [inline]\n [<ffffffff82e8681a>] mlxsw_sp_nexthop_obj_event+0x59a/0x2910 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:5239\n [<ffffffff813ef67d>] notifier_call_chain+0xbd/0x210 kernel/notifier.c:83\n [<ffffffff813f0662>] blocking_notifier_call_chain kernel/notifier.c:318 [inline]\n [<ffffffff813f0662>] blocking_notifier_call_chain+0x72/0xa0 kernel/notifier.c:306\n [<ffffffff8384b9c6>] call_nexthop_notifiers+0x156/0x310 net/ipv4/nexthop.c:244\n [<ffffffff83852bd8>] insert_nexthop net/ipv4/nexthop.c:2336 [inline]\n [<ffffffff83852bd8>] nexthop_add net/ipv4/nexthop.c:2644 [inline]\n [<ffffffff83852bd8>] rtm_new_nexthop+0x14e8/0x4d10 net/ipv4/nexthop.c:2913\n [<ffffffff833e9a78>] rtnetlink_rcv_msg+0x448/0xbf0 net/core/rtnetlink.c:5572\n [<ffffffff83608703>] netlink_rcv_skb+0x173/0x480 net/netlink/af_netlink.c:2504\n [<ffffffff833de032>] rtnetlink_rcv+0x22/0x30 net/core/rtnetlink.c:5590\n [<ffffffff836069de>] netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]\n [<ffffffff836069de>] netlink_unicast+0x5ae/0x7f0 net/netlink/af_netlink.c:1340\n [<ffffffff83607501>] netlink_sendmsg+0x8e1/0xe30 net/netlink/af_netlink.c:1929\n [<ffffffff832fde84>] sock_sendmsg_nosec net/socket.c:704 [inline]\n [<ffffffff832fde84>] sock_sendmsg net/socket.c:724 [inline]\n [<ffffffff832fde84>] ____sys_sendmsg+0x874/0x9f0 net/socket.c:2409\n [<ffffffff83304a44>] ___sys_sendmsg+0x104/0x170 net/socket.c:2463\n [<ffffffff83304c01>] __sys_sendmsg+0x111/0x1f0 net/socket.c:2492\n [<ffffffff83304d5d>] __do_sys_sendmsg net/socket.c:2501 [inline]\n [<ffffffff83304d5d>] __se_sys_sendmsg net/socket.c:2499 [inline]\n [<ffffffff83304d5d>] __x64_sys_sendmsg+0x7d/0xc0 net/socket.c:2499

In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: ensure tx skbs always have the MPTCP ext\n\nDue to signed/unsigned comparison, the expression:\n\n info->size_goal - skb->len > 0\n\nevaluates to true when the size goal is smaller than the\nskb size. That results in lack of tx cache refill, so that\nthe skb allocated by the core TCP code lacks the required\nMPTCP skb extensions.\n\nDue to the above, syzbot is able to trigger the following WARN_ON():\n\nWARNING: CPU: 1 PID: 810 at net/mptcp/protocol.c:1366 mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366\nModules linked in:\nCPU: 1 PID: 810 Comm: syz-executor.4 Not tainted 5.14.0-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nRIP: 0010:mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366\nCode: 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 <0f> 0b 41 bd ea ff ff ff e9 6f f4 ff ff 4c 89 e7 e8 b9 8e d2 f8 e9\nRSP: 0018:ffffc9000531f6a0 EFLAGS: 00010216\nRAX: 000000000000697f RBX: 0000000000000000 RCX: ffffc90012107000\nRDX: 0000000000040000 RSI: ffffffff88eac9e2 RDI: 0000000000000003\nRBP: ffff888078b15780 R08: 0000000000000000 R09: 0000000000000000\nR10: ffffffff88eac017 R11: 0000000000000000 R12: ffff88801de0a280\nR13: 0000000000006b58 R14: ffff888066278280 R15: ffff88803c2fe9c0\nFS: 00007fd9f866e700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007faebcb2f718 CR3: 00000000267cb000 CR4: 00000000001506e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n __mptcp_push_pending+0x1fb/0x6b0 net/mptcp/protocol.c:1547\n mptcp_release_cb+0xfe/0x210 net/mptcp/protocol.c:3003\n release_sock+0xb4/0x1b0 net/core/sock.c:3206\n sk_stream_wait_memory+0x604/0xed0 net/core/stream.c:145\n mptcp_sendmsg+0xc39/0x1bc0 net/mptcp/protocol.c:1749\n inet6_sendmsg+0x99/0xe0 net/ipv6/af_inet6.c:643\n sock_sendmsg_nosec net/socket.c:704 [inline]\n sock_sendmsg+0xcf/0x120 net/socket.c:724\n sock_write_iter+0x2a0/0x3e0 net/socket.c:1057\n call_write_iter include/linux/fs.h:2163 [inline]\n new_sync_write+0x40b/0x640 fs/read_write.c:507\n vfs_write+0x7cf/0xae0 fs/read_write.c:594\n ksys_write+0x1ee/0x250 fs/read_write.c:647\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x4665f9\nCode: 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 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fd9f866e188 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 000000000056c038 RCX: 00000000004665f9\nRDX: 00000000000e7b78 RSI: 0000000020000000 RDI: 0000000000000003\nRBP: 00000000004bfcc4 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 000000000056c038\nR13: 0000000000a9fb1f R14: 00007fd9f866e300 R15: 0000000000022000\n\nFix the issue rewriting the relevant expression to avoid\nsign-related problems - note: size_goal is always >= 0.\n\nAdditionally, ensure that the skb in the tx cache always carries\nthe relevant extension.

In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio-net: fix pages leaking when building skb in big mode\n\nWe try to use build_skb() if we had sufficient tailroom. But we forget\nto release the unused pages chained via private in big mode which will\nleak pages. Fixing this by release the pages after building the skb in\nbig mode.

In the Linux kernel, the following vulnerability has been resolved:\n\nafs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server\n\nAFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, and\nLinux's afs client switches between them when talking to a non-YFS server\nif the read size, the file position or the sum of the two have the upper 32\nbits set of the 64-bit value.\n\nThis is a problem, however, since the file position and length fields of\nFS.FetchData are *signed* 32-bit values.\n\nFix this by capturing the capability bits obtained from the fileserver when\nit's sent an FS.GetCapabilities RPC, rather than just discarding them, and\nthen picking out the VICED_CAPABILITY_64BITFILES flag. This can then be\nused to decide whether to use FS.FetchData or FS.FetchData64 - and also\nFS.StoreData or FS.StoreData64 - rather than using upper_32_bits() to\nswitch on the parameter values.\n\nThis capabilities flag could also be used to limit the maximum size of the\nfile, but all servers must be checked for that.\n\nNote that the issue does not exist with FS.StoreData - that uses *unsigned*\n32-bit values. It's also not a problem with Auristor servers as its\nYFS.FetchData64 op uses unsigned 64-bit values.\n\nThis can be tested by cloning a git repo through an OpenAFS client to an\nOpenAFS server and then doing "git status" on it from a Linux afs\nclient[1]. Provided the clone has a pack file that's in the 2G-4G range,\nthe git status will show errors like:\n\n error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index\n error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index\n\nThis can be observed in the server's FileLog with something like the\nfollowing appearing:\n\nSun Aug 29 19:31:39 2021 SRXAFS_FetchData, Fid = 2303380852.491776.3263114, Host 192.168.11.201:7001, Id 1001\nSun Aug 29 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001\nSun Aug 29 19:31:39 2021 FetchData_RXStyle: Pos 18446744071815340032, Len 3154\nSun Aug 29 19:31:39 2021 FetchData_RXStyle: file size 2400758866\n...\nSun Aug 29 19:31:40 2021 SRXAFS_FetchData returns 5\n\nNote the file position of 18446744071815340032. This is the requested file\nposition sign-extended.

In the Linux kernel, the following vulnerability has been resolved:\n\nafs: Fix page leak\n\nThere's a loop in afs_extend_writeback() that adds extra pages to a write\nwe want to make to improve the efficiency of the writeback by making it\nlarger. This loop stops, however, if we hit a page we can't write back\nfrom immediately, but it doesn't get rid of the page ref we speculatively\nacquired.\n\nThis was caused by the removal of the cleanup loop when the code switched\nfrom using find_get_pages_contig() to xarray scanning as the latter only\ngets a single page at a time, not a batch.\n\nFix this by putting the page on a ref on an early break from the loop.\nUnfortunately, we can't just add that page to the pagevec we're employing\nas we'll go through that and add those pages to the RPC call.\n\nThis was found by the generic/074 test. It leaks ~4GiB of RAM each time it\nis run - which can be observed with "top".

In the Linux kernel, the following vulnerability has been resolved:\n\nnexthop: Fix division by zero while replacing a resilient group\n\nThe resilient nexthop group torture tests in fib_nexthop.sh exposed a\npossible division by zero while replacing a resilient group [1]. The\ndivision by zero occurs when the data path sees a resilient nexthop\ngroup with zero buckets.\n\nThe tests replace a resilient nexthop group in a loop while traffic is\nforwarded through it. The tests do not specify the number of buckets\nwhile performing the replacement, resulting in the kernel allocating a\nstub resilient table (i.e, 'struct nh_res_table') with zero buckets.\n\nThis table should never be visible to the data path, but the old nexthop\ngroup (i.e., 'oldg') might still be used by the data path when the stub\ntable is assigned to it.\n\nFix this by only assigning the stub table to the old nexthop group after\nmaking sure the group is no longer used by the data path.\n\nTested with fib_nexthops.sh:\n\nTests passed: 222\nTests failed: 0\n\n[1]\n divide error: 0000 [#1] PREEMPT SMP KASAN\n CPU: 0 PID: 1850 Comm: ping Not tainted 5.14.0-custom-10271-ga86eb53057fe #1107\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014\n RIP: 0010:nexthop_select_path+0x2d2/0x1a80\n[...]\n Call Trace:\n fib_select_multipath+0x79b/0x1530\n fib_select_path+0x8fb/0x1c10\n ip_route_output_key_hash_rcu+0x1198/0x2da0\n ip_route_output_key_hash+0x190/0x340\n ip_route_output_flow+0x21/0x120\n raw_sendmsg+0x91d/0x2e10\n inet_sendmsg+0x9e/0xe0\n __sys_sendto+0x23d/0x360\n __x64_sys_sendto+0xe1/0x1b0\n do_syscall_64+0x35/0x80\n entry_SYSCALL_64_after_hwframe+0x44/0xae

In the Linux kernel, the following vulnerability has been resolved:\n\nstaging: greybus: uart: fix tty use after free\n\nUser space can hold a tty open indefinitely and tty drivers must not\nrelease the underlying structures until the last user is gone.\n\nSwitch to using the tty-port reference counter to manage the life time\nof the greybus tty state to avoid use after free after a disconnect.

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

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

In the Linux kernel, the following vulnerability has been resolved:\n\nnfs: fix acl memory leak of posix_acl_create()\n\nWhen looking into another nfs xfstests report, I found acl and\ndefault_acl in nfs3_proc_create() and nfs3_proc_mknod() error\npaths are possibly leaked. Fix them in advance.

In the Linux kernel, the following vulnerability has been resolved:\n\narch_topology: Avoid use-after-free for scale_freq_data\n\nCurrently topology_scale_freq_tick() (which gets called from\nscheduler_tick()) may end up using a pointer to "struct\nscale_freq_data", which was previously cleared by\ntopology_clear_scale_freq_source(), as there is no protection in place\nhere. The users of topology_clear_scale_freq_source() though needs a\nguarantee that the previously cleared scale_freq_data isn't used\nanymore, so they can free the related resources.\n\nSince topology_scale_freq_tick() is called from scheduler tick, we don't\nwant to add locking in there. Use the RCU update mechanism instead\n(which is already used by the scheduler's utilization update path) to\nguarantee race free updates here.\n\nsynchronize_rcu() makes sure that all RCU critical sections that started\nbefore it is called, will finish before it returns. And so the callers\nof topology_clear_scale_freq_source() don't need to worry about their\ncallback getting called anymore.

In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/bpf: Fix detecting BPF atomic instructions\n\nCommit 91c960b0056672 ("bpf: Rename BPF_XADD and prepare to encode other\natomics in .imm") converted BPF_XADD to BPF_ATOMIC and added a way to\ndistinguish instructions based on the immediate field. Existing JIT\nimplementations were updated to check for the immediate field and to\nreject programs utilizing anything more than BPF_ADD (such as BPF_FETCH)\nin the immediate field.\n\nHowever, the check added to powerpc64 JIT did not look at the correct\nBPF instruction. Due to this, such programs would be accepted and\nincorrectly JIT'ed resulting in soft lockups, as seen with the atomic\nbounds test. Fix this by looking at the correct immediate value.

In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix NULL dereference in nfs3svc_encode_getaclres\n\nIn error cases the dentry may be NULL.\n\nBefore 20798dfe249a, the encoder also checked dentry and\nd_really_is_positive(dentry), but that looks like overkill to me--zero\nstatus should be enough to guarantee a positive dentry.\n\nThis isn't the first time we've seen an error-case NULL dereference\nhidden in the initialization of a local variable in an xdr encoder. But\nI went back through the other recent rewrites and didn't spot any\nsimilar bugs.

In the Linux kernel, the following vulnerability has been resolved:\n\nmemory: fsl_ifc: fix leak of IO mapping on probe failure\n\nOn probe error the driver should unmap the IO memory. Smatch reports:\n\n drivers/memory/fsl_ifc.c:298 fsl_ifc_ctrl_probe() warn: 'fsl_ifc_ctrl_dev->gregs' not released on lines: 298.

In the Linux kernel, the following vulnerability has been resolved:\n\nmemory: fsl_ifc: fix leak of private memory on probe failure\n\nOn probe error the driver should free the memory allocated for private\nstructure. Fix this by using resource-managed allocation.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: Fix dereference of null pointer flow\n\nIn the case where chain->flags & NFT_CHAIN_HW_OFFLOAD is false then\nnft_flow_rule_create is not called and flow is NULL. The subsequent\nerror handling execution via label err_destroy_flow_rule will lead\nto a null pointer dereference on flow when calling nft_flow_rule_destroy.\nSince the error path to err_destroy_flow_rule has to cater for null\nand non-null flows, only call nft_flow_rule_destroy if flow is non-null\nto fix this issue.\n\nAddresses-Coverity: ("Explicity null dereference")

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: fix uninit-value in caif_seqpkt_sendmsg\n\nWhen nr_segs equal to zero in iovec_from_user, the object\nmsg->msg_iter.iov is uninit stack memory in caif_seqpkt_sendmsg\nwhich is defined in ___sys_sendmsg. So we cann't just judge\nmsg->msg_iter.iov->base directlly. We can use nr_segs to judge\nmsg in caif_seqpkt_sendmsg whether has data buffers.\n\n=====================================================\nBUG: KMSAN: uninit-value in caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542\nCall Trace:\n __dump_stack lib/dump_stack.c:77 [inline]\n dump_stack+0x1c9/0x220 lib/dump_stack.c:118\n kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118\n __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215\n caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542\n sock_sendmsg_nosec net/socket.c:652 [inline]\n sock_sendmsg net/socket.c:672 [inline]\n ____sys_sendmsg+0x12b6/0x1350 net/socket.c:2343\n ___sys_sendmsg net/socket.c:2397 [inline]\n __sys_sendmmsg+0x808/0xc90 net/socket.c:2480\n __compat_sys_sendmmsg net/compat.c:656 [inline]

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: sched: fix memory leak in tcindex_partial_destroy_work\n\nSyzbot reported memory leak in tcindex_set_parms(). The problem was in\nnon-freed perfect hash in tcindex_partial_destroy_work().\n\nIn tcindex_set_parms() new tcindex_data is allocated and some fields from\nold one are copied to new one, but not the perfect hash. Since\ntcindex_partial_destroy_work() is the destroy function for old\ntcindex_data, we need to free perfect hash to avoid memory leak.

In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: fix memleak in io_init_wq_offload()\n\nI got memory leak report when doing fuzz test:\n\nBUG: memory leak\nunreferenced object 0xffff888107310a80 (size 96):\ncomm "syz-executor.6", pid 4610, jiffies 4295140240 (age 20.135s)\nhex dump (first 32 bytes):\n01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........\nbacktrace:\n[<000000001974933b>] kmalloc include/linux/slab.h:591 [inline]\n[<000000001974933b>] kzalloc include/linux/slab.h:721 [inline]\n[<000000001974933b>] io_init_wq_offload fs/io_uring.c:7920 [inline]\n[<000000001974933b>] io_uring_alloc_task_context+0x466/0x640 fs/io_uring.c:7955\n[<0000000039d0800d>] __io_uring_add_tctx_node+0x256/0x360 fs/io_uring.c:9016\n[<000000008482e78c>] io_uring_add_tctx_node fs/io_uring.c:9052 [inline]\n[<000000008482e78c>] __do_sys_io_uring_enter fs/io_uring.c:9354 [inline]\n[<000000008482e78c>] __se_sys_io_uring_enter fs/io_uring.c:9301 [inline]\n[<000000008482e78c>] __x64_sys_io_uring_enter+0xabc/0xc20 fs/io_uring.c:9301\n[<00000000b875f18f>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n[<00000000b875f18f>] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80\n[<000000006b0a8484>] entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nCPU0 CPU1\nio_uring_enter io_uring_enter\nio_uring_add_tctx_node io_uring_add_tctx_node\n__io_uring_add_tctx_node __io_uring_add_tctx_node\nio_uring_alloc_task_context io_uring_alloc_task_context\nio_init_wq_offload io_init_wq_offload\nhash = kzalloc hash = kzalloc\nctx->hash_map = hash ctx->hash_map = hash <- one of the hash is leaked\n\nWhen calling io_uring_enter() in parallel, the 'hash_map' will be leaked,\nadd uring_lock to protect 'hash_map'.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: Fix NULL dereference on XCOPY completion\n\nCPU affinity control added with commit 39ae3edda325 ("scsi: target: core:\nMake completion affinity configurable") makes target_complete_cmd() queue\nwork on a CPU based on se_tpg->se_tpg_wwn->cmd_compl_affinity state.\n\nLIO's EXTENDED COPY worker is a special case in that read/write cmds are\ndispatched using the global xcopy_pt_tpg, which carries a NULL se_tpg_wwn\npointer following initialization in target_xcopy_setup_pt().\n\nThe NULL xcopy_pt_tpg->se_tpg_wwn pointer is dereferenced on completion of\nany EXTENDED COPY initiated read/write cmds. E.g using the libiscsi\nSCSI.ExtendedCopy.Simple test:\n\n BUG: kernel NULL pointer dereference, address: 00000000000001a8\n RIP: 0010:target_complete_cmd+0x9d/0x130 [target_core_mod]\n Call Trace:\n fd_execute_rw+0x148/0x42a [target_core_file]\n ? __dynamic_pr_debug+0xa7/0xe0\n ? target_check_reservation+0x5b/0x940 [target_core_mod]\n __target_execute_cmd+0x1e/0x90 [target_core_mod]\n transport_generic_new_cmd+0x17c/0x330 [target_core_mod]\n target_xcopy_issue_pt_cmd+0x9/0x60 [target_core_mod]\n target_xcopy_read_source.isra.7+0x10b/0x1b0 [target_core_mod]\n ? target_check_fua+0x40/0x40 [target_core_mod]\n ? transport_complete_task_attr+0x130/0x130 [target_core_mod]\n target_xcopy_do_work+0x61f/0xc00 [target_core_mod]\n\nThis fix makes target_complete_cmd() queue work on se_cmd->cpuid if\nse_tpg_wwn is NULL.

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: ngene: Fix out-of-bounds bug in ngene_command_config_free_buf()\n\nFix an 11-year old bug in ngene_command_config_free_buf() while\naddressing the following warnings caught with -Warray-bounds:\n\narch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds]\narch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds]\n\nThe problem is that the original code is trying to copy 6 bytes of\ndata into a one-byte size member _config_ of the wrong structue\nFW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a\nlegitimate compiler warning because memcpy() overruns the length\nof &com.cmd.ConfigureBuffers.config. It seems that the right\nstructure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains\n6 more members apart from the header _hdr_. Also, the name of\nthe function ngene_command_config_free_buf() suggests that the actual\nintention is to ConfigureFreeBuffers, instead of ConfigureBuffers\n(which takes place in the function ngene_command_config_buf(), above).\n\nFix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS\ninto new struct config, and use &com.cmd.ConfigureFreeBuffers.config as\nthe destination address, instead of &com.cmd.ConfigureBuffers.config,\nwhen calling memcpy().\n\nThis also helps with the ongoing efforts to globally enable\n-Warray-bounds and get us closer to being able to tighten the\nFORTIFY_SOURCE routines on memcpy().

In the Linux kernel, the following vulnerability has been resolved:\n\nspi: bcm2835: Fix out-of-bounds access with more than 4 slaves\n\nCommit 571e31fa60b3 ("spi: bcm2835: Cache CS register value for\n->prepare_message()") limited the number of slaves to 3 at compile-time.\nThe limitation was necessitated by a statically-sized array prepare_cs[]\nin the driver private data which contains a per-slave register value.\n\nThe commit sought to enforce the limitation at run-time by setting the\ncontroller's num_chipselect to 3: Slaves with a higher chipselect are\nrejected by spi_add_device().\n\nHowever the commit neglected that num_chipselect only limits the number\nof *native* chipselects. If GPIO chipselects are specified in the\ndevice tree for more than 3 slaves, num_chipselect is silently raised by\nof_spi_get_gpio_numbers() and the result are out-of-bounds accesses to\nthe statically-sized array prepare_cs[].\n\nAs a bandaid fix which is backportable to stable, raise the number of\nallowed slaves to 24 (which "ought to be enough for anybody"), enforce\nthe limitation on slave ->setup and revert num_chipselect to 3 (which is\nthe number of native chipselects supported by the controller).\nAn upcoming for-next commit will allow an arbitrary number of slaves.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: misc: brcmstb-usb-pinmap: check return value after calling platform_get_resource()\n\nIt will cause null-ptr-deref if platform_get_resource() returns NULL,\nwe need check the return value.

In the Linux kernel, the following vulnerability has been resolved:\n\nbus: mhi: pci_generic: Fix possible use-after-free in mhi_pci_remove()\n\nThis driver's remove path calls del_timer(). However, that function\ndoes not wait until the timer handler finishes. This means that the\ntimer handler may still be running after the driver's remove function\nhas finished, which would result in a use-after-free.\n\nFix by calling del_timer_sync(), which makes sure the timer handler\nhas finished, and unable to re-schedule itself.

In the Linux kernel, the following vulnerability has been resolved:\n\nftrace: Do not blindly read the ip address in ftrace_bug()\n\nIt was reported that a bug on arm64 caused a bad ip address to be used for\nupdating into a nop in ftrace_init(), but the error path (rightfully)\nreturned -EINVAL and not -EFAULT, as the bug caused more than one error to\noccur. But because -EINVAL was returned, the ftrace_bug() tried to report\nwhat was at the location of the ip address, and read it directly. This\ncaused the machine to panic, as the ip was not pointing to a valid memory\naddress.\n\nInstead, read the ip address with copy_from_kernel_nofault() to safely\naccess the memory, and if it faults, report that the address faulted,\notherwise report what was in that location.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdnsp: Fix deadlock issue in cdnsp_thread_irq_handler\n\nPatch fixes the following critical issue caused by deadlock which has been\ndetected during testing NCM class:\n\nsmp: csd: Detected non-responsive CSD lock (#1) on CPU#0\nsmp: csd: CSD lock (#1) unresponsive.\n....\nRIP: 0010:native_queued_spin_lock_slowpath+0x61/0x1d0\nRSP: 0018:ffffbc494011cde0 EFLAGS: 00000002\nRAX: 0000000000000101 RBX: ffff9ee8116b4a68 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9ee8116b4658\nRBP: ffffbc494011cde0 R08: 0000000000000001 R09: 0000000000000000\nR10: ffff9ee8116b4670 R11: 0000000000000000 R12: ffff9ee8116b4658\nR13: ffff9ee8116b4670 R14: 0000000000000246 R15: ffff9ee8116b4658\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f7bcc41a830 CR3: 000000007a612003 CR4: 00000000001706e0\nCall Trace:\n <IRQ>\n do_raw_spin_lock+0xc0/0xd0\n _raw_spin_lock_irqsave+0x95/0xa0\n cdnsp_gadget_ep_queue.cold+0x88/0x107 [cdnsp_udc_pci]\n usb_ep_queue+0x35/0x110\n eth_start_xmit+0x220/0x3d0 [u_ether]\n ncm_tx_timeout+0x34/0x40 [usb_f_ncm]\n ? ncm_free_inst+0x50/0x50 [usb_f_ncm]\n __hrtimer_run_queues+0xac/0x440\n hrtimer_run_softirq+0x8c/0xb0\n __do_softirq+0xcf/0x428\n asm_call_irq_on_stack+0x12/0x20\n </IRQ>\n do_softirq_own_stack+0x61/0x70\n irq_exit_rcu+0xc1/0xd0\n sysvec_apic_timer_interrupt+0x52/0xb0\n asm_sysvec_apic_timer_interrupt+0x12/0x20\nRIP: 0010:do_raw_spin_trylock+0x18/0x40\nRSP: 0018:ffffbc494138bda8 EFLAGS: 00000246\nRAX: 0000000000000000 RBX: ffff9ee8116b4658 RCX: 0000000000000000\nRDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9ee8116b4658\nRBP: ffffbc494138bda8 R08: 0000000000000001 R09: 0000000000000000\nR10: ffff9ee8116b4670 R11: 0000000000000000 R12: ffff9ee8116b4658\nR13: ffff9ee8116b4670 R14: ffff9ee7b5c73d80 R15: ffff9ee8116b4000\n _raw_spin_lock+0x3d/0x70\n ? cdnsp_thread_irq_handler.cold+0x32/0x112c [cdnsp_udc_pci]\n cdnsp_thread_irq_handler.cold+0x32/0x112c [cdnsp_udc_pci]\n ? cdnsp_remove_request+0x1f0/0x1f0 [cdnsp_udc_pci]\n ? cdnsp_thread_irq_handler+0x5/0xa0 [cdnsp_udc_pci]\n ? irq_thread+0xa0/0x1c0\n irq_thread_fn+0x28/0x60\n irq_thread+0x105/0x1c0\n ? __kthread_parkme+0x42/0x90\n ? irq_forced_thread_fn+0x90/0x90\n ? wake_threads_waitq+0x30/0x30\n ? irq_thread_check_affinity+0xe0/0xe0\n kthread+0x12a/0x160\n ? kthread_park+0x90/0x90\n ret_from_fork+0x22/0x30\n\nThe root cause of issue is spin_lock/spin_unlock instruction instead\nspin_lock_irqsave/spin_lock_irqrestore in cdnsp_thread_irq_handler\nfunction.

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/ipoib: Fix warning caused by destroying non-initial netns\n\nAfter the commit 5ce2dced8e95 ("RDMA/ipoib: Set rtnl_link_ops for ipoib\ninterfaces"), if the IPoIB device is moved to non-initial netns,\ndestroying that netns lets the device vanish instead of moving it back to\nthe initial netns, This is happening because default_device_exit() skips\nthe interfaces due to having rtnl_link_ops set.\n\nSteps to reporoduce:\n ip netns add foo\n ip link set mlx5_ib0 netns foo\n ip netns delete foo\n\nWARNING: CPU: 1 PID: 704 at net/core/dev.c:11435 netdev_exit+0x3f/0x50\nModules linked in: xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT\nnf_reject_ipv4 nft_compat nft_counter nft_chain_nat nf_nat nf_conntrack\nnf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink tun d\n fuse\nCPU: 1 PID: 704 Comm: kworker/u64:3 Tainted: G S W 5.13.0-rc1+ #1\nHardware name: Dell Inc. PowerEdge R630/02C2CP, BIOS 2.1.5 04/11/2016\nWorkqueue: netns cleanup_net\nRIP: 0010:netdev_exit+0x3f/0x50\nCode: 48 8b bb 30 01 00 00 e8 ef 81 b1 ff 48 81 fb c0 3a 54 a1 74 13 48\n8b 83 90 00 00 00 48 81 c3 90 00 00 00 48 39 d8 75 02 5b c3 <0f> 0b 5b\nc3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 0f 1f 44 00\nRSP: 0018:ffffb297079d7e08 EFLAGS: 00010206\nRAX: ffff8eb542c00040 RBX: ffff8eb541333150 RCX: 000000008010000d\nRDX: 000000008010000e RSI: 000000008010000d RDI: ffff8eb440042c00\nRBP: ffffb297079d7e48 R08: 0000000000000001 R09: ffffffff9fdeac00\nR10: ffff8eb5003be000 R11: 0000000000000001 R12: ffffffffa1545620\nR13: ffffffffa1545628 R14: 0000000000000000 R15: ffffffffa1543b20\nFS: 0000000000000000(0000) GS:ffff8ed37fa00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00005601b5f4c2e8 CR3: 0000001fc8c10002 CR4: 00000000003706e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n ops_exit_list.isra.9+0x36/0x70\n cleanup_net+0x234/0x390\n process_one_work+0x1cb/0x360\n ? process_one_work+0x360/0x360\n worker_thread+0x30/0x370\n ? process_one_work+0x360/0x360\n kthread+0x116/0x130\n ? kthread_park+0x80/0x80\n ret_from_fork+0x22/0x30\n\nTo avoid the above warning and later on the kernel panic that could happen\non shutdown due to a NULL pointer dereference, make sure to set the\nnetns_refund flag that was introduced by commit 3a5ca857079e ("can: dev:\nMove device back to init netns on owning netns delete") to properly\nrestore the IPoIB interfaces to the initial netns.

In the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Fix a potential NULL dereference in nfs_get_client()\n\nNone of the callers are expecting NULL returns from nfs_get_client() so\nthis code will lead to an Oops. It's better to return an error\npointer. I expect that this is dead code so hopefully no one is\naffected.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm/memory-failure: make sure wait for page writeback in memory_failure\n\nOur syzkaller trigger the "BUG_ON(!list_empty(&inode->i_wb_list))" in\nclear_inode:\n\n kernel BUG at fs/inode.c:519!\n Internal error: Oops - BUG: 0 [#1] SMP\n Modules linked in:\n Process syz-executor.0 (pid: 249, stack limit = 0x00000000a12409d7)\n CPU: 1 PID: 249 Comm: syz-executor.0 Not tainted 4.19.95\n Hardware name: linux,dummy-virt (DT)\n pstate: 80000005 (Nzcv daif -PAN -UAO)\n pc : clear_inode+0x280/0x2a8\n lr : clear_inode+0x280/0x2a8\n Call trace:\n clear_inode+0x280/0x2a8\n ext4_clear_inode+0x38/0xe8\n ext4_free_inode+0x130/0xc68\n ext4_evict_inode+0xb20/0xcb8\n evict+0x1a8/0x3c0\n iput+0x344/0x460\n do_unlinkat+0x260/0x410\n __arm64_sys_unlinkat+0x6c/0xc0\n el0_svc_common+0xdc/0x3b0\n el0_svc_handler+0xf8/0x160\n el0_svc+0x10/0x218\n Kernel panic - not syncing: Fatal exception\n\nA crash dump of this problem show that someone called __munlock_pagevec\nto clear page LRU without lock_page: do_mmap -> mmap_region -> do_munmap\n-> munlock_vma_pages_range -> __munlock_pagevec.\n\nAs a result memory_failure will call identify_page_state without\nwait_on_page_writeback. And after truncate_error_page clear the mapping\nof this page. end_page_writeback won't call sb_clear_inode_writeback to\nclear inode->i_wb_list. That will trigger BUG_ON in clear_inode!\n\nFix it by checking PageWriteback too to help determine should we skip\nwait_on_page_writeback.

In the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: Avoid WARN_ON timing related checks\n\nThe soft/batadv interface for a queued OGM can be changed during the time\nthe OGM was queued for transmission and when the OGM is actually\ntransmitted by the worker.\n\nBut WARN_ON must be used to denote kernel bugs and not to print simple\nwarnings. A warning can simply be printed using pr_warn.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipv4: fix memory leak in netlbl_cipsov4_add_std\n\nReported by syzkaller:\nBUG: memory leak\nunreferenced object 0xffff888105df7000 (size 64):\ncomm "syz-executor842", pid 360, jiffies 4294824824 (age 22.546s)\nhex dump (first 32 bytes):\n00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\nbacktrace:\n[<00000000e67ed558>] kmalloc include/linux/slab.h:590 [inline]\n[<00000000e67ed558>] kzalloc include/linux/slab.h:720 [inline]\n[<00000000e67ed558>] netlbl_cipsov4_add_std net/netlabel/netlabel_cipso_v4.c:145 [inline]\n[<00000000e67ed558>] netlbl_cipsov4_add+0x390/0x2340 net/netlabel/netlabel_cipso_v4.c:416\n[<0000000006040154>] genl_family_rcv_msg_doit.isra.0+0x20e/0x320 net/netlink/genetlink.c:739\n[<00000000204d7a1c>] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]\n[<00000000204d7a1c>] genl_rcv_msg+0x2bf/0x4f0 net/netlink/genetlink.c:800\n[<00000000c0d6a995>] netlink_rcv_skb+0x134/0x3d0 net/netlink/af_netlink.c:2504\n[<00000000d78b9d2c>] genl_rcv+0x24/0x40 net/netlink/genetlink.c:811\n[<000000009733081b>] netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]\n[<000000009733081b>] netlink_unicast+0x4a0/0x6a0 net/netlink/af_netlink.c:1340\n[<00000000d5fd43b8>] netlink_sendmsg+0x789/0xc70 net/netlink/af_netlink.c:1929\n[<000000000a2d1e40>] sock_sendmsg_nosec net/socket.c:654 [inline]\n[<000000000a2d1e40>] sock_sendmsg+0x139/0x170 net/socket.c:674\n[<00000000321d1969>] ____sys_sendmsg+0x658/0x7d0 net/socket.c:2350\n[<00000000964e16bc>] ___sys_sendmsg+0xf8/0x170 net/socket.c:2404\n[<000000001615e288>] __sys_sendmsg+0xd3/0x190 net/socket.c:2433\n[<000000004ee8b6a5>] do_syscall_64+0x37/0x90 arch/x86/entry/common.c:47\n[<00000000171c7cee>] entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nThe memory of doi_def->map.std pointing is allocated in\nnetlbl_cipsov4_add_std, but no place has freed it. It should be\nfreed in cipso_v4_doi_free which frees the cipso DOI resource.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: synproxy: Fix out of bounds when parsing TCP options\n\nThe TCP option parser in synproxy (synproxy_parse_options) could read\none byte out of bounds. When the length is 1, the execution flow gets\ninto the loop, reads one byte of the opcode, and if the opcode is\nneither TCPOPT_EOL nor TCPOPT_NOP, it reads one more byte, which exceeds\nthe length of 1.\n\nThis fix is inspired by commit 9609dad263f8 ("ipv4: tcp_input: fix stack\nout of bounds when parsing TCP options.").\n\nv2 changes:\n\nAdded an early return when length < 0 to avoid calling\nskb_header_pointer with negative length.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hamradio: fix memory leak in mkiss_close\n\nMy local syzbot instance hit memory leak in\nmkiss_open()[1]. The problem was in missing\nfree_netdev() in mkiss_close().\n\nIn mkiss_open() netdevice is allocated and then\nregistered, but in mkiss_close() netdevice was\nonly unregistered, but not freed.\n\nFail log:\n\nBUG: memory leak\nunreferenced object 0xffff8880281ba000 (size 4096):\n comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s)\n hex dump (first 32 bytes):\n 61 78 30 00 00 00 00 00 00 00 00 00 00 00 00 00 ax0.............\n 00 27 fa 2a 80 88 ff ff 00 00 00 00 00 00 00 00 .'.*............\n backtrace:\n [<ffffffff81a27201>] kvmalloc_node+0x61/0xf0\n [<ffffffff8706e7e8>] alloc_netdev_mqs+0x98/0xe80\n [<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1]\n [<ffffffff842355db>] tty_ldisc_open+0x9b/0x110\n [<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670\n [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440\n [<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200\n [<ffffffff8911263a>] do_syscall_64+0x3a/0xb0\n [<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nBUG: memory leak\nunreferenced object 0xffff8880141a9a00 (size 96):\n comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s)\n hex dump (first 32 bytes):\n e8 a2 1b 28 80 88 ff ff e8 a2 1b 28 80 88 ff ff ...(.......(....\n 98 92 9c aa b0 40 02 00 00 00 00 00 00 00 00 00 .....@..........\n backtrace:\n [<ffffffff8709f68b>] __hw_addr_create_ex+0x5b/0x310\n [<ffffffff8709fb38>] __hw_addr_add_ex+0x1f8/0x2b0\n [<ffffffff870a0c7b>] dev_addr_init+0x10b/0x1f0\n [<ffffffff8706e88b>] alloc_netdev_mqs+0x13b/0xe80\n [<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1]\n [<ffffffff842355db>] tty_ldisc_open+0x9b/0x110\n [<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670\n [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440\n [<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200\n [<ffffffff8911263a>] do_syscall_64+0x3a/0xb0\n [<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nBUG: memory leak\nunreferenced object 0xffff8880219bfc00 (size 512):\n comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s)\n hex dump (first 32 bytes):\n 00 a0 1b 28 80 88 ff ff 80 8f b1 8d ff ff ff ff ...(............\n 80 8f b1 8d ff ff ff ff 00 00 00 00 00 00 00 00 ................\n backtrace:\n [<ffffffff81a27201>] kvmalloc_node+0x61/0xf0\n [<ffffffff8706eec7>] alloc_netdev_mqs+0x777/0xe80\n [<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1]\n [<ffffffff842355db>] tty_ldisc_open+0x9b/0x110\n [<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670\n [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440\n [<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200\n [<ffffffff8911263a>] do_syscall_64+0x3a/0xb0\n [<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nBUG: memory leak\nunreferenced object 0xffff888029b2b200 (size 256):\n comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s)\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace:\n [<ffffffff81a27201>] kvmalloc_node+0x61/0xf0\n [<ffffffff8706f062>] alloc_netdev_mqs+0x912/0xe80\n [<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1]\n [<ffffffff842355db>] tty_ldisc_open+0x9b/0x110\n [<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670\n [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440\n [<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200\n [<ffffffff8911263a>] do_syscall_64+0x3a/0xb0\n [<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ethernet: fix potential use-after-free in ec_bhf_remove\n\nstatic void ec_bhf_remove(struct pci_dev *dev)\n{\n...\n struct ec_bhf_priv *priv = netdev_priv(net_dev);\n\n unregister_netdev(net_dev);\n free_netdev(net_dev);\n\n pci_iounmap(dev, priv->dma_io);\n pci_iounmap(dev, priv->io);\n...\n}\n\npriv is netdev private data, but it is used\nafter free_netdev(). It can cause use-after-free when accessing priv\npointer. So, fix it by moving free_netdev() after pci_iounmap()\ncalls.

In the Linux kernel, the following vulnerability has been resolved:\n\ncan: j1939: fix Use-after-Free, hold skb ref while in use\n\nThis patch fixes a Use-after-Free found by the syzbot.\n\nThe problem is that a skb is taken from the per-session skb queue,\nwithout incrementing the ref count. This leads to a Use-after-Free if\nthe skb is taken concurrently from the session queue due to a CTS.

In the Linux kernel, the following vulnerability has been resolved:\n\nmac80211: fix deadlock in AP/VLAN handling\n\nSyzbot reports that when you have AP_VLAN interfaces that are up\nand close the AP interface they belong to, we get a deadlock. No\nsurprise - since we dev_close() them with the wiphy mutex held,\nwhich goes back into the netdev notifier in cfg80211 and tries to\nacquire the wiphy mutex there.\n\nTo fix this, we need to do two things:\n 1) prevent changing iftype while AP_VLANs are up, we can't\n easily fix this case since cfg80211 already calls us with\n the wiphy mutex held, but change_interface() is relatively\n rare in drivers anyway, so changing iftype isn't used much\n (and userspace has to fall back to down/change/up anyway)\n 2) pull the dev_close() loop over VLANs out of the wiphy mutex\n section in the normal stop case

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: kTLS, Fix crash in RX resync flow\n\nFor the TLS RX resync flow, we maintain a list of TLS contexts\nthat require some attention, to communicate their resync information\nto the HW.\nHere we fix list corruptions, by protecting the entries against\nmovements coming from resync_handle_seq_match(), until their resync\nhandling in napi is fully completed.

In the Linux kernel, the following vulnerability has been resolved:\n\nhugetlb, userfaultfd: fix reservation restore on userfaultfd error\n\nCurrently in the is_continue case in hugetlb_mcopy_atomic_pte(), if we\nbail out using "goto out_release_unlock;" in the cases where idx >=\nsize, or !huge_pte_none(), the code will detect that new_pagecache_page\n== false, and so call restore_reserve_on_error(). In this case I see\nrestore_reserve_on_error() delete the reservation, and the following\ncall to remove_inode_hugepages() will increment h->resv_hugepages\ncausing a 100% reproducible leak.\n\nWe should treat the is_continue case similar to adding a page into the\npagecache and set new_pagecache_page to true, to indicate that there is\nno reservation to restore on the error path, and we need not call\nrestore_reserve_on_error(). Rename new_pagecache_page to\npage_in_pagecache to make that clear.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Fix use-after-free in lpfc_unreg_rpi() routine\n\nAn error is detected with the following report when unloading the driver:\n "KASAN: use-after-free in lpfc_unreg_rpi+0x1b1b"\n\nThe NLP_REG_LOGIN_SEND nlp_flag is set in lpfc_reg_fab_ctrl_node(), but the\nflag is not cleared upon completion of the login.\n\nThis allows a second call to lpfc_unreg_rpi() to proceed with nlp_rpi set\nto LPFC_RPI_ALLOW_ERROR. This results in a use after free access when used\nas an rpi_ids array index.\n\nFix by clearing the NLP_REG_LOGIN_SEND nlp_flag in\nlpfc_mbx_cmpl_fc_reg_login().

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/core: Set send and receive CQ before forwarding to the driver\n\nPreset both receive and send CQ pointers prior to call to the drivers and\noverwrite it later again till the mlx4 is going to be changed do not\noverwrite ibqp properties.\n\nThis change is needed for mlx5, because in case of QP creation failure, it\nwill go to the path of QP destroy which relies on proper CQ pointers.\n\n BUG: KASAN: use-after-free in create_qp.cold+0x164/0x16e [mlx5_ib]\n Write of size 8 at addr ffff8880064c55c0 by task a.out/246\n\n CPU: 0 PID: 246 Comm: a.out Not tainted 5.15.0+ #291\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n Call Trace:\n dump_stack_lvl+0x45/0x59\n print_address_description.constprop.0+0x1f/0x140\n kasan_report.cold+0x83/0xdf\n create_qp.cold+0x164/0x16e [mlx5_ib]\n mlx5_ib_create_qp+0x358/0x28a0 [mlx5_ib]\n create_qp.part.0+0x45b/0x6a0 [ib_core]\n ib_create_qp_user+0x97/0x150 [ib_core]\n ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x92c/0x1250 [ib_uverbs]\n ib_uverbs_cmd_verbs+0x1c38/0x3150 [ib_uverbs]\n ib_uverbs_ioctl+0x169/0x260 [ib_uverbs]\n __x64_sys_ioctl+0x866/0x14d0\n do_syscall_64+0x3d/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\n Allocated by task 246:\n kasan_save_stack+0x1b/0x40\n __kasan_kmalloc+0xa4/0xd0\n create_qp.part.0+0x92/0x6a0 [ib_core]\n ib_create_qp_user+0x97/0x150 [ib_core]\n ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x92c/0x1250 [ib_uverbs]\n ib_uverbs_cmd_verbs+0x1c38/0x3150 [ib_uverbs]\n ib_uverbs_ioctl+0x169/0x260 [ib_uverbs]\n __x64_sys_ioctl+0x866/0x14d0\n do_syscall_64+0x3d/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\n Freed by task 246:\n kasan_save_stack+0x1b/0x40\n kasan_set_track+0x1c/0x30\n kasan_set_free_info+0x20/0x30\n __kasan_slab_free+0x10c/0x150\n slab_free_freelist_hook+0xb4/0x1b0\n kfree+0xe7/0x2a0\n create_qp.part.0+0x52b/0x6a0 [ib_core]\n ib_create_qp_user+0x97/0x150 [ib_core]\n ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x92c/0x1250 [ib_uverbs]\n ib_uverbs_cmd_verbs+0x1c38/0x3150 [ib_uverbs]\n ib_uverbs_ioctl+0x169/0x260 [ib_uverbs]\n __x64_sys_ioctl+0x866/0x14d0\n do_syscall_64+0x3d/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae

In the Linux kernel, the following vulnerability has been resolved:\n\ncfg80211: call cfg80211_stop_ap when switch from P2P_GO type\n\nIf the userspace tools switch from NL80211_IFTYPE_P2P_GO to\nNL80211_IFTYPE_ADHOC via send_msg(NL80211_CMD_SET_INTERFACE), it\ndoes not call the cleanup cfg80211_stop_ap(), this leads to the\ninitialization of in-use data. For example, this path re-init the\nsdata->assigned_chanctx_list while it is still an element of\nassigned_vifs list, and makes that linked list corrupt.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix memory ordering between normal and ordered work functions\n\nOrdered work functions aren't guaranteed to be handled by the same thread\nwhich executed the normal work functions. The only way execution between\nnormal/ordered functions is synchronized is via the WORK_DONE_BIT,\nunfortunately the used bitops don't guarantee any ordering whatsoever.\n\nThis manifested as seemingly inexplicable crashes on ARM64, where\nasync_chunk::inode is seen as non-null in async_cow_submit which causes\nsubmit_compressed_extents to be called and crash occurs because\nasync_chunk::inode suddenly became NULL. The call trace was similar to:\n\n pc : submit_compressed_extents+0x38/0x3d0\n lr : async_cow_submit+0x50/0xd0\n sp : ffff800015d4bc20\n\n <registers omitted for brevity>\n\n Call trace:\n submit_compressed_extents+0x38/0x3d0\n async_cow_submit+0x50/0xd0\n run_ordered_work+0xc8/0x280\n btrfs_work_helper+0x98/0x250\n process_one_work+0x1f0/0x4ac\n worker_thread+0x188/0x504\n kthread+0x110/0x114\n ret_from_fork+0x10/0x18\n\nFix this by adding respective barrier calls which ensure that all\naccesses preceding setting of WORK_DONE_BIT are strictly ordered before\nsetting the flag. At the same time add a read barrier after reading of\nWORK_DONE_BIT in run_ordered_work which ensures all subsequent loads\nwould be strictly ordered after reading the bit. This in turn ensures\nare all accesses before WORK_DONE_BIT are going to be strictly ordered\nbefore any access that can occur in ordered_func.

In the Linux kernel, the following vulnerability has been resolved:\n\ni40e: Fix NULL ptr dereference on VSI filter sync\n\nRemove the reason of null pointer dereference in sync VSI filters.\nAdded new I40E_VSI_RELEASING flag to signalize deleting and releasing\nof VSI resources to sync this thread with sync filters subtask.\nWithout this patch it is possible to start update the VSI filter list\nafter VSI is removed, that's causing a kernel oops.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: SHAMPO, Fix invalid WQ linked list unlink\n\nWhen all the strides in a WQE have been consumed, the WQE is unlinked\nfrom the WQ linked list (mlx5_wq_ll_pop()). For SHAMPO, it is possible\nto receive CQEs with 0 consumed strides for the same WQE even after the\nWQE is fully consumed and unlinked. This triggers an additional unlink\nfor the same wqe which corrupts the linked list.\n\nFix this scenario by accepting 0 sized consumed strides without\nunlinking the WQE again.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: scrub: handle RST lookup error correctly\n\n[BUG]\nWhen running btrfs/060 with forced RST feature, it would crash the\nfollowing ASSERT() inside scrub_read_endio():\n\n ASSERT(sector_nr < stripe->nr_sectors);\n\nBefore that, we would have tree dump from\nbtrfs_get_raid_extent_offset(), as we failed to find the RST entry for\nthe range.\n\n[CAUSE]\nInside scrub_submit_extent_sector_read() every time we allocated a new\nbbio we immediately called btrfs_map_block() to make sure there was some\nRST range covering the scrub target.\n\nBut if btrfs_map_block() fails, we immediately call endio for the bbio,\nwhile the bbio is newly allocated, it's completely empty.\n\nThen inside scrub_read_endio(), we go through the bvecs to find\nthe sector number (as bi_sector is no longer reliable if the bio is\nsubmitted to lower layers).\n\nAnd since the bio is empty, such bvecs iteration would not find any\nsector matching the sector, and return sector_nr == stripe->nr_sectors,\ntriggering the ASSERT().\n\n[FIX]\nInstead of calling btrfs_map_block() after allocating a new bbio, call\nbtrfs_map_block() first.\n\nSince our only objective of calling btrfs_map_block() is only to update\nstripe_len, there is really no need to do that after btrfs_alloc_bio().\n\nThis new timing would avoid the problem of handling empty bbio\ncompletely, and in fact fixes a possible race window for the old code,\nwhere if the submission thread is the only owner of the pending_io, the\nscrub would never finish (since we didn't decrease the pending_io\ncounter).\n\nAlthough the root cause of RST lookup failure still needs to be\naddressed.

In PHP versions 8.1.* before 8.1.28, 8.2.* before 8.2.18, 8.3.* before 8.3.5, when using proc_open() command with array syntax, due to insufficient escaping, if the arguments of the executed command are controlled by a malicious user, the user can supply arguments that would execute arbitrary commands in Windows shell.

Memory safety bugs present in Firefox 130. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 131 and Thunderbird < 131.

Memory safety bugs present in Firefox 130, Firefox ESR 128.2, and Thunderbird 128.2. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 131, Firefox ESR < 128.3, Thunderbird < 128.3, and Thunderbird < 131.

Memory safety bugs present in Firefox 130, Firefox ESR 115.15, Firefox ESR 128.2, and Thunderbird 128.2. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 131, Firefox ESR < 128.3, Firefox ESR < 115.16, Thunderbird < 128.3, and Thunderbird < 131.

A potential memory corruption vulnerability could be triggered if an attacker had the ability to trigger an OOM at a specific moment during JIT compilation. This vulnerability affects Firefox < 131, Firefox ESR < 128.3, Thunderbird < 128.3, and Thunderbird < 131.

A website configured to initiate a specially crafted WebTransport session could crash the Firefox process leading to a denial of service condition. This vulnerability affects Firefox < 131, Firefox ESR < 128.3, Thunderbird < 128.3, and Thunderbird < 131.

By checking the result of calls to `window.open` with specifically set protocol handlers, an attacker could determine if the application which implements that protocol handler is installed. This vulnerability affects Firefox < 131, Firefox ESR < 128.3, Thunderbird < 128.3, and Thunderbird < 131.

A missing delay in directory upload UI could have made it possible for an attacker to trick a user into granting permission via clickjacking. This vulnerability affects Firefox < 131, Firefox ESR < 128.3, Thunderbird < 128.3, and Thunderbird < 131.

It is currently unknown if this issue is exploitable but a condition may arise where the structured clone of certain objects could lead to memory corruption. This vulnerability affects Firefox < 131, Firefox ESR < 128.3, Thunderbird < 128.3, and Thunderbird < 131.

An attacker could, via a specially crafted multipart response, execute arbitrary JavaScript under the `resource://devtools` origin. This could allow them to access cross-origin JSON content. This access is limited to "same site" documents by the Site Isolation feature on desktop clients, but full cross-origin access is possible on Android versions. This vulnerability affects Firefox < 131, Firefox ESR < 128.3, Firefox ESR < 115.16, Thunderbird < 128.3, and Thunderbird < 131.

An attacker could, via a specially crafted multipart response, execute arbitrary JavaScript under the `resource://pdf.js` origin. This could allow them to access cross-origin PDF content. This access is limited to "same site" documents by the Site Isolation feature on desktop clients, but full cross-origin access is possible on Android versions. This vulnerability affects Firefox < 131, Firefox ESR < 128.3, Firefox ESR < 115.16, Thunderbird < 128.3, and Thunderbird < 131.

A compromised content process could have allowed for the arbitrary loading of cross-origin pages. This vulnerability affects Firefox < 131, Firefox ESR < 128.3, Firefox ESR < 115.16, Thunderbird < 128.3, and Thunderbird < 131.

A vulnerability was found in Golang FIPS OpenSSL. This flaw allows a malicious user to randomly cause an uninitialized buffer length variable with a zeroed buffer to be returned in FIPS mode. It may also be possible to force a false positive match between non-equal hashes when comparing a trusted computed hmac sum to an untrusted input sum if an attacker can send a zeroed buffer in place of a pre-computed sum. It is also possible to force a derived key to be all zeros instead of an unpredictable value. This may have follow-on implications for the Go TLS stack.

An attacker could write data to the user's clipboard, bypassing the user prompt, during a certain sequence of navigational events. This vulnerability affects Firefox < 129, Firefox ESR < 128.3, and Thunderbird < 128.3.

CUPS is a standards-based, open-source printing system, and `libcupsfilters` contains the code of the filters of the former `cups-filters` package as library functions to be used for the data format conversion tasks needed in Printer Applications. The `cfGetPrinterAttributes5` function in `libcupsfilters` does not sanitize IPP attributes returned from an IPP server. When these IPP attributes are used, for instance, to generate a PPD file, this can lead to attacker controlled data to be provided to the rest of the CUPS system.

In the Linux kernel, the following vulnerability has been resolved:\n\niwlwifi: mvm: check debugfs_dir ptr before use\n\nWhen "debugfs=off" is used on the kernel command line, iwiwifi's\nmvm module uses an invalid/unchecked debugfs_dir pointer and causes\na BUG:\n\n BUG: kernel NULL pointer dereference, address: 000000000000004f\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 [#1] PREEMPT SMP\n CPU: 1 PID: 503 Comm: modprobe Tainted: G W 5.17.0-rc5 #7\n Hardware name: Dell Inc. Inspiron 15 5510/076F7Y, BIOS 2.4.1 11/05/2021\n RIP: 0010:iwl_mvm_dbgfs_register+0x692/0x700 [iwlmvm]\n Code: 69 a0 be 80 01 00 00 48 c7 c7 50 73 6a a0 e8 95 cf ee e0 48 8b 83 b0 1e 00 00 48 c7 c2 54 73 6a a0 be 64 00 00 00 48 8d 7d 8c <48> 8b 48 50 e8 15 22 07 e1 48 8b 43 28 48 8d 55 8c 48 c7 c7 5f 73\n RSP: 0018:ffffc90000a0ba68 EFLAGS: 00010246\n RAX: ffffffffffffffff RBX: ffff88817d6e3328 RCX: ffff88817d6e3328\n RDX: ffffffffa06a7354 RSI: 0000000000000064 RDI: ffffc90000a0ba6c\n RBP: ffffc90000a0bae0 R08: ffffffff824e4880 R09: ffffffffa069d620\n R10: ffffc90000a0ba00 R11: ffffffffffffffff R12: 0000000000000000\n R13: ffffc90000a0bb28 R14: ffff88817d6e3328 R15: ffff88817d6e3320\n FS: 00007f64dd92d740(0000) GS:ffff88847f640000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000000000000004f CR3: 000000016fc79001 CR4: 0000000000770ee0\n PKRU: 55555554\n Call Trace:\n <TASK>\n ? iwl_mvm_mac_setup_register+0xbdc/0xda0 [iwlmvm]\n iwl_mvm_start_post_nvm+0x71/0x100 [iwlmvm]\n iwl_op_mode_mvm_start+0xab8/0xb30 [iwlmvm]\n _iwl_op_mode_start+0x6f/0xd0 [iwlwifi]\n iwl_opmode_register+0x6a/0xe0 [iwlwifi]\n ? 0xffffffffa0231000\n iwl_mvm_init+0x35/0x1000 [iwlmvm]\n ? 0xffffffffa0231000\n do_one_initcall+0x5a/0x1b0\n ? kmem_cache_alloc+0x1e5/0x2f0\n ? do_init_module+0x1e/0x220\n do_init_module+0x48/0x220\n load_module+0x2602/0x2bc0\n ? __kernel_read+0x145/0x2e0\n ? kernel_read_file+0x229/0x290\n __do_sys_finit_module+0xc5/0x130\n ? __do_sys_finit_module+0xc5/0x130\n __x64_sys_finit_module+0x13/0x20\n do_syscall_64+0x38/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n RIP: 0033:0x7f64dda564dd\n Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 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 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1b 29 0f 00 f7 d8 64 89 01 48\n RSP: 002b:00007ffdba393f88 EFLAGS: 00000246 ORIG_RAX: 0000000000000139\n RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f64dda564dd\n RDX: 0000000000000000 RSI: 00005575399e2ab2 RDI: 0000000000000001\n RBP: 000055753a91c5e0 R08: 0000000000000000 R09: 0000000000000002\n R10: 0000000000000001 R11: 0000000000000246 R12: 00005575399e2ab2\n R13: 000055753a91ceb0 R14: 0000000000000000 R15: 000055753a923018\n </TASK>\n Modules linked in: btintel(+) btmtk bluetooth vfat snd_hda_codec_hdmi fat snd_hda_codec_realtek snd_hda_codec_generic iwlmvm(+) snd_sof_pci_intel_tgl mac80211 snd_sof_intel_hda_common soundwire_intel soundwire_generic_allocation soundwire_cadence soundwire_bus snd_sof_intel_hda snd_sof_pci snd_sof snd_sof_xtensa_dsp snd_soc_hdac_hda snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core btrfs snd_compress snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec raid6_pq iwlwifi snd_hda_core snd_pcm snd_timer snd soundcore cfg80211 intel_ish_ipc(+) thunderbolt rfkill intel_ishtp ucsi_acpi wmi i2c_hid_acpi i2c_hid evdev\n CR2: 000000000000004f\n ---[ end trace 0000000000000000 ]---\n\nCheck the debugfs_dir pointer for an error before using it.\n\n[change to make both conditional]

In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: LAPIC: Also cancel preemption timer during SET_LAPIC\n\nThe below warning is splatting during guest reboot.\n\n ------------[ cut here ]------------\n WARNING: CPU: 0 PID: 1931 at arch/x86/kvm/x86.c:10322 kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm]\n CPU: 0 PID: 1931 Comm: qemu-system-x86 Tainted: G I 5.17.0-rc1+ #5\n RIP: 0010:kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm]\n Call Trace:\n <TASK>\n kvm_vcpu_ioctl+0x279/0x710 [kvm]\n __x64_sys_ioctl+0x83/0xb0\n do_syscall_64+0x3b/0xc0\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n RIP: 0033:0x7fd39797350b\n\nThis can be triggered by not exposing tsc-deadline mode and doing a reboot in\nthe guest. The lapic_shutdown() function which is called in sys_reboot path\nwill not disarm the flying timer, it just masks LVTT. lapic_shutdown() clears\nAPIC state w/ LVT_MASKED and timer-mode bit is 0, this can trigger timer-mode\nswitch between tsc-deadline and oneshot/periodic, which can result in preemption\ntimer be cancelled in apic_update_lvtt(). However, We can't depend on this when\nnot exposing tsc-deadline mode and oneshot/periodic modes emulated by preemption\ntimer. Qemu will synchronise states around reset, let's cancel preemption timer\nunder KVM_SET_LAPIC.

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: ops: Reject out of bounds values in snd_soc_put_volsw()\n\nWe don't currently validate that the values being set are within the range\nwe advertised to userspace as being valid, do so and reject any values\nthat are out of range.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: mpt3sas: Fix use-after-free warning\n\nFix the following use-after-free warning which is observed during\ncontroller reset:\n\nrefcount_t: underflow; use-after-free.\nWARNING: CPU: 23 PID: 5399 at lib/refcount.c:28 refcount_warn_saturate+0xa6/0xf0

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: fix tc flower deletion for VLAN priority Rx steering\n\nTo replicate the issue:-\n\n1) Add 1 flower filter for VLAN Priority based frame steering:-\n$ IFDEVNAME=eth0\n$ tc qdisc add dev $IFDEVNAME ingress\n$ tc qdisc add dev $IFDEVNAME root mqprio num_tc 8 \\\n map 0 1 2 3 4 5 6 7 0 0 0 0 0 0 0 0 \\\n queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0\n$ tc filter add dev $IFDEVNAME parent ffff: protocol 802.1Q \\\n flower vlan_prio 0 hw_tc 0\n\n2) Get the 'pref' id\n$ tc filter show dev $IFDEVNAME ingress\n\n3) Delete a specific tc flower record (say pref 49151)\n$ tc filter del dev $IFDEVNAME parent ffff: pref 49151\n\n>From dmesg, we will observe kernel NULL pointer ooops\n\n[ 197.170464] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[ 197.171367] #PF: supervisor read access in kernel mode\n[ 197.171367] #PF: error_code(0x0000) - not-present page\n[ 197.171367] PGD 0 P4D 0\n[ 197.171367] Oops: 0000 [#1] PREEMPT SMP NOPTI\n\n<snip>\n\n[ 197.171367] RIP: 0010:tc_setup_cls+0x20b/0x4a0 [stmmac]\n\n<snip>\n\n[ 197.171367] Call Trace:\n[ 197.171367] <TASK>\n[ 197.171367] ? __stmmac_disable_all_queues+0xa8/0xe0 [stmmac]\n[ 197.171367] stmmac_setup_tc_block_cb+0x70/0x110 [stmmac]\n[ 197.171367] tc_setup_cb_destroy+0xb3/0x180\n[ 197.171367] fl_hw_destroy_filter+0x94/0xc0 [cls_flower]\n\nThe above issue is due to previous incorrect implementation of\ntc_del_vlan_flow(), shown below, that uses flow_cls_offload_flow_rule()\nto get struct flow_rule *rule which is no longer valid for tc filter\ndelete operation.\n\n struct flow_rule *rule = flow_cls_offload_flow_rule(cls);\n struct flow_dissector *dissector = rule->match.dissector;\n\nSo, to ensure tc_del_vlan_flow() deletes the right VLAN cls record for\nearlier configured RX queue (configured by hw_tc) in tc_add_vlan_flow(),\nthis patch introduces stmmac_rfs_entry as driver-side flow_cls_offload\nrecord for 'RX frame steering' tc flower, currently used for VLAN\npriority. The implementation has taken consideration for future extension\nto include other type RX frame steering such as EtherType based.\n\nv2:\n - Clean up overly extensive backtrace and rewrite git message to better\n explain the kernel NULL pointer issue.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: scsi_debug: Fix type in min_t to avoid stack OOB\n\nChange min_t() to use type "u32" instead of type "int" to avoid stack out\nof bounds. With min_t() type "int" the values get sign extended and the\nlarger value gets used causing stack out of bounds.\n\nBUG: KASAN: stack-out-of-bounds in memcpy include/linux/fortify-string.h:191 [inline]\nBUG: KASAN: stack-out-of-bounds in sg_copy_buffer+0x1de/0x240 lib/scatterlist.c:976\nRead of size 127 at addr ffff888072607128 by task syz-executor.7/18707\n\nCPU: 1 PID: 18707 Comm: syz-executor.7 Not tainted 5.15.0-syzk #1\nHardware name: Red Hat KVM, BIOS 1.13.0-2\nCall Trace:\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106\n print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:256\n __kasan_report mm/kasan/report.c:442 [inline]\n kasan_report.cold.14+0x7d/0x117 mm/kasan/report.c:459\n check_region_inline mm/kasan/generic.c:183 [inline]\n kasan_check_range+0x1a3/0x210 mm/kasan/generic.c:189\n memcpy+0x23/0x60 mm/kasan/shadow.c:65\n memcpy include/linux/fortify-string.h:191 [inline]\n sg_copy_buffer+0x1de/0x240 lib/scatterlist.c:976\n sg_copy_from_buffer+0x33/0x40 lib/scatterlist.c:1000\n fill_from_dev_buffer.part.34+0x82/0x130 drivers/scsi/scsi_debug.c:1162\n fill_from_dev_buffer drivers/scsi/scsi_debug.c:1888 [inline]\n resp_readcap16+0x365/0x3b0 drivers/scsi/scsi_debug.c:1887\n schedule_resp+0x4d8/0x1a70 drivers/scsi/scsi_debug.c:5478\n scsi_debug_queuecommand+0x8c9/0x1ec0 drivers/scsi/scsi_debug.c:7533\n scsi_dispatch_cmd drivers/scsi/scsi_lib.c:1520 [inline]\n scsi_queue_rq+0x16b0/0x2d40 drivers/scsi/scsi_lib.c:1699\n blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1639\n __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325\n blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358\n __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1761\n __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1838\n blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891\n blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474\n blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:62\n sg_common_write.isra.18+0xeb3/0x2000 drivers/scsi/sg.c:836\n sg_new_write.isra.19+0x570/0x8c0 drivers/scsi/sg.c:774\n sg_ioctl_common+0x14d6/0x2710 drivers/scsi/sg.c:939\n sg_ioctl+0xa2/0x180 drivers/scsi/sg.c:1165\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:874 [inline]\n __se_sys_ioctl fs/ioctl.c:860 [inline]\n __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae

In the Linux kernel, the following vulnerability has been resolved:\n\nx86/xen: Drop USERGS_SYSRET64 paravirt call\n\ncommit afd30525a659ac0ae0904f0cb4a2ca75522c3123 upstream.\n\nUSERGS_SYSRET64 is used to return from a syscall via SYSRET, but\na Xen PV guest will nevertheless use the IRET hypercall, as there\nis no sysret PV hypercall defined.\n\nSo instead of testing all the prerequisites for doing a sysret and\nthen mangling the stack for Xen PV again for doing an iret just use\nthe iret exit from the beginning.\n\nThis can easily be done via an ALTERNATIVE like it is done for the\nsysenter compat case already.\n\nIt should be noted that this drops the optimization in Xen for not\nrestoring a few registers when returning to user mode, but it seems\nas if the saved instructions in the kernel more than compensate for\nthis drop (a kernel build in a Xen PV guest was slightly faster with\nthis patch applied).\n\nWhile at it remove the stale sysret32 remnants.\n\n [ pawan: Brad Spengler and Salvatore Bonaccorso <carnil@debian.org>\n reported a problem with the 5.10 backport commit edc702b4a820\n ("x86/entry_64: Add VERW just before userspace transition").\n\n When CONFIG_PARAVIRT_XXL=y, CLEAR_CPU_BUFFERS is not executed in\n syscall_return_via_sysret path as USERGS_SYSRET64 is runtime\n patched to:\n\n .cpu_usergs_sysret64 = { 0x0f, 0x01, 0xf8,\n 0x48, 0x0f, 0x07 }, // swapgs; sysretq\n\n which is missing CLEAR_CPU_BUFFERS. It turns out dropping\n USERGS_SYSRET64 simplifies the code, allowing CLEAR_CPU_BUFFERS\n to be explicitly added to syscall_return_via_sysret path. Below\n is with CONFIG_PARAVIRT_XXL=y and this patch applied:\n\n syscall_return_via_sysret:\n ...\n <+342>: swapgs\n <+345>: xchg %ax,%ax\n <+347>: verw -0x1a2(%rip) <------\n <+354>: sysretq\n ]

A flaw was found in the QEMU NBD Server. This vulnerability allows a denial of service (DoS) attack via improper synchronization during socket closure when a client keeps a socket open as the server is taken offline.

A flaw was found in libnbd. The client did not always correctly verify the NBD server's certificate when using TLS to connect to an NBD server. This issue allows a man-in-the-middle attack on NBD traffic.

There is a MEDIUM severity vulnerability affecting CPython.\nRegular expressions that allowed excessive backtracking during tarfile.TarFile header parsing are vulnerable to ReDoS via specifically-crafted tar archives.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: bridge: mcast: wait for previous gc cycles when removing port\n\nsyzbot hit a use-after-free[1] which is caused because the bridge doesn't\nmake sure that all previous garbage has been collected when removing a\nport. What happens is:\n CPU 1 CPU 2\n start gc cycle remove port\n acquire gc lock first\n wait for lock\n call br_multicasg_gc() directly\n acquire lock now but free port\n the port can be freed\n while grp timers still\n running\n\nMake sure all previous gc cycles have finished by using flush_work before\nfreeing the port.\n\n[1]\n BUG: KASAN: slab-use-after-free in br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861\n Read of size 8 at addr ffff888071d6d000 by task syz.5.1232/9699\n\n CPU: 1 PID: 9699 Comm: syz.5.1232 Not tainted 6.10.0-rc5-syzkaller-00021-g24ca36a562d6 #0\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024\n Call Trace:\n <IRQ>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0xc3/0x620 mm/kasan/report.c:488\n kasan_report+0xd9/0x110 mm/kasan/report.c:601\n br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861\n call_timer_fn+0x1a3/0x610 kernel/time/timer.c:1792\n expire_timers kernel/time/timer.c:1843 [inline]\n __run_timers+0x74b/0xaf0 kernel/time/timer.c:2417\n __run_timer_base kernel/time/timer.c:2428 [inline]\n __run_timer_base kernel/time/timer.c:2421 [inline]\n run_timer_base+0x111/0x190 kernel/time/timer.c:2437

In the Linux kernel, the following vulnerability has been resolved:\n\ngpio: prevent potential speculation leaks in gpio_device_get_desc()\n\nUserspace may trigger a speculative read of an address outside the gpio\ndescriptor array.\nUsers can do that by calling gpio_ioctl() with an offset out of range.\nOffset is copied from user and then used as an array index to get\nthe gpio descriptor without sanitization in gpio_device_get_desc().\n\nThis change ensures that the offset is sanitized by using\narray_index_nospec() to mitigate any possibility of speculative\ninformation leaks.\n\nThis bug was discovered and resolved using Coverity Static Analysis\nSecurity Testing (SAST) by Synopsys, Inc.

In the Linux kernel, the following vulnerability has been resolved:\n\nmemcg: protect concurrent access to mem_cgroup_idr\n\nCommit 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure after\nmany small jobs") decoupled the memcg IDs from the CSS ID space to fix the\ncgroup creation failures. It introduced IDR to maintain the memcg ID\nspace. The IDR depends on external synchronization mechanisms for\nmodifications. For the mem_cgroup_idr, the idr_alloc() and idr_replace()\nhappen within css callback and thus are protected through cgroup_mutex\nfrom concurrent modifications. However idr_remove() for mem_cgroup_idr\nwas not protected against concurrency and can be run concurrently for\ndifferent memcgs when they hit their refcnt to zero. Fix that.\n\nWe have been seeing list_lru based kernel crashes at a low frequency in\nour fleet for a long time. These crashes were in different part of\nlist_lru code including list_lru_add(), list_lru_del() and reparenting\ncode. Upon further inspection, it looked like for a given object (dentry\nand inode), the super_block's list_lru didn't have list_lru_one for the\nmemcg of that object. The initial suspicions were either the object is\nnot allocated through kmem_cache_alloc_lru() or somehow\nmemcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but\nreturned success. No evidence were found for these cases.\n\nLooking more deeply, we started seeing situations where valid memcg's id\nis not present in mem_cgroup_idr and in some cases multiple valid memcgs\nhave same id and mem_cgroup_idr is pointing to one of them. So, the most\nreasonable explanation is that these situations can happen due to race\nbetween multiple idr_remove() calls or race between\nidr_alloc()/idr_replace() and idr_remove(). These races are causing\nmultiple memcgs to acquire the same ID and then offlining of one of them\nwould cleanup list_lrus on the system for all of them. Later access from\nother memcgs to the list_lru cause crashes due to missing list_lru_one.

In the Linux kernel, the following vulnerability has been resolved:\n\nexec: Fix ToCToU between perm check and set-uid/gid usage\n\nWhen opening a file for exec via do_filp_open(), permission checking is\ndone against the file's metadata at that moment, and on success, a file\npointer is passed back. Much later in the execve() code path, the file\nmetadata (specifically mode, uid, and gid) is used to determine if/how\nto set the uid and gid. However, those values may have changed since the\npermissions check, meaning the execution may gain unintended privileges.\n\nFor example, if a file could change permissions from executable and not\nset-id:\n\n---------x 1 root root 16048 Aug 7 13:16 target\n\nto set-id and non-executable:\n\n---S------ 1 root root 16048 Aug 7 13:16 target\n\nit is possible to gain root privileges when execution should have been\ndisallowed.\n\nWhile this race condition is rare in real-world scenarios, it has been\nobserved (and proven exploitable) when package managers are updating\nthe setuid bits of installed programs. Such files start with being\nworld-executable but then are adjusted to be group-exec with a set-uid\nbit. For example, "chmod o-x,u+s target" makes "target" executable only\nby uid "root" and gid "cdrom", while also becoming setuid-root:\n\n-rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 target\n\nbecomes:\n\n-rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 target\n\nBut racing the chmod means users without group "cdrom" membership can\nget the permission to execute "target" just before the chmod, and when\nthe chmod finishes, the exec reaches brpm_fill_uid(), and performs the\nsetuid to root, violating the expressed authorization of "only cdrom\ngroup members can setuid to root".\n\nRe-check that we still have execute permissions in case the metadata\nhas changed. It would be better to keep a copy from the perm-check time,\nbut until we can do that refactoring, the least-bad option is to do a\nfull inode_permission() call (under inode lock). It is understood that\nthis is safe against dead-locks, but hardly optimal.

In the Linux kernel, the following vulnerability has been resolved:\n\nmlxsw: spectrum_acl_erp: Fix object nesting warning\n\nACLs in Spectrum-2 and newer ASICs can reside in the algorithmic TCAM\n(A-TCAM) or in the ordinary circuit TCAM (C-TCAM). The former can\ncontain more ACLs (i.e., tc filters), but the number of masks in each\nregion (i.e., tc chain) is limited.\n\nIn order to mitigate the effects of the above limitation, the device\nallows filters to share a single mask if their masks only differ in up\nto 8 consecutive bits. For example, dst_ip/25 can be represented using\ndst_ip/24 with a delta of 1 bit. The C-TCAM does not have a limit on the\nnumber of masks being used (and therefore does not support mask\naggregation), but can contain a limited number of filters.\n\nThe driver uses the "objagg" library to perform the mask aggregation by\npassing it objects that consist of the filter's mask and whether the\nfilter is to be inserted into the A-TCAM or the C-TCAM since filters in\ndifferent TCAMs cannot share a mask.\n\nThe set of created objects is dependent on the insertion order of the\nfilters and is not necessarily optimal. Therefore, the driver will\nperiodically ask the library to compute a more optimal set ("hints") by\nlooking at all the existing objects.\n\nWhen the library asks the driver whether two objects can be aggregated\nthe driver only compares the provided masks and ignores the A-TCAM /\nC-TCAM indication. This is the right thing to do since the goal is to\nmove as many filters as possible to the A-TCAM. The driver also forbids\ntwo identical masks from being aggregated since this can only happen if\none was intentionally put in the C-TCAM to avoid a conflict in the\nA-TCAM.\n\nThe above can result in the following set of hints:\n\nH1: {mask X, A-TCAM} -> H2: {mask Y, A-TCAM} // X is Y + delta\nH3: {mask Y, C-TCAM} -> H4: {mask Z, A-TCAM} // Y is Z + delta\n\nAfter getting the hints from the library the driver will start migrating\nfilters from one region to another while consulting the computed hints\nand instructing the device to perform a lookup in both regions during\nthe transition.\n\nAssuming a filter with mask X is being migrated into the A-TCAM in the\nnew region, the hints lookup will return H1. Since H2 is the parent of\nH1, the library will try to find the object associated with it and\ncreate it if necessary in which case another hints lookup (recursive)\nwill be performed. This hints lookup for {mask Y, A-TCAM} will either\nreturn H2 or H3 since the driver passes the library an object comparison\nfunction that ignores the A-TCAM / C-TCAM indication.\n\nThis can eventually lead to nested objects which are not supported by\nthe library [1].\n\nFix by removing the object comparison function from both the driver and\nthe library as the driver was the only user. That way the lookup will\nonly return exact matches.\n\nI do not have a reliable reproducer that can reproduce the issue in a\ntimely manner, but before the fix the issue would reproduce in several\nminutes and with the fix it does not reproduce in over an hour.\n\nNote that the current usefulness of the hints is limited because they\ninclude the C-TCAM indication and represent aggregation that cannot\nactually happen. This will be addressed in net-next.\n\n[1]\nWARNING: CPU: 0 PID: 153 at lib/objagg.c:170 objagg_obj_parent_assign+0xb5/0xd0\nModules linked in:\nCPU: 0 PID: 153 Comm: kworker/0:18 Not tainted 6.9.0-rc6-custom-g70fbc2c1c38b #42\nHardware name: Mellanox Technologies Ltd. MSN3700C/VMOD0008, BIOS 5.11 10/10/2018\nWorkqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work\nRIP: 0010:objagg_obj_parent_assign+0xb5/0xd0\n[...]\nCall Trace:\n \n __objagg_obj_get+0x2bb/0x580\n objagg_obj_get+0xe/0x80\n mlxsw_sp_acl_erp_mask_get+0xb5/0xf0\n mlxsw_sp_acl_atcam_entry_add+0xe8/0x3c0\n mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0\n mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270\n mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510\n process_one_work+0x151/0x370