In the Linux kernel, the following vulnerability has been resolved:\nwifi: iwlwifi: mvm: don't set the MFP flag for the GTK\nThe firmware doesn't need the MFP flag for the GTK, it can even make the\nfirmware crash. in case the AP is configured with: group cipher TKIP and\nMFPC. We would send the GTK with cipher = TKIP and MFP which is of course\nnot possible.

In the Linux kernel, the following vulnerability has been resolved:\nnet: openvswitch: Fix Use-After-Free in ovs_ct_exit\nSince kfree_rcu, which is called in the hlist_for_each_entry_rcu traversal\nof ovs_ct_limit_exit, is not part of the RCU read critical section, it\nis possible that the RCU grace period will pass during the traversal and\nthe key will be free.\nTo prevent this, it should be changed to hlist_for_each_entry_safe.

In the Linux kernel, the following vulnerability has been resolved:\nSUNRPC: fix some memleaks in gssx_dec_option_array\nThe creds and oa->data need to be freed in the error-handling paths after\ntheir allocation. So this patch add these deallocations in the\ncorresponding paths.

In the Linux kernel, the following vulnerability has been resolved:\nnetfilter: nf_tables: do not compare internal table flags on updates\nRestore skipping transaction if table update does not modify flags.

In the Linux kernel, the following vulnerability has been resolved:\nnbd: null check for nla_nest_start\nnla_nest_start() may fail and return NULL. Insert a check and set errno\nbased on other call sites within the same source code.

In the Linux kernel, the following vulnerability has been resolved:\nnetfilter: nf_tables: Fix potential data-race in __nft_expr_type_get()\nnft_unregister_expr() can concurrent with __nft_expr_type_get(),\nand there is not any protection when iterate over nf_tables_expressions\nlist in __nft_expr_type_get(). Therefore, there is potential data-race\nof nf_tables_expressions list entry.\nUse list_for_each_entry_rcu() to iterate over nf_tables_expressions\nlist in __nft_expr_type_get(), and use rcu_read_lock() in the caller\nnft_expr_type_get() to protect the entire type query process.

In the Linux kernel, the following vulnerability has been resolved:\nnetfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()\nnft_unregister_obj() can concurrent with __nft_obj_type_get(),\nand there is not any protection when iterate over nf_tables_objects\nlist in __nft_obj_type_get(). Therefore, there is potential data-race\nof nf_tables_objects list entry.\nUse list_for_each_entry_rcu() to iterate over nf_tables_objects\nlist in __nft_obj_type_get(), and use rcu_read_lock() in the caller\nnft_obj_type_get() to protect the entire type query process.

In the Linux kernel, the following vulnerability has been resolved:\nnetfilter: nf_tables: fix memleak in map from abort path\nThe delete set command does not rely on the transaction object for\nelement removal, therefore, a combination of delete element + delete set\nfrom the abort path could result in restoring twice the refcount of the\nmapping.\nCheck for inactive element in the next generation for the delete element\ncommand in the abort path, skip restoring state if next generation bit\nhas been already cleared. This is similar to the activate logic using\nthe set walk iterator.\n[ 6170.286929] ------------[ cut here ]------------\n[ 6170.286939] WARNING: CPU: 6 PID: 790302 at net/netfilter/nf_tables_api.c:2086 nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.287071] Modules linked in: [...]\n[ 6170.287633] CPU: 6 PID: 790302 Comm: kworker/6:2 Not tainted 6.9.0-rc3+ #365\n[ 6170.287768] RIP: 0010:nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.287886] Code: df 48 8d 7d 58 e8 69 2e 3b df 48 8b 7d 58 e8 80 1b 37 df 48 8d 7d 68 e8 57 2e 3b df 48 8b 7d 68 e8 6e 1b 37 df 48 89 ef eb c4 <0f> 0b 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 0f\n[ 6170.287895] RSP: 0018:ffff888134b8fd08 EFLAGS: 00010202\n[ 6170.287904] RAX: 0000000000000001 RBX: ffff888125bffb28 RCX: dffffc0000000000\n[ 6170.287912] RDX: 0000000000000003 RSI: ffffffffa20298ab RDI: ffff88811ebe4750\n[ 6170.287919] RBP: ffff88811ebe4700 R08: ffff88838e812650 R09: fffffbfff0623a55\n[ 6170.287926] R10: ffffffff8311d2af R11: 0000000000000001 R12: ffff888125bffb10\n[ 6170.287933] R13: ffff888125bffb10 R14: dead000000000122 R15: dead000000000100\n[ 6170.287940] FS: 0000000000000000(0000) GS:ffff888390b00000(0000) knlGS:0000000000000000\n[ 6170.287948] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 6170.287955] CR2: 00007fd31fc00710 CR3: 0000000133f60004 CR4: 00000000001706f0\n[ 6170.287962] Call Trace:\n[ 6170.287967] \n[ 6170.287973] ? __warn+0x9f/0x1a0\n[ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.288092] ? report_bug+0x1b1/0x1e0\n[ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.288092] ? report_bug+0x1b1/0x1e0\n[ 6170.288104] ? handle_bug+0x3c/0x70\n[ 6170.288112] ? exc_invalid_op+0x17/0x40\n[ 6170.288120] ? asm_exc_invalid_op+0x1a/0x20\n[ 6170.288132] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]\n[ 6170.288243] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.288366] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]\n[ 6170.288483] nf_tables_trans_destroy_work+0x588/0x590 [nf_tables]

In the Linux kernel, the following vulnerability has been resolved:\nnet/sched: Fix mirred deadlock on device recursion\nWhen the mirred action is used on a classful egress qdisc and a packet is\nmirrored or redirected to self we hit a qdisc lock deadlock.\nSee trace below.\n[..... other info removed for brevity....]\n[ 82.890906]\n[ 82.890906] ============================================\n[ 82.890906] WARNING: possible recursive locking detected\n[ 82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G W\n[ 82.890906] --------------------------------------------\n[ 82.890906] ping/418 is trying to acquire lock:\n[ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at:\n__dev_queue_xmit+0x1778/0x3550\n[ 82.890906]\n[ 82.890906] but task is already holding lock:\n[ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at:\n__dev_queue_xmit+0x1778/0x3550\n[ 82.890906]\n[ 82.890906] other info that might help us debug this:\n[ 82.890906] Possible unsafe locking scenario:\n[ 82.890906]\n[ 82.890906] CPU0\n[ 82.890906] ----\n[ 82.890906] lock(&sch->q.lock);\n[ 82.890906] lock(&sch->q.lock);\n[ 82.890906]\n[ 82.890906] *** DEADLOCK ***\n[ 82.890906]\n[..... other info removed for brevity....]\nExample setup (eth0->eth0) to recreate\ntc qdisc add dev eth0 root handle 1: htb default 30\ntc filter add dev eth0 handle 1: protocol ip prio 2 matchall \\\naction mirred egress redirect dev eth0\nAnother example(eth0->eth1->eth0) to recreate\ntc qdisc add dev eth0 root handle 1: htb default 30\ntc filter add dev eth0 handle 1: protocol ip prio 2 matchall \\\naction mirred egress redirect dev eth1\ntc qdisc add dev eth1 root handle 1: htb default 30\ntc filter add dev eth1 handle 1: protocol ip prio 2 matchall \\\naction mirred egress redirect dev eth0\nWe fix this by adding an owner field (CPU id) to struct Qdisc set after\nroot qdisc is entered. When the softirq enters it a second time, if the\nqdisc owner is the same CPU, the packet is dropped to break the loop.

In the Linux kernel, the following vulnerability has been resolved:\nmac802154: fix llsec key resources release in mac802154_llsec_key_del\nmac802154_llsec_key_del() can free resources of a key directly without\nfollowing the RCU rules for waiting before the end of a grace period. This\nmay lead to use-after-free in case llsec_lookup_key() is traversing the\nlist of keys in parallel with a key deletion:\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0\nModules linked in:\nCPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\nRIP: 0010:refcount_warn_saturate+0x162/0x2a0\nCall Trace:\n\nllsec_lookup_key.isra.0+0x890/0x9e0\nmac802154_llsec_encrypt+0x30c/0x9c0\nieee802154_subif_start_xmit+0x24/0x1e0\ndev_hard_start_xmit+0x13e/0x690\nsch_direct_xmit+0x2ae/0xbc0\n__dev_queue_xmit+0x11dd/0x3c20\ndgram_sendmsg+0x90b/0xd60\n__sys_sendto+0x466/0x4c0\n__x64_sys_sendto+0xe0/0x1c0\ndo_syscall_64+0x45/0xf0\nentry_SYSCALL_64_after_hwframe+0x6e/0x76\nAlso, ieee802154_llsec_key_entry structures are not freed by\nmac802154_llsec_key_del():\nunreferenced object 0xffff8880613b6980 (size 64):\ncomm "iwpan", pid 2176, jiffies 4294761134 (age 60.475s)\nhex dump (first 32 bytes):\n78 0d 8f 18 80 88 ff ff 22 01 00 00 00 00 ad de x.......".......\n00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00 ................\nbacktrace:\n[] __kmem_cache_alloc_node+0x1e2/0x2d0\n[] kmalloc_trace+0x25/0xc0\n[] mac802154_llsec_key_add+0xac9/0xcf0\n[] ieee802154_add_llsec_key+0x5a/0x80\n[] nl802154_add_llsec_key+0x426/0x5b0\n[] genl_family_rcv_msg_doit+0x1fe/0x2f0\n[] genl_rcv_msg+0x531/0x7d0\n[] netlink_rcv_skb+0x169/0x440\n[] genl_rcv+0x28/0x40\n[] netlink_unicast+0x53c/0x820\n[] netlink_sendmsg+0x93b/0xe60\n[] ____sys_sendmsg+0xac5/0xca0\n[] ___sys_sendmsg+0x11d/0x1c0\n[] __sys_sendmsg+0xfa/0x1d0\n[] do_syscall_64+0x45/0xf0\n[] entry_SYSCALL_64_after_hwframe+0x6e/0x76\nHandle the proper resource release in the RCU callback function\nmac802154_llsec_key_del_rcu().\nNote that if llsec_lookup_key() finds a key, it gets a refcount via\nllsec_key_get() and locally copies key id from key_entry (which is a\nlist element). So it's safe to call llsec_key_put() and free the list\nentry after the RCU grace period elapses.\nFound by Linux Verification Center (linuxtesting.org).

In the Linux kernel, the following vulnerability has been resolved:\nmm: swap: fix race between free_swap_and_cache() and swapoff()\nThere was previously a theoretical window where swapoff() could run and\nteardown a swap_info_struct while a call to free_swap_and_cache() was\nrunning in another thread. This could cause, amongst other bad\npossibilities, swap_page_trans_huge_swapped() (called by\nfree_swap_and_cache()) to access the freed memory for swap_map.\nThis is a theoretical problem and I haven't been able to provoke it from a\ntest case. But there has been agreement based on code review that this is\npossible (see link below).\nFix it by using get_swap_device()/put_swap_device(), which will stall\nswapoff(). There was an extra check in _swap_info_get() to confirm that\nthe swap entry was not free. This isn't present in get_swap_device()\nbecause it doesn't make sense in general due to the race between getting\nthe reference and swapoff. So I've added an equivalent check directly in\nfree_swap_and_cache().\nDetails of how to provoke one possible issue (thanks to David Hildenbrand\nfor deriving this):\n--8<-----\n__swap_entry_free() might be the last user and result in\n"count == SWAP_HAS_CACHE".\nswapoff->try_to_unuse() will stop as soon as soon as si->inuse_pages==0.\nSo the question is: could someone reclaim the folio and turn\nsi->inuse_pages==0, before we completed swap_page_trans_huge_swapped().\nImagine the following: 2 MiB folio in the swapcache. Only 2 subpages are\nstill references by swap entries.\nProcess 1 still references subpage 0 via swap entry.\nProcess 2 still references subpage 1 via swap entry.\nProcess 1 quits. Calls free_swap_and_cache().\n-> count == SWAP_HAS_CACHE\n[then, preempted in the hypervisor etc.]\nProcess 2 quits. Calls free_swap_and_cache().\n-> count == SWAP_HAS_CACHE\nProcess 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls\n__try_to_reclaim_swap().\n__try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()->\nput_swap_folio()->free_swap_slot()->swapcache_free_entries()->\nswap_entry_free()->swap_range_free()->\n...\nWRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries);\nWhat stops swapoff to succeed after process 2 reclaimed the swap cache\nbut before process1 finished its call to swap_page_trans_huge_swapped()?\n--8<-----

In the Linux kernel, the following vulnerability has been resolved:\nnfs: fix UAF in direct writes\nIn production we have been hitting the following warning consistently\n------------[ cut here ]------------\nrefcount_t: underflow; use-after-free.\nWARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0\nWorkqueue: nfsiod nfs_direct_write_schedule_work [nfs]\nRIP: 0010:refcount_warn_saturate+0x9c/0xe0\nPKRU: 55555554\nCall Trace:\n\n? __warn+0x9f/0x130\n? refcount_warn_saturate+0x9c/0xe0\n? report_bug+0xcc/0x150\n? handle_bug+0x3d/0x70\n? exc_invalid_op+0x16/0x40\n? asm_exc_invalid_op+0x16/0x20\n? refcount_warn_saturate+0x9c/0xe0\nnfs_direct_write_schedule_work+0x237/0x250 [nfs]\nprocess_one_work+0x12f/0x4a0\nworker_thread+0x14e/0x3b0\n? ZSTD_getCParams_internal+0x220/0x220\nkthread+0xdc/0x120\n? __btf_name_valid+0xa0/0xa0\nret_from_fork+0x1f/0x30\nThis is because we're completing the nfs_direct_request twice in a row.\nThe source of this is when we have our commit requests to submit, we\nprocess them and send them off, and then in the completion path for the\ncommit requests we have\nif (nfs_commit_end(cinfo.mds))\nnfs_direct_write_complete(dreq);\nHowever since we're submitting asynchronous requests we sometimes have\none that completes before we submit the next one, so we end up calling\ncomplete on the nfs_direct_request twice.\nThe only other place we use nfs_generic_commit_list() is in\n__nfs_commit_inode, which wraps this call in a\nnfs_commit_begin();\nnfs_commit_end();\nWhich is a common pattern for this style of completion handling, one\nthat is also repeated in the direct code with get_dreq()/put_dreq()\ncalls around where we process events as well as in the completion paths.\nFix this by using the same pattern for the commit requests.\nBefore with my 200 node rocksdb stress running this warning would pop\nevery 10ish minutes. With my patch the stress test has been running for\nseveral hours without popping.

In the Linux kernel, the following vulnerability has been resolved:\ndrm/vmwgfx: Create debugfs ttm_resource_manager entry only if needed\nThe driver creates /sys/kernel/debug/dri/0/mob_ttm even when the\ncorresponding ttm_resource_manager is not allocated.\nThis leads to a crash when trying to read from this file.\nAdd a check to create mob_ttm, system_mob_ttm, and gmr_ttm debug file\nonly when the corresponding ttm_resource_manager is allocated.\ncrash> bt\nPID: 3133409 TASK: ffff8fe4834a5000 CPU: 3 COMMAND: "grep"\n#0 [ffffb954506b3b20] machine_kexec at ffffffffb2a6bec3\n#1 [ffffb954506b3b78] __crash_kexec at ffffffffb2bb598a\n#2 [ffffb954506b3c38] crash_kexec at ffffffffb2bb68c1\n#3 [ffffb954506b3c50] oops_end at ffffffffb2a2a9b1\n#4 [ffffb954506b3c70] no_context at ffffffffb2a7e913\n#5 [ffffb954506b3cc8] __bad_area_nosemaphore at ffffffffb2a7ec8c\n#6 [ffffb954506b3d10] do_page_fault at ffffffffb2a7f887\n#7 [ffffb954506b3d40] page_fault at ffffffffb360116e\n[exception RIP: ttm_resource_manager_debug+0x11]\nRIP: ffffffffc04afd11 RSP: ffffb954506b3df0 RFLAGS: 00010246\nRAX: ffff8fe41a6d1200 RBX: 0000000000000000 RCX: 0000000000000940\nRDX: 0000000000000000 RSI: ffffffffc04b4338 RDI: 0000000000000000\nRBP: ffffb954506b3e08 R8: ffff8fee3ffad000 R9: 0000000000000000\nR10: ffff8fe41a76a000 R11: 0000000000000001 R12: 00000000ffffffff\nR13: 0000000000000001 R14: ffff8fe5bb6f3900 R15: ffff8fe41a6d1200\nORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018\n#8 [ffffb954506b3e00] ttm_resource_manager_show at ffffffffc04afde7 [ttm]\n#9 [ffffb954506b3e30] seq_read at ffffffffb2d8f9f3\nRIP: 00007f4c4eda8985 RSP: 00007ffdbba9e9f8 RFLAGS: 00000246\nRAX: ffffffffffffffda RBX: 000000000037e000 RCX: 00007f4c4eda8985\nRDX: 000000000037e000 RSI: 00007f4c41573000 RDI: 0000000000000003\nRBP: 000000000037e000 R8: 0000000000000000 R9: 000000000037fe30\nR10: 0000000000000000 R11: 0000000000000246 R12: 00007f4c41573000\nR13: 0000000000000003 R14: 00007f4c41572010 R15: 0000000000000003\nORIG_RAX: 0000000000000000 CS: 0033 SS: 002b

In the Linux kernel, the following vulnerability has been resolved:\nnetfilter: nf_tables: release mutex after nft_gc_seq_end from abort path\nThe commit mutex should not be released during the critical section\nbetween nft_gc_seq_begin() and nft_gc_seq_end(), otherwise, async GC\nworker could collect expired objects and get the released commit lock\nwithin the same GC sequence.\nnf_tables_module_autoload() temporarily releases the mutex to load\nmodule dependencies, then it goes back to replay the transaction again.\nMove it at the end of the abort phase after nft_gc_seq_end() is called.

In the Linux kernel, the following vulnerability has been resolved:\ninet: inet_defrag: prevent sk release while still in use\nip_local_out() and other functions can pass skb->sk as function argument.\nIf the skb is a fragment and reassembly happens before such function call\nreturns, the sk must not be released.\nThis affects skb fragments reassembled via netfilter or similar\nmodules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline.\nEric Dumazet made an initial analysis of this bug. Quoting Eric:\nCalling ip_defrag() in output path is also implying skb_orphan(),\nwhich is buggy because output path relies on sk not disappearing.\nA relevant old patch about the issue was :\n8282f27449bf ("inet: frag: Always orphan skbs inside ip_defrag()")\n[..]\nnet/ipv4/ip_output.c depends on skb->sk being set, and probably to an\ninet socket, not an arbitrary one.\nIf we orphan the packet in ipvlan, then downstream things like FQ\npacket scheduler will not work properly.\nWe need to change ip_defrag() to only use skb_orphan() when really\nneeded, ie whenever frag_list is going to be used.\nEric suggested to stash sk in fragment queue and made an initial patch.\nHowever there is a problem with this:\nIf skb is refragmented again right after, ip_do_fragment() will copy\nhead->sk to the new fragments, and sets up destructor to sock_wfree.\nIOW, we have no choice but to fix up sk_wmem accouting to reflect the\nfully reassembled skb, else wmem will underflow.\nThis change moves the orphan down into the core, to last possible moment.\nAs ip_defrag_offset is aliased with sk_buff->sk member, we must move the\noffset into the FRAG_CB, else skb->sk gets clobbered.\nThis allows to delay the orphaning long enough to learn if the skb has\nto be queued or if the skb is completing the reasm queue.\nIn the former case, things work as before, skb is orphaned. This is\nsafe because skb gets queued/stolen and won't continue past reasm engine.\nIn the latter case, we will steal the skb->sk reference, reattach it to\nthe head skb, and fix up wmem accouting when inet_frag inflates truesize.

This CVE ID has been rejected or withdrawn by its CVE Numbering Authority for the following reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:\nquota: Fix potential NULL pointer dereference\nBelow race may cause NULL pointer dereference\nP1P2\ndquot_free_inodequota_off\ndrop_dquot_ref\nremove_dquot_ref\ndquots = i_dquot(inode)\ndquots = i_dquot(inode)\nsrcu_read_lock\ndquots[cnt]) != NULL (1)\ndquots[type] = NULL (2)\nspin_lock(&dquots[cnt]->dq_dqb_lock) (3)\n....\nIf dquot_free_inode(or other routines) checks inode's quota pointers (1)\nbefore quota_off sets it to NULL(2) and use it (3) after that, NULL pointer\ndereference will be triggered.\nSo let's fix it by using a temporary pointer to avoid this issue.

In the Linux kernel, the following vulnerability has been resolved:\nNFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102\nA call to listxattr() with a buffer size = 0 returns the actual\nsize of the buffer needed for a subsequent call. When size > 0,\nnfs4_listxattr() does not return an error because either\ngeneric_listxattr() or nfs4_listxattr_nfs4_label() consumes\nexactly all the bytes then size is 0 when calling\nnfs4_listxattr_nfs4_user() which then triggers the following\nkernel BUG:\n[ 99.403778] kernel BUG at mm/usercopy.c:102!\n[ 99.404063] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n[ 99.408463] CPU: 0 PID: 3310 Comm: python3 Not tainted 6.6.0-61.fc40.aarch64 #1\n[ 99.415827] Call trace:\n[ 99.415985] usercopy_abort+0x70/0xa0\n[ 99.416227] __check_heap_object+0x134/0x158\n[ 99.416505] check_heap_object+0x150/0x188\n[ 99.416696] __check_object_size.part.0+0x78/0x168\n[ 99.416886] __check_object_size+0x28/0x40\n[ 99.417078] listxattr+0x8c/0x120\n[ 99.417252] path_listxattr+0x78/0xe0\n[ 99.417476] __arm64_sys_listxattr+0x28/0x40\n[ 99.417723] invoke_syscall+0x78/0x100\n[ 99.417929] el0_svc_common.constprop.0+0x48/0xf0\n[ 99.418186] do_el0_svc+0x24/0x38\n[ 99.418376] el0_svc+0x3c/0x110\n[ 99.418554] el0t_64_sync_handler+0x120/0x130\n[ 99.418788] el0t_64_sync+0x194/0x198\n[ 99.418994] Code: aa0003e3 d000a3e0 91310000 97f49bdb (d4210000)\nIssue is reproduced when generic_listxattr() returns 'system.nfs4_acl',\nthus calling lisxattr() with size = 16 will trigger the bug.\nAdd check on nfs4_listxattr() to return ERANGE error when it is\ncalled with size > 0 and the return value is greater than size.

In the Linux kernel, the following vulnerability has been resolved:\nigc: avoid returning frame twice in XDP_REDIRECT\nWhen a frame can not be transmitted in XDP_REDIRECT\n(e.g. due to a full queue), it is necessary to free\nit by calling xdp_return_frame_rx_napi.\nHowever, this is the responsibility of the caller of\nthe ndo_xdp_xmit (see for example bq_xmit_all in\nkernel/bpf/devmap.c) and thus calling it inside\nigc_xdp_xmit (which is the ndo_xdp_xmit of the igc\ndriver) as well will lead to memory corruption.\nIn fact, bq_xmit_all expects that it can return all\nframes after the last successfully transmitted one.\nTherefore, break for the first not transmitted frame,\nbut do not call xdp_return_frame_rx_napi in igc_xdp_xmit.\nThis is equally implemented in other Intel drivers\nsuch as the igb.\nThere are two alternatives to this that were rejected:\n1. Return num_frames as all the frames would have been\ntransmitted and release them inside igc_xdp_xmit.\nWhile it might work technically, it is not what\nthe return value is meant to represent (i.e. the\nnumber of SUCCESSFULLY transmitted packets).\n2. Rework kernel/bpf/devmap.c and all drivers to\nsupport non-consecutively dropped packets.\nBesides being complex, it likely has a negative\nperformance impact without a significant gain\nsince it is anyway unlikely that the next frame\ncan be transmitted if the previous one was dropped.\nThe memory corruption can be reproduced with\nthe following script which leads to a kernel panic\nafter a few seconds. It basically generates more\ntraffic than a i225 NIC can transmit and pushes it\nvia XDP_REDIRECT from a virtual interface to the\nphysical interface where frames get dropped.\n#!/bin/bash\nINTERFACE=enp4s0\nINTERFACE_IDX=`cat /sys/class/net/$INTERFACE/ifindex`\nsudo ip link add dev veth1 type veth peer name veth2\nsudo ip link set up $INTERFACE\nsudo ip link set up veth1\nsudo ip link set up veth2\ncat << EOF > redirect.bpf.c\nSEC("prog")\nint redirect(struct xdp_md *ctx)\n{\nreturn bpf_redirect($INTERFACE_IDX, 0);\n}\nchar _license[] SEC("license") = "GPL";\nEOF\nclang -O2 -g -Wall -target bpf -c redirect.bpf.c -o redirect.bpf.o\nsudo ip link set veth2 xdp obj redirect.bpf.o\ncat << EOF > pass.bpf.c\nSEC("prog")\nint pass(struct xdp_md *ctx)\n{\nreturn XDP_PASS;\n}\nchar _license[] SEC("license") = "GPL";\nEOF\nclang -O2 -g -Wall -target bpf -c pass.bpf.c -o pass.bpf.o\nsudo ip link set $INTERFACE xdp obj pass.bpf.o\ncat << EOF > trafgen.cfg\n{\n/* Ethernet Header */\n0xe8, 0x6a, 0x64, 0x41, 0xbf, 0x46,\n0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,\nconst16(ETH_P_IP),\n/* IPv4 Header */\n0b01000101, 0, # IPv4 version, IHL, TOS\nconst16(1028), # IPv4 total length (UDP length + 20 bytes (IP header))\nconst16(2), # IPv4 ident\n0b01000000, 0, # IPv4 flags, fragmentation off\n64, # IPv4 TTL\n17, # Protocol UDP\ncsumip(14, 33), # IPv4 checksum\n/* UDP Header */\n10, 0, 1, 1, # IP Src - adapt as needed\n10, 0, 1, 2, # IP Dest - adapt as needed\nconst16(6666), # UDP Src Port\nconst16(6666), # UDP Dest Port\nconst16(1008), # UDP length (UDP header 8 bytes + payload length)\ncsumudp(14, 34), # UDP checksum\n/* Payload */\nfill('W', 1000),\n}\nEOF\nsudo trafgen -i trafgen.cfg -b3000MB -o veth1 --cpp

In the Linux kernel, the following vulnerability has been resolved:\nnet/ipv6: avoid possible UAF in ip6_route_mpath_notify()\nsyzbot found another use-after-free in ip6_route_mpath_notify() [1]\nCommit f7225172f25a ("net/ipv6: prevent use after free in\nip6_route_mpath_notify") was not able to fix the root cause.\nWe need to defer the fib6_info_release() calls after\nip6_route_mpath_notify(), in the cleanup phase.\n[1]\nBUG: KASAN: slab-use-after-free in rt6_fill_node+0x1460/0x1ac0\nRead of size 4 at addr ffff88809a07fc64 by task syz-executor.2/23037\nCPU: 0 PID: 23037 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-01035-gea7f3cfaa588 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024\nCall Trace:\n\n__dump_stack lib/dump_stack.c:88 [inline]\ndump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106\nprint_address_description mm/kasan/report.c:377 [inline]\nprint_report+0x167/0x540 mm/kasan/report.c:488\nkasan_report+0x142/0x180 mm/kasan/report.c:601\nrt6_fill_node+0x1460/0x1ac0\ninet6_rt_notify+0x13b/0x290 net/ipv6/route.c:6184\nip6_route_mpath_notify net/ipv6/route.c:5198 [inline]\nip6_route_multipath_add net/ipv6/route.c:5404 [inline]\ninet6_rtm_newroute+0x1d0f/0x2300 net/ipv6/route.c:5517\nrtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597\nnetlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543\nnetlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]\nnetlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367\nnetlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908\nsock_sendmsg_nosec net/socket.c:730 [inline]\n__sock_sendmsg+0x221/0x270 net/socket.c:745\n____sys_sendmsg+0x525/0x7d0 net/socket.c:2584\n___sys_sendmsg net/socket.c:2638 [inline]\n__sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667\ndo_syscall_64+0xf9/0x240\nentry_SYSCALL_64_after_hwframe+0x6f/0x77\nRIP: 0033:0x7f73dd87dda9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 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 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f73de6550c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 00007f73dd9ac050 RCX: 00007f73dd87dda9\nRDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005\nRBP: 00007f73dd8ca47a R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 000000000000006e R14: 00007f73dd9ac050 R15: 00007ffdbdeb7858\n\nAllocated by task 23037:\nkasan_save_stack mm/kasan/common.c:47 [inline]\nkasan_save_track+0x3f/0x80 mm/kasan/common.c:68\npoison_kmalloc_redzone mm/kasan/common.c:372 [inline]\n__kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:389\nkasan_kmalloc include/linux/kasan.h:211 [inline]\n__do_kmalloc_node mm/slub.c:3981 [inline]\n__kmalloc+0x22e/0x490 mm/slub.c:3994\nkmalloc include/linux/slab.h:594 [inline]\nkzalloc include/linux/slab.h:711 [inline]\nfib6_info_alloc+0x2e/0xf0 net/ipv6/ip6_fib.c:155\nip6_route_info_create+0x445/0x12b0 net/ipv6/route.c:3758\nip6_route_multipath_add net/ipv6/route.c:5298 [inline]\ninet6_rtm_newroute+0x744/0x2300 net/ipv6/route.c:5517\nrtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597\nnetlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543\nnetlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]\nnetlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367\nnetlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908\nsock_sendmsg_nosec net/socket.c:730 [inline]\n__sock_sendmsg+0x221/0x270 net/socket.c:745\n____sys_sendmsg+0x525/0x7d0 net/socket.c:2584\n___sys_sendmsg net/socket.c:2638 [inline]\n__sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667\ndo_syscall_64+0xf9/0x240\nentry_SYSCALL_64_after_hwframe+0x6f/0x77\nFreed by task 16:\nkasan_save_stack mm/kasan/common.c:47 [inline]\nkasan_save_track+0x3f/0x80 mm/kasan/common.c:68\nkasan_save_free_info+0x4e/0x60 mm/kasan/generic.c:640\npoison_slab_object+0xa6/0xe0 m\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\nefi: runtime: Fix potential overflow of soft-reserved region size\nmd_size will have been narrowed if we have >= 4GB worth of pages in a\nsoft-reserved region.

In the Linux kernel, the following vulnerability has been resolved:\ncachefiles: fix memory leak in cachefiles_add_cache()\nThe following memory leak was reported after unbinding /dev/cachefiles:\n==================================================================\nunreferenced object 0xffff9b674176e3c0 (size 192):\ncomm "cachefilesd2", pid 680, jiffies 4294881224\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 00 00 00 00 00 00 00 00 00 00 00 00 ................\nbacktrace (crc ea38a44b):\n[] kmem_cache_alloc+0x2d5/0x370\n[] prepare_creds+0x26/0x2e0\n[] cachefiles_determine_cache_security+0x1f/0x120\n[] cachefiles_add_cache+0x13c/0x3a0\n[] cachefiles_daemon_write+0x146/0x1c0\n[] vfs_write+0xcb/0x520\n[] ksys_write+0x69/0xf0\n[] do_syscall_64+0x72/0x140\n[] entry_SYSCALL_64_after_hwframe+0x6e/0x76\n==================================================================\nPut the reference count of cache_cred in cachefiles_daemon_unbind() to\nfix the problem. And also put cache_cred in cachefiles_add_cache() error\nbranch to avoid memory leaks.

In the Linux kernel, the following vulnerability has been resolved:\nnet: bridge: switchdev: Skip MDB replays of deferred events on offload\nBefore this change, generation of the list of MDB events to replay\nwould race against the creation of new group memberships, either from\nthe IGMP/MLD snooping logic or from user configuration.\nWhile new memberships are immediately visible to walkers of\nbr->mdb_list, the notification of their existence to switchdev event\nsubscribers is deferred until a later point in time. So if a replay\nlist was generated during a time that overlapped with such a window,\nit would also contain a replay of the not-yet-delivered event.\nThe driver would thus receive two copies of what the bridge internally\nconsidered to be one single event. On destruction of the bridge, only\na single membership deletion event was therefore sent. As a\nconsequence of this, drivers which reference count memberships (at\nleast DSA), would be left with orphan groups in their hardware\ndatabase when the bridge was destroyed.\nThis is only an issue when replaying additions. While deletion events\nmay still be pending on the deferred queue, they will already have\nbeen removed from br->mdb_list, so no duplicates can be generated in\nthat scenario.\nTo a user this meant that old group memberships, from a bridge in\nwhich a port was previously attached, could be reanimated (in\nhardware) when the port joined a new bridge, without the new bridge's\nknowledge.\nFor example, on an mv88e6xxx system, create a snooping bridge and\nimmediately add a port to it:\nroot@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \\\n> ip link set dev x3 up master br0\nAnd then destroy the bridge:\nroot@infix-06-0b-00:~$ ip link del dev br0\nroot@infix-06-0b-00:~$ mvls atu\nADDRESS FID STATE Q F 0 1 2 3 4 5 6 7 8 9 a\nDEV:0 Marvell 88E6393X\n33:33::6a 1 static - - 0 . . . . . . . . . .\n33:33:ff:87:e4:3f 1 static - - 0 . . . . . . . . . .\nff:ff:ff:ff:ff:ff 1 static - - 0 1 2 3 4 5 6 7 8 9 a\nroot@infix-06-0b-00:~$\nThe two IPv6 groups remain in the hardware database because the\nport (x3) is notified of the host's membership twice: once via the\noriginal event and once via a replay. Since only a single delete\nnotification is sent, the count remains at 1 when the bridge is\ndestroyed.\nThen add the same port (or another port belonging to the same hardware\ndomain) to a new bridge, this time with snooping disabled:\nroot@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcast_snooping 0 && \\\n> ip link set dev x3 up master br1\nAll multicast, including the two IPv6 groups from br0, should now be\nflooded, according to the policy of br1. But instead the old\nmemberships are still active in the hardware database, causing the\nswitch to only forward traffic to those groups towards the CPU (port\n0).\nEliminate the race in two steps:\n1. Grab the write-side lock of the MDB while generating the replay\nlist.\nThis prevents new memberships from showing up while we are generating\nthe replay list. But it leaves the scenario in which a deferred event\nwas already generated, but not delivered, before we grabbed the\nlock. Therefore:\n2. Make sure that no deferred version of a replay event is already\nenqueued to the switchdev deferred queue, before adding it to the\nreplay list, when replaying additions.

In the Linux kernel, the following vulnerability has been resolved:\nvfio/pci: Lock external INTx masking ops\nMask operations through config space changes to DisINTx may race INTx\nconfiguration changes via ioctl. Create wrappers that add locking for\npaths outside of the core interrupt code.\nIn particular, irq_type is updated holding igate, therefore testing\nis_intx() requires holding igate. For example clearing DisINTx from\nconfig space can otherwise race changes of the interrupt configuration.\nThis aligns interfaces which may trigger the INTx eventfd into two\ncamps, one side serialized by igate and the other only enabled while\nINTx is configured. A subsequent patch introduces synchronization for\nthe latter flows.

In the Linux kernel, the following vulnerability has been resolved:\nstmmac: Clear variable when destroying workqueue\nCurrently when suspending driver and stopping workqueue it is checked whether\nworkqueue is not NULL and if so, it is destroyed.\nFunction destroy_workqueue() does drain queue and does clear variable, but\nit does not set workqueue variable to NULL. This can cause kernel/module\npanic if code attempts to clear workqueue that was not initialized.\nThis scenario is possible when resuming suspended driver in stmmac_resume(),\nbecause there is no handling for failed stmmac_hw_setup(),\nwhich can fail and return if DMA engine has failed to initialize,\nand workqueue is initialized after DMA engine.\nShould DMA engine fail to initialize, resume will proceed normally,\nbut interface won't work and TX queue will eventually timeout,\ncausing 'Reset adapter' error.\nThis then does destroy workqueue during reset process.\nAnd since workqueue is initialized after DMA engine and can be skipped,\nit will cause kernel/module panic.\nTo secure against this possible crash, set workqueue variable to NULL when\ndestroying workqueue.\nLog/backtrace from crash goes as follows:\n[88.031977]------------[ cut here ]------------\n[88.031985]NETDEV WATCHDOG: eth0 (sxgmac): transmit queue 1 timed out\n[88.032017]WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:477 dev_watchdog+0x390/0x398\n\n[88.032251]---[ end trace e70de432e4d5c2c0 ]---\n[88.032282]sxgmac 16d88000.ethernet eth0: Reset adapter.\n[88.036359]------------[ cut here ]------------\n[88.036519]Call trace:\n[88.036523] flush_workqueue+0x3e4/0x430\n[88.036528] drain_workqueue+0xc4/0x160\n[88.036533] destroy_workqueue+0x40/0x270\n[88.036537] stmmac_fpe_stop_wq+0x4c/0x70\n[88.036541] stmmac_release+0x278/0x280\n[88.036546] __dev_close_many+0xcc/0x158\n[88.036551] dev_close_many+0xbc/0x190\n[88.036555] dev_close.part.0+0x70/0xc0\n[88.036560] dev_close+0x24/0x30\n[88.036564] stmmac_service_task+0x110/0x140\n[88.036569] process_one_work+0x1d8/0x4a0\n[88.036573] worker_thread+0x54/0x408\n[88.036578] kthread+0x164/0x170\n[88.036583] ret_from_fork+0x10/0x20\n[88.036588]---[ end trace e70de432e4d5c2c1 ]---\n[88.036597]Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004

In the Linux kernel, the following vulnerability has been resolved:\next4: avoid allocating blocks from corrupted group in ext4_mb_try_best_found()\nDetermine if the group block bitmap is corrupted before using ac_b_ex in\next4_mb_try_best_found() to avoid allocating blocks from a group with a\ncorrupted block bitmap in the following concurrency and making the\nsituation worse.\next4_mb_regular_allocator\next4_lock_group(sb, group)\next4_mb_good_group\n// check if the group bbitmap is corrupted\next4_mb_complex_scan_group\n// Scan group gets ac_b_ex but doesn't use it\next4_unlock_group(sb, group)\next4_mark_group_bitmap_corrupted(group)\n// The block bitmap was corrupted during\n// the group unlock gap.\next4_mb_try_best_found\next4_lock_group(ac->ac_sb, group)\next4_mb_use_best_found\nmb_mark_used\n// Allocating blocks in block bitmap corrupted group

In the Linux kernel, the following vulnerability has been resolved:\next4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal()\nPlaces the logic for checking if the group's block bitmap is corrupt under\nthe protection of the group lock to avoid allocating blocks from the group\nwith a corrupted block bitmap.

In the Linux kernel, the following vulnerability has been resolved:\nnet/sched: act_mirred: use the backlog for mirred ingress\nThe test Davide added in commit ca22da2fbd69 ("act_mirred: use the backlog\nfor nested calls to mirred ingress") hangs our testing VMs every 10 or so\nruns, with the familiar tcp_v4_rcv -> tcp_v4_rcv deadlock reported by\nlockdep.\nThe problem as previously described by Davide (see Link) is that\nif we reverse flow of traffic with the redirect (egress -> ingress)\nwe may reach the same socket which generated the packet. And we may\nstill be holding its socket lock. The common solution to such deadlocks\nis to put the packet in the Rx backlog, rather than run the Rx path\ninline. Do that for all egress -> ingress reversals, not just once\nwe started to nest mirred calls.\nIn the past there was a concern that the backlog indirection will\nlead to loss of error reporting / less accurate stats. But the current\nworkaround does not seem to address the issue.

In the Linux kernel, the following vulnerability has been resolved:\narp: Prevent overflow in arp_req_get().\nsyzkaller reported an overflown write in arp_req_get(). [0]\nWhen ioctl(SIOCGARP) is issued, arp_req_get() looks up an neighbour\nentry and copies neigh->ha to struct arpreq.arp_ha.sa_data.\nThe arp_ha here is struct sockaddr, not struct sockaddr_storage, so\nthe sa_data buffer is just 14 bytes.\nIn the splat below, 2 bytes are overflown to the next int field,\narp_flags. We initialise the field just after the memcpy(), so it's\nnot a problem.\nHowever, when dev->addr_len is greater than 22 (e.g. MAX_ADDR_LEN),\narp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL)\nin arp_ioctl() before calling arp_req_get().\nTo avoid the overflow, let's limit the max length of memcpy().\nNote that commit b5f0de6df6dc ("net: dev: Convert sa_data to flexible\narray in struct sockaddr") just silenced syzkaller.\n[0]:\nmemcpy: detected field-spanning write (size 16) of single field "r->arp_ha.sa_data" at net/ipv4/arp.c:1128 (size 14)\nWARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128\nModules linked in:\nCPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014\nRIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128\nCode: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb <0f> 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6\nRSP: 0018:ffffc900050b7998 EFLAGS: 00010286\nRAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001\nRBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000\nR13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010\nFS: 00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n\narp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261\ninet_ioctl+0x314/0x3a0 net/ipv4/af_inet.c:981\nsock_do_ioctl+0xdf/0x260 net/socket.c:1204\nsock_ioctl+0x3ef/0x650 net/socket.c:1321\nvfs_ioctl fs/ioctl.c:51 [inline]\n__do_sys_ioctl fs/ioctl.c:870 [inline]\n__se_sys_ioctl fs/ioctl.c:856 [inline]\n__x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856\ndo_syscall_x64 arch/x86/entry/common.c:51 [inline]\ndo_syscall_64+0x37/0x90 arch/x86/entry/common.c:81\nentry_SYSCALL_64_after_hwframe+0x64/0xce\nRIP: 0033:0x7f172b262b8d\nCode: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 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 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f172bf300b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d\nRDX: 0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003\nRBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000\n

In the Linux kernel, the following vulnerability has been resolved:\next4: fix double-free of blocks due to wrong extents moved_len\nIn ext4_move_extents(), moved_len is only updated when all moves are\nsuccessfully executed, and only discards orig_inode and donor_inode\npreallocations when moved_len is not zero. When the loop fails to exit\nafter successfully moving some extents, moved_len is not updated and\nremains at 0, so it does not discard the preallocations.\nIf the moved extents overlap with the preallocated extents, the\noverlapped extents are freed twice in ext4_mb_release_inode_pa() and\next4_process_freed_data() (as described in commit 94d7c16cbbbd ("ext4:\nFix double-free of blocks with EXT4_IOC_MOVE_EXT")), and bb_free is\nincremented twice. Hence when trim is executed, a zero-division bug is\ntriggered in mb_update_avg_fragment_size() because bb_free is not zero\nand bb_fragments is zero.\nTherefore, update move_len after each extent move to avoid the issue.

In the Linux kernel, the following vulnerability has been resolved:\nhv_netvsc: Fix race condition between netvsc_probe and netvsc_remove\nIn commit ac5047671758 ("hv_netvsc: Disable NAPI before closing the\nVMBus channel"), napi_disable was getting called for all channels,\nincluding all subchannels without confirming if they are enabled or not.\nThis caused hv_netvsc getting hung at napi_disable, when netvsc_probe()\nhas finished running but nvdev->subchan_work has not started yet.\nnetvsc_subchan_work() -> rndis_set_subchannel() has not created the\nsub-channels and because of that netvsc_sc_open() is not running.\nnetvsc_remove() calls cancel_work_sync(&nvdev->subchan_work), for which\nnetvsc_subchan_work did not run.\nnetif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPI\ncannot be scheduled. Then netvsc_sc_open() -> napi_enable will clear the\nNAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does the\nopposite.\nNow during netvsc_device_remove(), when napi_disable is called for those\nsubchannels, napi_disable gets stuck on infinite msleep.\nThis fix addresses this problem by ensuring that napi_disable() is not\ngetting called for non-enabled NAPI struct.\nBut netif_napi_del() is still necessary for these non-enabled NAPI struct\nfor cleanup purpose.\nCall trace:\n[ 654.559417] task:modprobe state:D stack: 0 pid: 2321 ppid: 1091 flags:0x00004002\n[ 654.568030] Call Trace:\n[ 654.571221] \n[ 654.573790] __schedule+0x2d6/0x960\n[ 654.577733] schedule+0x69/0xf0\n[ 654.581214] schedule_timeout+0x87/0x140\n[ 654.585463] ? __bpf_trace_tick_stop+0x20/0x20\n[ 654.590291] msleep+0x2d/0x40\n[ 654.593625] napi_disable+0x2b/0x80\n[ 654.597437] netvsc_device_remove+0x8a/0x1f0 [hv_netvsc]\n[ 654.603935] rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc]\n[ 654.611101] ? do_wait_intr+0xb0/0xb0\n[ 654.615753] netvsc_remove+0x7c/0x120 [hv_netvsc]\n[ 654.621675] vmbus_remove+0x27/0x40 [hv_vmbus]

In the Linux kernel, the following vulnerability has been resolved:\nfs/proc: do_task_stat: use sig->stats_lock to gather the threads/children stats\nlock_task_sighand() can trigger a hard lockup. If NR_CPUS threads call\ndo_task_stat() at the same time and the process has NR_THREADS, it will\nspin with irqs disabled O(NR_CPUS * NR_THREADS) time.\nChange do_task_stat() to use sig->stats_lock to gather the statistics\noutside of ->siglock protected section, in the likely case this code will\nrun lockless.

In the Linux kernel, the following vulnerability has been resolved:\ndrm/amd/display: Implement bounds check for stream encoder creation in DCN301\n'stream_enc_regs' array is an array of dcn10_stream_enc_registers\nstructures. The array is initialized with four elements, corresponding\nto the four calls to stream_enc_regs() in the array initializer. This\nmeans that valid indices for this array are 0, 1, 2, and 3.\nThe error message 'stream_enc_regs' 4 <= 5 below, is indicating that\nthere is an attempt to access this array with an index of 5, which is\nout of bounds. This could lead to undefined behavior\nHere, eng_id is used as an index to access the stream_enc_regs array. If\neng_id is 5, this would result in an out-of-bounds access on the\nstream_enc_regs array.\nThus fixing Buffer overflow error in dcn301_stream_encoder_create\nreported by Smatch:\ndrivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn301/dcn301_resource.c:1011 dcn301_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5

In the Linux kernel, the following vulnerability has been resolved:\ntcp: add sanity checks to rx zerocopy\nTCP rx zerocopy intent is to map pages initially allocated\nfrom NIC drivers, not pages owned by a fs.\nThis patch adds to can_map_frag() these additional checks:\n- Page must not be a compound one.\n- page->mapping must be NULL.\nThis fixes the panic reported by ZhangPeng.\nsyzbot was able to loopback packets built with sendfile(),\nmapping pages owned by an ext4 file to TCP rx zerocopy.\nr3 = socket$inet_tcp(0x2, 0x1, 0x0)\nmmap(&(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0)\nr4 = socket$inet_tcp(0x2, 0x1, 0x0)\nbind$inet(r4, &(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10)\nconnect$inet(r4, &(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10)\nr5 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\\x00',\n0x181e42, 0x0)\nfallocate(r5, 0x0, 0x0, 0x85b8)\nsendfile(r4, r5, 0x0, 0x8ba0)\ngetsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23,\n&(0x7f00000001c0)={&(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0,\n0x0, 0x0, 0x0, 0x0}, &(0x7f0000000440)=0x40)\nr6 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\\x00',\n0x181e42, 0x0)

In the Linux kernel, the following vulnerability has been resolved:\ntcp: make sure init the accept_queue's spinlocks once\nWhen I run syz's reproduction C program locally, it causes the following\nissue:\npvqspinlock: lock 0xffff9d181cd5c660 has corrupted value 0x0!\nWARNING: CPU: 19 PID: 21160 at __pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)\nHardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011\nRIP: 0010:__pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)\nCode: 73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7\n30 20 ce 8f e8 ad 56 42 ff <0f> 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90\nRSP: 0018:ffffa8d200604cb8 EFLAGS: 00010282\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908\nRDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900\nRBP: ffff9d181cd5c280 R08: 0000000000000000 R09: 00000000ffff7fff\nR10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000\nR13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000\nFS: 00007fa110184640(0000) GS:ffff9d1ef60c0000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0\nCall Trace:\n\n_raw_spin_unlock (kernel/locking/spinlock.c:186)\ninet_csk_reqsk_queue_add (net/ipv4/inet_connection_sock.c:1321)\ninet_csk_complete_hashdance (net/ipv4/inet_connection_sock.c:1358)\ntcp_check_req (net/ipv4/tcp_minisocks.c:868)\ntcp_v4_rcv (net/ipv4/tcp_ipv4.c:2260)\nip_protocol_deliver_rcu (net/ipv4/ip_input.c:205)\nip_local_deliver_finish (net/ipv4/ip_input.c:234)\n__netif_receive_skb_one_core (net/core/dev.c:5529)\nprocess_backlog (./include/linux/rcupdate.h:779)\n__napi_poll (net/core/dev.c:6533)\nnet_rx_action (net/core/dev.c:6604)\n__do_softirq (./arch/x86/include/asm/jump_label.h:27)\ndo_softirq (kernel/softirq.c:454 kernel/softirq.c:441)\n\n\n__local_bh_enable_ip (kernel/softirq.c:381)\n__dev_queue_xmit (net/core/dev.c:4374)\nip_finish_output2 (./include/net/neighbour.h:540 net/ipv4/ip_output.c:235)\n__ip_queue_xmit (net/ipv4/ip_output.c:535)\n__tcp_transmit_skb (net/ipv4/tcp_output.c:1462)\ntcp_rcv_synsent_state_process (net/ipv4/tcp_input.c:6469)\ntcp_rcv_state_process (net/ipv4/tcp_input.c:6657)\ntcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1929)\n__release_sock (./include/net/sock.h:1121 net/core/sock.c:2968)\nrelease_sock (net/core/sock.c:3536)\ninet_wait_for_connect (net/ipv4/af_inet.c:609)\n__inet_stream_connect (net/ipv4/af_inet.c:702)\ninet_stream_connect (net/ipv4/af_inet.c:748)\n__sys_connect (./include/linux/file.h:45 net/socket.c:2064)\n__x64_sys_connect (net/socket.c:2073 net/socket.c:2070 net/socket.c:2070)\ndo_syscall_64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:82)\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)\nRIP: 0033:0x7fa10ff05a3d\nCode: 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\nc2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ab a3 0e 00 f7 d8 64 89 01 48\nRSP: 002b:00007fa110183de8 EFLAGS: 00000202 ORIG_RAX: 000000000000002a\nRAX: ffffffffffffffda RBX: 0000000020000054 RCX: 00007fa10ff05a3d\nRDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003\nRBP: 00007fa110183e20 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000202 R12: 00007fa110184640\nR13: 0000000000000000 R14: 00007fa10fe8b060 R15: 00007fff73e23b20\n\nThe issue triggering process is analyzed as follows:\nThread A Thread B\ntcp_v4_rcv//receive ack TCP packet inet_shutdown\ntcp_check_req tcp_disconnect //disconnect sock\n... tcp_set_state(sk, TCP_CLOSE)\ninet_csk_complete_hashdance ...\ninet_csk_reqsk_queue_add \n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\nmlxsw: spectrum_acl_tcam: Fix stack corruption\nWhen tc filters are first added to a net device, the corresponding local\nport gets bound to an ACL group in the device. The group contains a list\nof ACLs. In turn, each ACL points to a different TCAM region where the\nfilters are stored. During forwarding, the ACLs are sequentially\nevaluated until a match is found.\nOne reason to place filters in different regions is when they are added\nwith decreasing priorities and in an alternating order so that two\nconsecutive filters can never fit in the same region because of their\nkey usage.\nIn Spectrum-2 and newer ASICs the firmware started to report that the\nmaximum number of ACLs in a group is more than 16, but the layout of the\nregister that configures ACL groups (PAGT) was not updated to account\nfor that. It is therefore possible to hit stack corruption [1] in the\nrare case where more than 16 ACLs in a group are required.\nFix by limiting the maximum ACL group size to the minimum between what\nthe firmware reports and the maximum ACLs that fit in the PAGT register.\nAdd a test case to make sure the machine does not crash when this\ncondition is hit.\n[1]\nKernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120\n[...]\ndump_stack_lvl+0x36/0x50\npanic+0x305/0x330\n__stack_chk_fail+0x15/0x20\nmlxsw_sp_acl_tcam_group_update+0x116/0x120\nmlxsw_sp_acl_tcam_group_region_attach+0x69/0x110\nmlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20\nmlxsw_sp_acl_tcam_ventry_add+0x25/0xe0\nmlxsw_sp_acl_rule_add+0x47/0x240\nmlxsw_sp_flower_replace+0x1a9/0x1d0\ntc_setup_cb_add+0xdc/0x1c0\nfl_hw_replace_filter+0x146/0x1f0\nfl_change+0xc17/0x1360\ntc_new_tfilter+0x472/0xb90\nrtnetlink_rcv_msg+0x313/0x3b0\nnetlink_rcv_skb+0x58/0x100\nnetlink_unicast+0x244/0x390\nnetlink_sendmsg+0x1e4/0x440\n____sys_sendmsg+0x164/0x260\n___sys_sendmsg+0x9a/0xe0\n__sys_sendmsg+0x7a/0xc0\ndo_syscall_64+0x40/0xe0\nentry_SYSCALL_64_after_hwframe+0x63/0x6b

create_empty_lvol in drivers/mtd/ubi/vtbl.c in the Linux kernel through 6.7.4 can attempt to allocate zero bytes, and crash, because of a missing check for ubi->leb_size.

A flaw was found in some Intel CPUs where mitigations for the Spectre V2/BHI vulnerability were incomplete. This issue may allow an attacker to read arbitrary memory, compromising system integrity and exposing sensitive information.

Hardware logic with insecure de-synchronization in Intel(R) DSA and Intel(R) IAA for some Intel(R) 4th or 5th generation Xeon(R) processors may allow an authorized user to potentially enable denial of service via local access.

Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot). Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and 21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 7.4 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).

Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: 2D). Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and 21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).

Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Concurrency). Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23; Oracle GraalVM Enterprise Edition: 20.3.14 and 21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.7 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).

Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot). Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and 21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).

Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot). Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and 21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).

Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot). Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and 21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).

In the Linux kernel, the following vulnerability has been resolved:\nplatform/x86: wmi: Fix opening of char device\nSince commit fa1f68db6ca7 ("drivers: misc: pass miscdevice pointer via\nfile private data"), the miscdevice stores a pointer to itself inside\nfilp->private_data, which means that private_data will not be NULL when\nwmi_char_open() is called. This might cause memory corruption should\nwmi_char_open() be unable to find its driver, something which can\nhappen when the associated WMI device is deleted in wmi_free_devices().\nFix the problem by using the miscdevice pointer to retrieve the WMI\ndevice data associated with a char device using container_of(). This\nalso avoids wmi_char_open() picking a wrong WMI device bound to a\ndriver with the same name as the original driver.

In the Linux kernel, the following vulnerability has been resolved:\nmedia: bttv: fix use after free error due to btv->timeout timer\nThere may be some a race condition between timer function\nbttv_irq_timeout and bttv_remove. The timer is setup in\nprobe and there is no timer_delete operation in remove\nfunction. When it hit kfree btv, the function might still be\ninvoked, which will cause use after free bug.\nThis bug is found by static analysis, it may be false positive.\nFix it by adding del_timer_sync invoking to the remove function.\ncpu0 cpu1\nbttv_probe\n->timer_setup\n->bttv_set_dma\n->mod_timer;\nbttv_remove\n->kfree(btv);\n->bttv_irq_timeout\n->USE btv

In the Linux kernel, the following vulnerability has been resolved:\ntipc: Change nla_policy for bearer-related names to NLA_NUL_STRING\nsyzbot reported the following uninit-value access issue [1]:\n=====================================================\nBUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline]\nBUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756\nstrlen lib/string.c:418 [inline]\nstrstr+0xb8/0x2f0 lib/string.c:756\ntipc_nl_node_reset_link_stats+0x3ea/0xb50 net/tipc/node.c:2595\ngenl_family_rcv_msg_doit net/netlink/genetlink.c:971 [inline]\ngenl_family_rcv_msg net/netlink/genetlink.c:1051 [inline]\ngenl_rcv_msg+0x11ec/0x1290 net/netlink/genetlink.c:1066\nnetlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2545\ngenl_rcv+0x40/0x60 net/netlink/genetlink.c:1075\nnetlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline]\nnetlink_unicast+0xf47/0x1250 net/netlink/af_netlink.c:1368\nnetlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910\nsock_sendmsg_nosec net/socket.c:730 [inline]\nsock_sendmsg net/socket.c:753 [inline]\n____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541\n___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595\n__sys_sendmsg net/socket.c:2624 [inline]\n__do_sys_sendmsg net/socket.c:2633 [inline]\n__se_sys_sendmsg net/socket.c:2631 [inline]\n__x64_sys_sendmsg+0x307/0x490 net/socket.c:2631\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\nUninit was created at:\nslab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767\nslab_alloc_node mm/slub.c:3478 [inline]\nkmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523\nkmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559\n__alloc_skb+0x318/0x740 net/core/skbuff.c:650\nalloc_skb include/linux/skbuff.h:1286 [inline]\nnetlink_alloc_large_skb net/netlink/af_netlink.c:1214 [inline]\nnetlink_sendmsg+0xb34/0x13d0 net/netlink/af_netlink.c:1885\nsock_sendmsg_nosec net/socket.c:730 [inline]\nsock_sendmsg net/socket.c:753 [inline]\n____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541\n___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595\n__sys_sendmsg net/socket.c:2624 [inline]\n__do_sys_sendmsg net/socket.c:2633 [inline]\n__se_sys_sendmsg net/socket.c:2631 [inline]\n__x64_sys_sendmsg+0x307/0x490 net/socket.c:2631\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\nTIPC bearer-related names including link names must be null-terminated\nstrings. If a link name which is not null-terminated is passed through\nnetlink, strstr() and similar functions can cause buffer overrun. This\ncauses the above issue.\nThis patch changes the nla_policy for bearer-related names from NLA_STRING\nto NLA_NUL_STRING. This resolves the issue by ensuring that only\nnull-terminated strings are accepted as bearer-related names.\nsyzbot reported similar uninit-value issue related to bearer names [2]. The\nroot cause of this issue is that a non-null-terminated bearer name was\npassed. This patch also resolved this issue.

In the Linux kernel, the following vulnerability has been resolved:\natl1c: Work around the DMA RX overflow issue\nThis is based on alx driver commit 881d0327db37 ("net: alx: Work around\nthe DMA RX overflow issue").\nThe alx and atl1c drivers had RX overflow error which was why a custom\nallocator was created to avoid certain addresses. The simpler workaround\nthen created for alx driver, but not for atl1c due to lack of tester.\nInstead of using a custom allocator, check the allocated skb address and\nuse skb_reserve() to move away from problematic 0x...fc0 address.\nTested on AR8131 on Acer 4540.

In the Linux kernel, the following vulnerability has been resolved:\nwifi: mac80211: don't return unset power in ieee80211_get_tx_power()\nWe can get a UBSAN warning if ieee80211_get_tx_power() returns the\nINT_MIN value mac80211 internally uses for "unset power level".\nUBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5\n-2147483648 * 100 cannot be represented in type 'int'\nCPU: 0 PID: 20433 Comm: insmod Tainted: G WC OE\nCall Trace:\ndump_stack+0x74/0x92\nubsan_epilogue+0x9/0x50\nhandle_overflow+0x8d/0xd0\n__ubsan_handle_mul_overflow+0xe/0x10\nnl80211_send_iface+0x688/0x6b0 [cfg80211]\n[...]\ncfg80211_register_wdev+0x78/0xb0 [cfg80211]\ncfg80211_netdev_notifier_call+0x200/0x620 [cfg80211]\n[...]\nieee80211_if_add+0x60e/0x8f0 [mac80211]\nieee80211_register_hw+0xda5/0x1170 [mac80211]\nIn this case, simply return an error instead, to indicate\nthat no data is available.

In the Linux kernel, the following vulnerability has been resolved:\nscsi: ibmvfc: Remove BUG_ON in the case of an empty event pool\nIn practice the driver should never send more commands than are allocated\nto a queue's event pool. In the unlikely event that this happens, the code\nasserts a BUG_ON, and in the case that the kernel is not configured to\ncrash on panic returns a junk event pointer from the empty event list\ncausing things to spiral from there. This BUG_ON is a historical artifact\nof the ibmvfc driver first being upstreamed, and it is well known now that\nthe use of BUG_ON is bad practice except in the most unrecoverable\nscenario. There is nothing about this scenario that prevents the driver\nfrom recovering and carrying on.\nRemove the BUG_ON in question from ibmvfc_get_event() and return a NULL\npointer in the case of an empty event pool. Update all call sites to\nibmvfc_get_event() to check for a NULL pointer and perfrom the appropriate\nfailure or recovery action.

In the Linux kernel, the following vulnerability has been resolved:\nSUNRPC: Fix RPC client cleaned up the freed pipefs dentries\nRPC client pipefs dentries cleanup is in separated rpc_remove_pipedir()\nworkqueue,which takes care about pipefs superblock locking.\nIn some special scenarios, when kernel frees the pipefs sb of the\ncurrent client and immediately alloctes a new pipefs sb,\nrpc_remove_pipedir function would misjudge the existence of pipefs\nsb which is not the one it used to hold. As a result,\nthe rpc_remove_pipedir would clean the released freed pipefs dentries.\nTo fix this issue, rpc_remove_pipedir should check whether the\ncurrent pipefs sb is consistent with the original pipefs sb.\nThis error can be catched by KASAN:\n=========================================================\n[ 250.497700] BUG: KASAN: slab-use-after-free in dget_parent+0x195/0x200\n[ 250.498315] Read of size 4 at addr ffff88800a2ab804 by task kworker/0:18/106503\n[ 250.500549] Workqueue: events rpc_free_client_work\n[ 250.501001] Call Trace:\n[ 250.502880] kasan_report+0xb6/0xf0\n[ 250.503209] ? dget_parent+0x195/0x200\n[ 250.503561] dget_parent+0x195/0x200\n[ 250.503897] ? __pfx_rpc_clntdir_depopulate+0x10/0x10\n[ 250.504384] rpc_rmdir_depopulate+0x1b/0x90\n[ 250.504781] rpc_remove_client_dir+0xf5/0x150\n[ 250.505195] rpc_free_client_work+0xe4/0x230\n[ 250.505598] process_one_work+0x8ee/0x13b0\n...\n[ 22.039056] Allocated by task 244:\n[ 22.039390] kasan_save_stack+0x22/0x50\n[ 22.039758] kasan_set_track+0x25/0x30\n[ 22.040109] __kasan_slab_alloc+0x59/0x70\n[ 22.040487] kmem_cache_alloc_lru+0xf0/0x240\n[ 22.040889] __d_alloc+0x31/0x8e0\n[ 22.041207] d_alloc+0x44/0x1f0\n[ 22.041514] __rpc_lookup_create_exclusive+0x11c/0x140\n[ 22.041987] rpc_mkdir_populate.constprop.0+0x5f/0x110\n[ 22.042459] rpc_create_client_dir+0x34/0x150\n[ 22.042874] rpc_setup_pipedir_sb+0x102/0x1c0\n[ 22.043284] rpc_client_register+0x136/0x4e0\n[ 22.043689] rpc_new_client+0x911/0x1020\n[ 22.044057] rpc_create_xprt+0xcb/0x370\n[ 22.044417] rpc_create+0x36b/0x6c0\n...\n[ 22.049524] Freed by task 0:\n[ 22.049803] kasan_save_stack+0x22/0x50\n[ 22.050165] kasan_set_track+0x25/0x30\n[ 22.050520] kasan_save_free_info+0x2b/0x50\n[ 22.050921] __kasan_slab_free+0x10e/0x1a0\n[ 22.051306] kmem_cache_free+0xa5/0x390\n[ 22.051667] rcu_core+0x62c/0x1930\n[ 22.051995] __do_softirq+0x165/0x52a\n[ 22.052347]\n[ 22.052503] Last potentially related work creation:\n[ 22.052952] kasan_save_stack+0x22/0x50\n[ 22.053313] __kasan_record_aux_stack+0x8e/0xa0\n[ 22.053739] __call_rcu_common.constprop.0+0x6b/0x8b0\n[ 22.054209] dentry_free+0xb2/0x140\n[ 22.054540] __dentry_kill+0x3be/0x540\n[ 22.054900] shrink_dentry_list+0x199/0x510\n[ 22.055293] shrink_dcache_parent+0x190/0x240\n[ 22.055703] do_one_tree+0x11/0x40\n[ 22.056028] shrink_dcache_for_umount+0x61/0x140\n[ 22.056461] generic_shutdown_super+0x70/0x590\n[ 22.056879] kill_anon_super+0x3a/0x60\n[ 22.057234] rpc_kill_sb+0x121/0x200

In the Linux kernel, the following vulnerability has been resolved:\nipvlan: add ipvlan_route_v6_outbound() helper\nInspired by syzbot reports using a stack of multiple ipvlan devices.\nReduce stack size needed in ipvlan_process_v6_outbound() by moving\nthe flowi6 struct used for the route lookup in an non inlined\nhelper. ipvlan_route_v6_outbound() needs 120 bytes on the stack,\nimmediately reclaimed.\nAlso make sure ipvlan_process_v4_outbound() is not inlined.\nWe might also have to lower MAX_NEST_DEV, because only syzbot uses\nsetups with more than four stacked devices.\nBUG: TASK stack guard page was hit at ffffc9000e803ff8 (stack is ffffc9000e804000..ffffc9000e808000)\nstack guard page: 0000 [#1] SMP KASAN\nCPU: 0 PID: 13442 Comm: syz-executor.4 Not tainted 6.1.52-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023\nRIP: 0010:kasan_check_range+0x4/0x2a0 mm/kasan/generic.c:188\nCode: 48 01 c6 48 89 c7 e8 db 4e c1 03 31 c0 5d c3 cc 0f 0b eb 02 0f 0b b8 ea ff ff ff 5d c3 cc 00 00 cc cc 00 00 cc cc 55 48 89 e5 <41> 57 41 56 41 55 41 54 53 b0 01 48 85 f6 0f 84 a4 01 00 00 48 89\nRSP: 0018:ffffc9000e804000 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817e5bf2\nRDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff887c6568\nRBP: ffffc9000e804000 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff92001d0080c\nR13: dffffc0000000000 R14: ffffffff87e6b100 R15: 0000000000000000\nFS: 00007fd0c55826c0(0000) GS:ffff8881f6800000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffc9000e803ff8 CR3: 0000000170ef7000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n<#DF>\n\n\n[] __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31\n[] instrument_atomic_read include/linux/instrumented.h:72 [inline]\n[] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]\n[] cpumask_test_cpu include/linux/cpumask.h:506 [inline]\n[] cpu_online include/linux/cpumask.h:1092 [inline]\n[] trace_lock_acquire include/trace/events/lock.h:24 [inline]\n[] lock_acquire+0xe2/0x590 kernel/locking/lockdep.c:5632\n[] rcu_lock_acquire+0x2e/0x40 include/linux/rcupdate.h:306\n[] rcu_read_lock include/linux/rcupdate.h:747 [inline]\n[] ip6_pol_route+0x15d/0x1440 net/ipv6/route.c:2221\n[] ip6_pol_route_output+0x50/0x80 net/ipv6/route.c:2606\n[] pol_lookup_func include/net/ip6_fib.h:584 [inline]\n[] fib6_rule_lookup+0x265/0x620 net/ipv6/fib6_rules.c:116\n[] ip6_route_output_flags_noref+0x2d9/0x3a0 net/ipv6/route.c:2638\n[] ip6_route_output_flags+0xca/0x340 net/ipv6/route.c:2651\n[] ip6_route_output include/net/ip6_route.h:100 [inline]\n[] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:473 [inline]\n[] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline]\n[] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]\n[] ipvlan_queue_xmit+0xc33/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677\n[] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229\n[] netdev_start_xmit include/linux/netdevice.h:4966 [inline]\n[] xmit_one net/core/dev.c:3644 [inline]\n[] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660\n[] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324\n[] dev_queue_xmit include/linux/netdevice.h:3067 [inline]\n[] neigh_hh_output include/net/neighbour.h:529 [inline]\n[

In the Linux kernel, the following vulnerability has been resolved:\ni2c: core: Run atomic i2c xfer when !preemptible\nSince bae1d3a05a8b, i2c transfers are non-atomic if preemption is\ndisabled. However, non-atomic i2c transfers require preemption (e.g. in\nwait_for_completion() while waiting for the DMA).\npanic() calls preempt_disable_notrace() before calling\nemergency_restart(). Therefore, if an i2c device is used for the\nrestart, the xfer should be atomic. This avoids warnings like:\n[ 12.667612] WARNING: CPU: 1 PID: 1 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x33c/0x6b0\n[ 12.676926] Voluntary context switch within RCU read-side critical section!\n...\n[ 12.742376] schedule_timeout from wait_for_completion_timeout+0x90/0x114\n[ 12.749179] wait_for_completion_timeout from tegra_i2c_wait_completion+0x40/0x70\n...\n[ 12.994527] atomic_notifier_call_chain from machine_restart+0x34/0x58\n[ 13.001050] machine_restart from panic+0x2a8/0x32c\nUse !preemptible() instead, which is basically the same check as\npre-v5.2.

In the Linux kernel, the following vulnerability has been resolved:\nbonding: stop the device in bond_setup_by_slave()\nCommit 9eed321cde22 ("net: lapbether: only support ethernet devices")\nhas been able to keep syzbot away from net/lapb, until today.\nIn the following splat [1], the issue is that a lapbether device has\nbeen created on a bonding device without members. Then adding a non\nARPHRD_ETHER member forced the bonding master to change its type.\nThe fix is to make sure we call dev_close() in bond_setup_by_slave()\nso that the potential linked lapbether devices (or any other devices\nhaving assumptions on the physical device) are removed.\nA similar bug has been addressed in commit 40baec225765\n("bonding: fix panic on non-ARPHRD_ETHER enslave failure")\n[1]\nskbuff: skb_under_panic: text:ffff800089508810 len:44 put:40 head:ffff0000c78e7c00 data:ffff0000c78e7bea tail:0x16 end:0x140 dev:bond0\nkernel BUG at net/core/skbuff.c:192 !\nInternal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP\nModules linked in:\nCPU: 0 PID: 6007 Comm: syz-executor383 Not tainted 6.6.0-rc3-syzkaller-gbf6547d8715b #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023\npstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : skb_panic net/core/skbuff.c:188 [inline]\npc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202\nlr : skb_panic net/core/skbuff.c:188 [inline]\nlr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202\nsp : ffff800096a06aa0\nx29: ffff800096a06ab0 x28: ffff800096a06ba0 x27: dfff800000000000\nx26: ffff0000ce9b9b50 x25: 0000000000000016 x24: ffff0000c78e7bea\nx23: ffff0000c78e7c00 x22: 000000000000002c x21: 0000000000000140\nx20: 0000000000000028 x19: ffff800089508810 x18: ffff800096a06100\nx17: 0000000000000000 x16: ffff80008a629a3c x15: 0000000000000001\nx14: 1fffe00036837a32 x13: 0000000000000000 x12: 0000000000000000\nx11: 0000000000000201 x10: 0000000000000000 x9 : cb50b496c519aa00\nx8 : cb50b496c519aa00 x7 : 0000000000000001 x6 : 0000000000000001\nx5 : ffff800096a063b8 x4 : ffff80008e280f80 x3 : ffff8000805ad11c\nx2 : 0000000000000001 x1 : 0000000100000201 x0 : 0000000000000086\nCall trace:\nskb_panic net/core/skbuff.c:188 [inline]\nskb_under_panic+0x13c/0x140 net/core/skbuff.c:202\nskb_push+0xf0/0x108 net/core/skbuff.c:2446\nip6gre_header+0xbc/0x738 net/ipv6/ip6_gre.c:1384\ndev_hard_header include/linux/netdevice.h:3136 [inline]\nlapbeth_data_transmit+0x1c4/0x298 drivers/net/wan/lapbether.c:257\nlapb_data_transmit+0x8c/0xb0 net/lapb/lapb_iface.c:447\nlapb_transmit_buffer+0x178/0x204 net/lapb/lapb_out.c:149\nlapb_send_control+0x220/0x320 net/lapb/lapb_subr.c:251\n__lapb_disconnect_request+0x9c/0x17c net/lapb/lapb_iface.c:326\nlapb_device_event+0x288/0x4e0 net/lapb/lapb_iface.c:492\nnotifier_call_chain+0x1a4/0x510 kernel/notifier.c:93\nraw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461\ncall_netdevice_notifiers_info net/core/dev.c:1970 [inline]\ncall_netdevice_notifiers_extack net/core/dev.c:2008 [inline]\ncall_netdevice_notifiers net/core/dev.c:2022 [inline]\n__dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508\ndev_close_many+0x1e0/0x470 net/core/dev.c:1559\ndev_close+0x174/0x250 net/core/dev.c:1585\nlapbeth_device_event+0x2e4/0x958 drivers/net/wan/lapbether.c:466\nnotifier_call_chain+0x1a4/0x510 kernel/notifier.c:93\nraw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461\ncall_netdevice_notifiers_info net/core/dev.c:1970 [inline]\ncall_netdevice_notifiers_extack net/core/dev.c:2008 [inline]\ncall_netdevice_notifiers net/core/dev.c:2022 [inline]\n__dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508\ndev_close_many+0x1e0/0x470 net/core/dev.c:1559\ndev_close+0x174/0x250 net/core/dev.c:1585\nbond_enslave+0x2298/0x30cc drivers/net/bonding/bond_main.c:2332\nbond_do_ioctl+0x268/0xc64 drivers/net/bonding/bond_main.c:4539\ndev_ifsioc+0x754/0x9ac\ndev_ioctl+0x4d8/0xd34 net/core/dev_ioctl.c:786\nsock_do_ioctl+0x1d4/0x2d0 net/socket.c:1217\nsock_ioctl+0x4e8/0x834 net/socket.c:1322\nvfs_ioctl fs/ioctl.c:51 [inline]\n__do_\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\nwifi: ath11k: fix gtk offload status event locking\nThe ath11k active pdevs are protected by RCU but the gtk offload status\nevent handling code calling ath11k_mac_get_arvif_by_vdev_id() was not\nmarked as a read-side critical section.\nMark the code in question as an RCU read-side critical section to avoid\nany potential use-after-free issues.\nCompile tested only.

In the Linux kernel, the following vulnerability has been resolved:\nnet/smc: avoid data corruption caused by decline\nWe found a data corruption issue during testing of SMC-R on Redis\napplications.\nThe benchmark has a low probability of reporting a strange error as\nshown below.\n"Error: Protocol error, got "\\xe2" as reply type byte"\nFinally, we found that the retrieved error data was as follows:\n0xE2 0xD4 0xC3 0xD9 0x04 0x00 0x2C 0x20 0xA6 0x56 0x00 0x16 0x3E 0x0C\n0xCB 0x04 0x02 0x01 0x00 0x00 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00\n0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xE2\nIt is quite obvious that this is a SMC DECLINE message, which means that\nthe applications received SMC protocol message.\nWe found that this was caused by the following situations:\nclient server\n¦ clc proposal\n------------->\n¦ clc accept\n<-------------\n¦ clc confirm\n------------->\nwait llc confirm\nsend llc confirm\n¦failed llc confirm\n¦ x------\n(after 2s)timeout\nwait llc confirm rsp\nwait decline\n(after 1s) timeout\n(after 2s) timeout\n¦ decline\n-------------->\n¦ decline\n<--------------\nAs a result, a decline message was sent in the implementation, and this\nmessage was read from TCP by the already-fallback connection.\nThis patch double the client timeout as 2x of the server value,\nWith this simple change, the Decline messages should never cross or\ncollide (during Confirm link timeout).\nThis issue requires an immediate solution, since the protocol updates\ninvolve a more long-term solution.

In the Linux kernel, the following vulnerability has been resolved:\nmedia: gspca: cpia1: shift-out-of-bounds in set_flicker\nSyzkaller reported the following issue:\nUBSAN: shift-out-of-bounds in drivers/media/usb/gspca/cpia1.c:1031:27\nshift exponent 245 is too large for 32-bit type 'int'\nWhen the value of the variable "sd->params.exposure.gain" exceeds the\nnumber of bits in an integer, a shift-out-of-bounds error is reported. It\nis triggered because the variable "currentexp" cannot be left-shifted by\nmore than the number of bits in an integer. In order to avoid invalid\nrange during left-shift, the conditional expression is added.

In the Linux kernel, the following vulnerability has been resolved:\nvirtio-blk: fix implicit overflow on virtio_max_dma_size\nThe following codes have an implicit conversion from size_t to u32:\n(u32)max_size = (size_t)virtio_max_dma_size(vdev);\nThis may lead overflow, Ex (size_t)4G -> (u32)0. Once\nvirtio_max_dma_size() has a larger size than U32_MAX, use U32_MAX\ninstead.

This CVE ID has been rejected or withdrawn by its CVE Numbering Authority for the following reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:\nmmc: sdio: fix possible resource leaks in some error paths\nIf sdio_add_func() or sdio_init_func() fails, sdio_remove_func() can\nnot release the resources, because the sdio function is not presented\nin these two cases, it won't call of_node_put() or put_device().\nTo fix these leaks, make sdio_func_present() only control whether\ndevice_del() needs to be called or not, then always call of_node_put()\nand put_device().\nIn error case in sdio_init_func(), the reference of 'card->dev' is\nnot get, to avoid redundant put in sdio_free_func_cis(), move the\nget_device() to sdio_alloc_func() and put_device() to sdio_release_func(),\nit can keep the get/put function be balanced.\nWithout this patch, while doing fault inject test, it can get the\nfollowing leak reports, after this fix, the leak is gone.\nunreferenced object 0xffff888112514000 (size 2048):\ncomm "kworker/3:2", pid 65, jiffies 4294741614 (age 124.774s)\nhex dump (first 32 bytes):\n00 e0 6f 12 81 88 ff ff 60 58 8d 06 81 88 ff ff ..o.....`X......\n10 40 51 12 81 88 ff ff 10 40 51 12 81 88 ff ff .@Q......@Q.....\nbacktrace:\n[<000000009e5931da>] kmalloc_trace+0x21/0x110\n[<000000002f839ccb>] mmc_alloc_card+0x38/0xb0 [mmc_core]\n[<0000000004adcbf6>] mmc_sdio_init_card+0xde/0x170 [mmc_core]\n[<000000007538fea0>] mmc_attach_sdio+0xcb/0x1b0 [mmc_core]\n[<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core]\nunreferenced object 0xffff888112511000 (size 2048):\ncomm "kworker/3:2", pid 65, jiffies 4294741623 (age 124.766s)\nhex dump (first 32 bytes):\n00 40 51 12 81 88 ff ff e0 58 8d 06 81 88 ff ff .@Q......X......\n10 10 51 12 81 88 ff ff 10 10 51 12 81 88 ff ff ..Q.......Q.....\nbacktrace:\n[<000000009e5931da>] kmalloc_trace+0x21/0x110\n[<00000000fcbe706c>] sdio_alloc_func+0x35/0x100 [mmc_core]\n[<00000000c68f4b50>] mmc_attach_sdio.cold.18+0xb1/0x395 [mmc_core]\n[<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core]

In the Linux kernel, the following vulnerability has been resolved:\nsched/psi: Fix use-after-free in ep_remove_wait_queue()\nIf a non-root cgroup gets removed when there is a thread that registered\ntrigger and is polling on a pressure file within the cgroup, the polling\nwaitqueue gets freed in the following path:\ndo_rmdir\ncgroup_rmdir\nkernfs_drain_open_files\ncgroup_file_release\ncgroup_pressure_release\npsi_trigger_destroy\nHowever, the polling thread still has a reference to the pressure file and\nwill access the freed waitqueue when the file is closed or upon exit:\nfput\nep_eventpoll_release\nep_free\nep_remove_wait_queue\nremove_wait_queue\nThis results in use-after-free as pasted below.\nThe fundamental problem here is that cgroup_file_release() (and\nconsequently waitqueue's lifetime) is not tied to the file's real lifetime.\nUsing wake_up_pollfree() here might be less than ideal, but it is in line\nwith the comment at commit 42288cb44c4b ("wait: add wake_up_pollfree()")\nsince the waitqueue's lifetime is not tied to file's one and can be\nconsidered as another special case. While this would be fixable by somehow\nmaking cgroup_file_release() be tied to the fput(), it would require\nsizable refactoring at cgroups or higher layer which might be more\njustifiable if we identify more cases like this.\nBUG: KASAN: use-after-free in _raw_spin_lock_irqsave+0x60/0xc0\nWrite of size 4 at addr ffff88810e625328 by task a.out/4404\nCPU: 19 PID: 4404 Comm: a.out Not tainted 6.2.0-rc6 #38\nHardware name: Amazon EC2 c5a.8xlarge/, BIOS 1.0 10/16/2017\nCall Trace:\n\ndump_stack_lvl+0x73/0xa0\nprint_report+0x16c/0x4e0\nkasan_report+0xc3/0xf0\nkasan_check_range+0x2d2/0x310\n_raw_spin_lock_irqsave+0x60/0xc0\nremove_wait_queue+0x1a/0xa0\nep_free+0x12c/0x170\nep_eventpoll_release+0x26/0x30\n__fput+0x202/0x400\ntask_work_run+0x11d/0x170\ndo_exit+0x495/0x1130\ndo_group_exit+0x100/0x100\nget_signal+0xd67/0xde0\narch_do_signal_or_restart+0x2a/0x2b0\nexit_to_user_mode_prepare+0x94/0x100\nsyscall_exit_to_user_mode+0x20/0x40\ndo_syscall_64+0x52/0x90\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nAllocated by task 4404:\nkasan_set_track+0x3d/0x60\n__kasan_kmalloc+0x85/0x90\npsi_trigger_create+0x113/0x3e0\npressure_write+0x146/0x2e0\ncgroup_file_write+0x11c/0x250\nkernfs_fop_write_iter+0x186/0x220\nvfs_write+0x3d8/0x5c0\nksys_write+0x90/0x110\ndo_syscall_64+0x43/0x90\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\nFreed by task 4407:\nkasan_set_track+0x3d/0x60\nkasan_save_free_info+0x27/0x40\n____kasan_slab_free+0x11d/0x170\nslab_free_freelist_hook+0x87/0x150\n__kmem_cache_free+0xcb/0x180\npsi_trigger_destroy+0x2e8/0x310\ncgroup_file_release+0x4f/0xb0\nkernfs_drain_open_files+0x165/0x1f0\nkernfs_drain+0x162/0x1a0\n__kernfs_remove+0x1fb/0x310\nkernfs_remove_by_name_ns+0x95/0xe0\ncgroup_addrm_files+0x67f/0x700\ncgroup_destroy_locked+0x283/0x3c0\ncgroup_rmdir+0x29/0x100\nkernfs_iop_rmdir+0xd1/0x140\nvfs_rmdir+0xfe/0x240\ndo_rmdir+0x13d/0x280\n__x64_sys_rmdir+0x2c/0x30\ndo_syscall_64+0x43/0x90\nentry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:\nof: Fix double free in of_parse_phandle_with_args_map\nIn of_parse_phandle_with_args_map() the inner loop that\niterates through the map entries calls of_node_put(new)\nto free the reference acquired by the previous iteration\nof the inner loop. This assumes that the value of "new" is\nNULL on the first iteration of the inner loop.\nMake sure that this is true in all iterations of the outer\nloop by setting "new" to NULL after its value is assigned to "cur".\nExtend the unittest to detect the double free and add an additional\ntest case that actually triggers this path.

In the Linux kernel, the following vulnerability has been resolved:\ndrm/vmwgfx: fix a memleak in vmw_gmrid_man_get_node\nWhen ida_alloc_max fails, resources allocated before should be freed,\nincluding *res allocated by kmalloc and ttm_resource_init.

In the Linux kernel, the following vulnerability has been resolved:\nRevert "net/mlx5: Block entering switchdev mode with ns inconsistency"\nThis reverts commit 662404b24a4c4d839839ed25e3097571f5938b9b.\nThe revert is required due to the suspicion it is not good for anything\nand cause crash.

In the Linux kernel, the following vulnerability has been resolved:\nSUNRPC: fix a memleak in gss_import_v2_context\nThe ctx->mech_used.data allocated by kmemdup is not freed in neither\ngss_import_v2_context nor it only caller gss_krb5_import_sec_context,\nwhich frees ctx on error.\nThus, this patch reform the last call of gss_import_v2_context to the\ngss_krb5_import_ctx_v2, preventing the memleak while keepping the return\nformation.

In the Linux kernel, the following vulnerability has been resolved:\ndrm/vmwgfx: Unmap the surface before resetting it on a plane state\nSwitch to a new plane state requires unreferencing of all held surfaces.\nIn the work required for mob cursors the mapped surfaces started being\ncached but the variable indicating whether the surface is currently\nmapped was not being reset. This leads to crashes as the duplicated\nstate, incorrectly, indicates the that surface is mapped even when\nno surface is present. That's because after unreferencing the surface\nit's perfectly possible for the plane to be backed by a bo instead of a\nsurface.\nReset the surface mapped flag when unreferencing the plane state surface\nto fix null derefs in cleanup. Fixes crashes in KDE KWin 6.0 on Wayland:\nOops: 0000 [#1] PREEMPT SMP PTI\nCPU: 4 PID: 2533 Comm: kwin_wayland Not tainted 6.7.0-rc3-vmwgfx #2\nHardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020\nRIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx]\nCode: 00 00 00 75 3a 48 83 c4 10 5b 5d c3 cc cc cc cc 48 8b b3 a8 00 00 00 48 c7 c7 99 90 43 c0 e8 93 c5 db ca 48 8b 83 a8 00 00 00 <48> 8b 78 28 e8 e3 f>\nRSP: 0018:ffffb6b98216fa80 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff969d84cdcb00 RCX: 0000000000000027\nRDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff969e75f21600\nRBP: ffff969d4143dc50 R08: 0000000000000000 R09: ffffb6b98216f920\nR10: 0000000000000003 R11: ffff969e7feb3b10 R12: 0000000000000000\nR13: 0000000000000000 R14: 000000000000027b R15: ffff969d49c9fc00\nFS: 00007f1e8f1b4180(0000) GS:ffff969e75f00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000028 CR3: 0000000104006004 CR4: 00000000003706f0\nCall Trace:\n\n? __die+0x23/0x70\n? page_fault_oops+0x171/0x4e0\n? exc_page_fault+0x7f/0x180\n? asm_exc_page_fault+0x26/0x30\n? vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx]\ndrm_atomic_helper_cleanup_planes+0x9b/0xc0\ncommit_tail+0xd1/0x130\ndrm_atomic_helper_commit+0x11a/0x140\ndrm_atomic_commit+0x97/0xd0\n? __pfx___drm_printfn_info+0x10/0x10\ndrm_atomic_helper_update_plane+0xf5/0x160\ndrm_mode_cursor_universal+0x10e/0x270\ndrm_mode_cursor_common+0x102/0x230\n? __pfx_drm_mode_cursor2_ioctl+0x10/0x10\ndrm_ioctl_kernel+0xb2/0x110\ndrm_ioctl+0x26d/0x4b0\n? __pfx_drm_mode_cursor2_ioctl+0x10/0x10\n? __pfx_drm_ioctl+0x10/0x10\nvmw_generic_ioctl+0xa4/0x110 [vmwgfx]\n__x64_sys_ioctl+0x94/0xd0\ndo_syscall_64+0x61/0xe0\n? __x64_sys_ioctl+0xaf/0xd0\n? syscall_exit_to_user_mode+0x2b/0x40\n? do_syscall_64+0x70/0xe0\n? __x64_sys_ioctl+0xaf/0xd0\n? syscall_exit_to_user_mode+0x2b/0x40\n? do_syscall_64+0x70/0xe0\n? exc_page_fault+0x7f/0x180\nentry_SYSCALL_64_after_hwframe+0x6e/0x76\nRIP: 0033:0x7f1e93f279ed\nCode: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff f>\nRSP: 002b:00007ffca0faf600 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: ffffffffffffffda RBX: 000055db876ed2c0 RCX: 00007f1e93f279ed\nRDX: 00007ffca0faf6c0 RSI: 00000000c02464bb RDI: 0000000000000015\nRBP: 00007ffca0faf650 R08: 000055db87184010 R09: 0000000000000007\nR10: 000055db886471a0 R11: 0000000000000246 R12: 00007ffca0faf6c0\nR13: 00000000c02464bb R14: 0000000000000015 R15: 00007ffca0faf790\n\nModules linked in: snd_seq_dummy snd_hrtimer nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_ine>\nCR2: 0000000000000028\n---[ end trace 0000000000000000 ]---\nRIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx]\nCode: 00 00 00 75 3a 48 83 c4 10 5b 5d c3 cc cc cc cc 48 8b b3 a8 00 00 00 48 c7 c7 99 90 43 c0 e8 93 c5 db ca 48 8b 83 a8 00 00 00 <48> 8b 78 28 e8 e3 f>\nRSP: 0018:ffffb6b98216fa80 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff969d84cdcb00 RCX: 0000000000000027\nRDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff969e75f21600\nRBP: ffff969d4143\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\nSUNRPC: Fix a suspicious RCU usage warning\nI received the following warning while running cthon against an ontap\nserver running pNFS:\n[ 57.202521] =============================\n[ 57.202522] WARNING: suspicious RCU usage\n[ 57.202523] 6.7.0-rc3-g2cc14f52aeb7 #41492 Not tainted\n[ 57.202525] -----------------------------\n[ 57.202525] net/sunrpc/xprtmultipath.c:349 RCU-list traversed in non-reader section!!\n[ 57.202527]\nother info that might help us debug this:\n[ 57.202528]\nrcu_scheduler_active = 2, debug_locks = 1\n[ 57.202529] no locks held by test5/3567.\n[ 57.202530]\nstack backtrace:\n[ 57.202532] CPU: 0 PID: 3567 Comm: test5 Not tainted 6.7.0-rc3-g2cc14f52aeb7 #41492 5b09971b4965c0aceba19f3eea324a4a806e227e\n[ 57.202534] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 2/2/2022\n[ 57.202536] Call Trace:\n[ 57.202537] \n[ 57.202540] dump_stack_lvl+0x77/0xb0\n[ 57.202551] lockdep_rcu_suspicious+0x154/0x1a0\n[ 57.202556] rpc_xprt_switch_has_addr+0x17c/0x190 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]\n[ 57.202596] rpc_clnt_setup_test_and_add_xprt+0x50/0x180 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]\n[ 57.202621] ? rpc_clnt_add_xprt+0x254/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]\n[ 57.202646] rpc_clnt_add_xprt+0x27a/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]\n[ 57.202671] ? __pfx_rpc_clnt_setup_test_and_add_xprt+0x10/0x10 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]\n[ 57.202696] nfs4_pnfs_ds_connect+0x345/0x760 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]\n[ 57.202728] ? __pfx_nfs4_test_session_trunk+0x10/0x10 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]\n[ 57.202754] nfs4_fl_prepare_ds+0x75/0xc0 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a]\n[ 57.202760] filelayout_write_pagelist+0x4a/0x200 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a]\n[ 57.202765] pnfs_generic_pg_writepages+0xbe/0x230 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]\n[ 57.202788] __nfs_pageio_add_request+0x3fd/0x520 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]\n[ 57.202813] nfs_pageio_add_request+0x18b/0x390 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]\n[ 57.202831] nfs_do_writepage+0x116/0x1e0 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]\n[ 57.202849] nfs_writepages_callback+0x13/0x30 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]\n[ 57.202866] write_cache_pages+0x265/0x450\n[ 57.202870] ? __pfx_nfs_writepages_callback+0x10/0x10 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]\n[ 57.202891] nfs_writepages+0x141/0x230 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]\n[ 57.202913] do_writepages+0xd2/0x230\n[ 57.202917] ? filemap_fdatawrite_wbc+0x5c/0x80\n[ 57.202921] filemap_fdatawrite_wbc+0x67/0x80\n[ 57.202924] filemap_write_and_wait_range+0xd9/0x170\n[ 57.202930] nfs_wb_all+0x49/0x180 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]\n[ 57.202947] nfs4_file_flush+0x72/0xb0 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]\n[ 57.202969] __se_sys_close+0x46/0xd0\n[ 57.202972] do_syscall_64+0x68/0x100\n[ 57.202975] ? do_syscall_64+0x77/0x100\n[ 57.202976] ? do_syscall_64+0x77/0x100\n[ 57.202979] entry_SYSCALL_64_after_hwframe+0x6e/0x76\n[ 57.202982] RIP: 0033:0x7fe2b12e4a94\n[ 57.202985] Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 80 3d d5 18 0e 00 00 74 13 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 44 c3 0f 1f 00 48 83 ec 18 89 7c 24 0c e8 c3\n[ 57.202987] RSP: 002b:00007ffe857ddb38 EFLAGS: 00000202 ORIG_RAX: 0000000000000003\n[ 57.202989] RAX: ffffffffffffffda RBX: 00007ffe857dfd68 RCX: 00007fe2b12e4a94\n[ 57.202991] RDX: 0000000000002000 RSI: 00007ffe857ddc40 RDI: 0000000000000003\n[ 57.202992] RBP: 00007ffe857dfc50 R08: 7fffffffffffffff R09: 0000000065650f49\n[ 57.202993] R10: 00007f\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\next4: avoid online resizing failures due to oversized flex bg\nWhen we online resize an ext4 filesystem with a oversized flexbg_size,\nmkfs.ext4 -F -G 67108864 $dev -b 4096 100M\nmount $dev $dir\nresize2fs $dev 16G\nthe following WARN_ON is triggered:\n==================================================================\nWARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550\nModules linked in: sg(E)\nCPU: 0 PID: 427 Comm: resize2fs Tainted: G E 6.6.0-rc5+ #314\nRIP: 0010:__alloc_pages+0x411/0x550\nCall Trace:\n\n__kmalloc_large_node+0xa2/0x200\n__kmalloc+0x16e/0x290\next4_resize_fs+0x481/0xd80\n__ext4_ioctl+0x1616/0x1d90\next4_ioctl+0x12/0x20\n__x64_sys_ioctl+0xf0/0x150\ndo_syscall_64+0x3b/0x90\n==================================================================\nThis is because flexbg_size is too large and the size of the new_group_data\narray to be allocated exceeds MAX_ORDER. Currently, the minimum value of\nMAX_ORDER is 8, the minimum value of PAGE_SIZE is 4096, the corresponding\nmaximum number of groups that can be allocated is:\n(PAGE_SIZE << MAX_ORDER) / sizeof(struct ext4_new_group_data) ≈ 21845\nAnd the value that is down-aligned to the power of 2 is 16384. Therefore,\nthis value is defined as MAX_RESIZE_BG, and the number of groups added\neach time does not exceed this value during resizing, and is added multiple\ntimes to complete the online resizing. The difference is that the metadata\nin a flex_bg may be more dispersed.

In the Linux kernel, the following vulnerability has been resolved:\npstore/ram: Fix crash when setting number of cpus to an odd number\nWhen the number of cpu cores is adjusted to 7 or other odd numbers,\nthe zone size will become an odd number.\nThe address of the zone will become:\naddr of zone0 = BASE\naddr of zone1 = BASE + zone_size\naddr of zone2 = BASE + zone_size*2\n...\nThe address of zone1/3/5/7 will be mapped to non-alignment va.\nEventually crashes will occur when accessing these va.\nSo, use ALIGN_DOWN() to make sure the zone size is even\nto avoid this bug.

In the Linux kernel, the following vulnerability has been resolved:\nwifi: mac80211: fix potential key use-after-free\nWhen ieee80211_key_link() is called by ieee80211_gtk_rekey_add()\nbut returns 0 due to KRACK protection (identical key reinstall),\nieee80211_gtk_rekey_add() will still return a pointer into the\nkey, in a potential use-after-free. This normally doesn't happen\nsince it's only called by iwlwifi in case of WoWLAN rekey offload\nwhich has its own KRACK protection, but still better to fix, do\nthat by returning an error code and converting that to success on\nthe cfg80211 boundary only, leaving the error for bad callers of\nieee80211_gtk_rekey_add().

In the Linux kernel, the following vulnerability has been resolved:\ndrm: Don't unref the same fb many times by mistake due to deadlock handling\nIf we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl()\nwe proceed to unref the fb and then retry the whole thing from the top.\nBut we forget to reset the fb pointer back to NULL, and so if we then\nget another error during the retry, before the fb lookup, we proceed\nthe unref the same fb again without having gotten another reference.\nThe end result is that the fb will (eventually) end up being freed\nwhile it's still in use.\nReset fb to NULL once we've unreffed it to avoid doing it again\nuntil we've done another fb lookup.\nThis turned out to be pretty easy to hit on a DG2 when doing async\nflips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I\nsaw that drm_closefb() simply got stuck in a busy loop while walking\nthe framebuffer list. Fortunately I was able to convince it to oops\ninstead, and from there it was easier to track down the culprit.

In the Linux kernel, the following vulnerability has been resolved:\nice: Fix some null pointer dereference issues in ice_ptp.c\ndevm_kasprintf() returns a pointer to dynamically allocated memory\nwhich can be NULL upon failure.

In the Linux kernel, the following vulnerability has been resolved:\nefivarfs: force RO when remounting if SetVariable is not supported\nIf SetVariable at runtime is not supported by the firmware we never assign\na callback for that function. At the same time mount the efivarfs as\nRO so no one can call that. However, we never check the permission flags\nwhen someone remounts the filesystem as RW. As a result this leads to a\ncrash looking like this:\n$ mount -o remount,rw /sys/firmware/efi/efivars\n$ efi-updatevar -f PK.auth PK\n[ 303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n[ 303.280482] Mem abort info:\n[ 303.280854] ESR = 0x0000000086000004\n[ 303.281338] EC = 0x21: IABT (current EL), IL = 32 bits\n[ 303.282016] SET = 0, FnV = 0\n[ 303.282414] EA = 0, S1PTW = 0\n[ 303.282821] FSC = 0x04: level 0 translation fault\n[ 303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000\n[ 303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000\n[ 303.286076] Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP\n[ 303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6\n[ 303.288586] CPU: 1 PID: 755 Comm: efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1\n[ 303.289748] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023\n[ 303.291150] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 303.292123] pc : 0x0\n[ 303.292443] lr : efivar_set_variable_locked+0x74/0xec\n[ 303.293156] sp : ffff800008673c10\n[ 303.293619] x29: ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000\n[ 303.294592] x26: 0000000000000800 x25: ffff000002467400 x24: 0000000000000027\n[ 303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21: ffff000002467000\n[ 303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000\n[ 303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54\n[ 303.298495] x14: ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4\n[ 303.299453] x11: ffff000002af7b01 x10: 0000000000000003 x9 : 0000000000000002\n[ 303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 : 0000000000a85201\n[ 303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc\n[ 303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000\n[ 303.303341] Call trace:\n[ 303.303679] 0x0\n[ 303.303938] efivar_entry_set_get_size+0x98/0x16c\n[ 303.304585] efivarfs_file_write+0xd0/0x1a4\n[ 303.305148] vfs_write+0xc4/0x2e4\n[ 303.305601] ksys_write+0x70/0x104\n[ 303.306073] __arm64_sys_write+0x1c/0x28\n[ 303.306622] invoke_syscall+0x48/0x114\n[ 303.307156] el0_svc_common.constprop.0+0x44/0xec\n[ 303.307803] do_el0_svc+0x38/0x98\n[ 303.308268] el0_svc+0x2c/0x84\n[ 303.308702] el0t_64_sync_handler+0xf4/0x120\n[ 303.309293] el0t_64_sync+0x190/0x194\n[ 303.309794] Code: ???????? ???????? ???????? ???????? (????????)\n[ 303.310612] ---[ end trace 0000000000000000 ]---\nFix this by adding a .reconfigure() function to the fs operations which\nwe can use to check the requested flags and deny anything that's not RO\nif the firmware doesn't implement SetVariable at runtime.

In the Linux kernel, the following vulnerability has been resolved:\npowerpc/pseries/memhp: Fix access beyond end of drmem array\ndlpar_memory_remove_by_index() may access beyond the bounds of the\ndrmem lmb array when the LMB lookup fails to match an entry with the\ngiven DRC index. When the search fails, the cursor is left pointing to\n&drmem_info->lmbs[drmem_info->n_lmbs], which is one element past the\nlast valid entry in the array. The debug message at the end of the\nfunction then dereferences this pointer:\npr_debug("Failed to hot-remove memory at %llx\\n",\nlmb->base_addr);\nThis was found by inspection and confirmed with KASAN:\npseries-hotplug-mem: Attempting to hot-remove LMB, drc index 1234\n==================================================================\nBUG: KASAN: slab-out-of-bounds in dlpar_memory+0x298/0x1658\nRead of size 8 at addr c000000364e97fd0 by task bash/949\ndump_stack_lvl+0xa4/0xfc (unreliable)\nprint_report+0x214/0x63c\nkasan_report+0x140/0x2e0\n__asan_load8+0xa8/0xe0\ndlpar_memory+0x298/0x1658\nhandle_dlpar_errorlog+0x130/0x1d0\ndlpar_store+0x18c/0x3e0\nkobj_attr_store+0x68/0xa0\nsysfs_kf_write+0xc4/0x110\nkernfs_fop_write_iter+0x26c/0x390\nvfs_write+0x2d4/0x4e0\nksys_write+0xac/0x1a0\nsystem_call_exception+0x268/0x530\nsystem_call_vectored_common+0x15c/0x2ec\nAllocated by task 1:\nkasan_save_stack+0x48/0x80\nkasan_set_track+0x34/0x50\nkasan_save_alloc_info+0x34/0x50\n__kasan_kmalloc+0xd0/0x120\n__kmalloc+0x8c/0x320\nkmalloc_array.constprop.0+0x48/0x5c\ndrmem_init+0x2a0/0x41c\ndo_one_initcall+0xe0/0x5c0\nkernel_init_freeable+0x4ec/0x5a0\nkernel_init+0x30/0x1e0\nret_from_kernel_user_thread+0x14/0x1c\nThe buggy address belongs to the object at c000000364e80000\nwhich belongs to the cache kmalloc-128k of size 131072\nThe buggy address is located 0 bytes to the right of\nallocated 98256-byte region [c000000364e80000, c000000364e97fd0)\n==================================================================\npseries-hotplug-mem: Failed to hot-remove memory at 0\nLog failed lookups with a separate message and dereference the\ncursor only when it points to a valid entry.

Information exposure through microarchitectural state after transient execution from some register files for some Intel(R) Atom(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.

In the Linux kernel, the following vulnerability has been resolved:\nnet: fix information leakage in /proc/net/ptype\nIn one net namespace, after creating a packet socket without binding\nit to a device, users in other net namespaces can observe the new\n`packet_type` added by this packet socket by reading `/proc/net/ptype`\nfile. This is minor information leakage as packet socket is\nnamespace aware.\nAdd a net pointer in `packet_type` to keep the net namespace of\nof corresponding packet socket. In `ptype_seq_show`, this net pointer\nmust be checked when it is not NULL.

In the Linux kernel, the following vulnerability has been resolved:\nblock: Fix wrong offset in bio_truncate()\nbio_truncate() clears the buffer outside of last block of bdev, however\ncurrent bio_truncate() is using the wrong offset of page. So it can\nreturn the uninitialized data.\nThis happened when both of truncated/corrupted FS and userspace (via\nbdev) are trying to read the last of bdev.

In the Linux kernel, the following vulnerability has been resolved:\nnet: amd-xgbe: Fix skb data length underflow\nThere will be BUG_ON() triggered in include/linux/skbuff.h leading to\nintermittent kernel panic, when the skb length underflow is detected.\nFix this by dropping the packet if such length underflows are seen\nbecause of inconsistencies in the hardware descriptors.

In the Linux kernel, the following vulnerability has been resolved:\ni2c: mlxbf: prevent stack overflow in mlxbf_i2c_smbus_start_transaction()\nmemcpy() is called in a loop while 'operation->length' upper bound\nis not checked and 'data_idx' also increments.

In the Linux kernel, the following vulnerability has been resolved:\nnet/sunrpc: fix reference count leaks in rpc_sysfs_xprt_state_change\nThe refcount leak issues take place in an error handling path. When the\n3rd argument buf doesn't match with "offline", "online" or "remove", the\nfunction simply returns -EINVAL and forgets to decrease the reference\ncount of a rpc_xprt object and a rpc_xprt_switch object increased by\nrpc_sysfs_xprt_kobj_get_xprt() and\nrpc_sysfs_xprt_kobj_get_xprt_switch(), causing reference count leaks of\nboth unused objects.\nFix this issue by jumping to the error handling path labelled with\nout_put when buf matches none of "offline", "online" or "remove".

In the Linux kernel, the following vulnerability has been resolved:\novl: fix warning in ovl_create_real()\nSyzbot triggered the following warning in ovl_workdir_create() ->\novl_create_real():\nif (!err && WARN_ON(!newdentry->d_inode)) {\nThe reason is that the cgroup2 filesystem returns from mkdir without\ninstantiating the new dentry.\nWeird filesystems such as this will be rejected by overlayfs at a later\nstage during setup, but to prevent such a warning, call ovl_mkdir_real()\ndirectly from ovl_workdir_create() and reject this case early.

In the Linux kernel, the following vulnerability has been resolved:\nethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port()\nThe if statement:\nif (port >= DSAF_GE_NUM)\nreturn;\nlimits the value of port less than DSAF_GE_NUM (i.e., 8).\nHowever, if the value of port is 6 or 7, an array overflow could occur:\nport_rst_off = dsaf_dev->mac_cb[port]->port_rst_off;\nbecause the length of dsaf_dev->mac_cb is DSAF_MAX_PORT_NUM (i.e., 6).\nTo fix this possible array overflow, we first check port and if it is\ngreater than or equal to DSAF_MAX_PORT_NUM, the function returns.

In the Linux kernel, the following vulnerability has been resolved:\nmm: khugepaged: skip huge page collapse for special files\nThe read-only THP for filesystems will collapse THP for files opened\nreadonly and mapped with VM_EXEC. The intended usecase is to avoid TLB\nmisses for large text segments. But it doesn't restrict the file types\nso a THP could be collapsed for a non-regular file, for example, block\ndevice, if it is opened readonly and mapped with EXEC permission. This\nmay cause bugs, like [1] and [2].\nThis is definitely not the intended usecase, so just collapse THP for\nregular files in order to close the attack surface.\n[shy828301@gmail.com: fix vm_file check [3]]

In the Linux kernel, the following vulnerability has been resolved:\nisdn: mISDN: Fix sleeping function called from invalid context\nThe driver can call card->isac.release() function from an atomic\ncontext.\nFix this by calling this function after releasing the lock.\nThe following log reveals it:\n[ 44.168226 ] BUG: sleeping function called from invalid context at kernel/workqueue.c:3018\n[ 44.168941 ] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 5475, name: modprobe\n[ 44.169574 ] INFO: lockdep is turned off.\n[ 44.169899 ] irq event stamp: 0\n[ 44.170160 ] hardirqs last enabled at (0): [<0000000000000000>] 0x0\n[ 44.170627 ] hardirqs last disabled at (0): [] copy_process+0x132d/0x3e00\n[ 44.171240 ] softirqs last enabled at (0): [] copy_process+0x135a/0x3e00\n[ 44.171852 ] softirqs last disabled at (0): [<0000000000000000>] 0x0\n[ 44.172318 ] Preemption disabled at:\n[ 44.172320 ] [] nj_release+0x69/0x500 [netjet]\n[ 44.174441 ] Call Trace:\n[ 44.174630 ] dump_stack_lvl+0xa8/0xd1\n[ 44.174912 ] dump_stack+0x15/0x17\n[ 44.175166 ] ___might_sleep+0x3a2/0x510\n[ 44.175459 ] ? nj_release+0x69/0x500 [netjet]\n[ 44.175791 ] __might_sleep+0x82/0xe0\n[ 44.176063 ] ? start_flush_work+0x20/0x7b0\n[ 44.176375 ] start_flush_work+0x33/0x7b0\n[ 44.176672 ] ? trace_irq_enable_rcuidle+0x85/0x170\n[ 44.177034 ] ? kasan_quarantine_put+0xaa/0x1f0\n[ 44.177372 ] ? kasan_quarantine_put+0xaa/0x1f0\n[ 44.177711 ] __flush_work+0x11a/0x1a0\n[ 44.177991 ] ? flush_work+0x20/0x20\n[ 44.178257 ] ? lock_release+0x13c/0x8f0\n[ 44.178550 ] ? __kasan_check_write+0x14/0x20\n[ 44.178872 ] ? do_raw_spin_lock+0x148/0x360\n[ 44.179187 ] ? read_lock_is_recursive+0x20/0x20\n[ 44.179530 ] ? __kasan_check_read+0x11/0x20\n[ 44.179846 ] ? do_raw_spin_unlock+0x55/0x900\n[ 44.180168 ] ? ____kasan_slab_free+0x116/0x140\n[ 44.180505 ] ? _raw_spin_unlock_irqrestore+0x41/0x60\n[ 44.180878 ] ? skb_queue_purge+0x1a3/0x1c0\n[ 44.181189 ] ? kfree+0x13e/0x290\n[ 44.181438 ] flush_work+0x17/0x20\n[ 44.181695 ] mISDN_freedchannel+0xe8/0x100\n[ 44.182006 ] isac_release+0x210/0x260 [mISDNipac]\n[ 44.182366 ] nj_release+0xf6/0x500 [netjet]\n[ 44.182685 ] nj_remove+0x48/0x70 [netjet]\n[ 44.182989 ] pci_device_remove+0xa9/0x250

In the Linux kernel, the following vulnerability has been resolved:\nuserfaultfd: fix a race between writeprotect and exit_mmap()\nA race is possible when a process exits, its VMAs are removed by\nexit_mmap() and at the same time userfaultfd_writeprotect() is called.\nThe race was detected by KASAN on a development kernel, but it appears\nto be possible on vanilla kernels as well.\nUse mmget_not_zero() to prevent the race as done in other userfaultfd\noperations.

In the Linux kernel, the following vulnerability has been resolved:\nnetfilter: conntrack: serialize hash resizes and cleanups\nSyzbot was able to trigger the following warning [1]\nNo repro found by syzbot yet but I was able to trigger similar issue\nby having 2 scripts running in parallel, changing conntrack hash sizes,\nand:\nfor j in `seq 1 1000` ; do unshare -n /bin/true >/dev/null ; done\nIt would take more than 5 minutes for net_namespace structures\nto be cleaned up.\nThis is because nf_ct_iterate_cleanup() has to restart everytime\na resize happened.\nBy adding a mutex, we can serialize hash resizes and cleanups\nand also make get_next_corpse() faster by skipping over empty\nbuckets.\nEven without resizes in the picture, this patch considerably\nspeeds up network namespace dismantles.\n[1]\nINFO: task syz-executor.0:8312 can't die for more than 144 seconds.\ntask:syz-executor.0 state:R running task stack:25672 pid: 8312 ppid: 6573 flags:0x00004006\nCall Trace:\ncontext_switch kernel/sched/core.c:4955 [inline]\n__schedule+0x940/0x26f0 kernel/sched/core.c:6236\npreempt_schedule_common+0x45/0xc0 kernel/sched/core.c:6408\npreempt_schedule_thunk+0x16/0x18 arch/x86/entry/thunk_64.S:35\n__local_bh_enable_ip+0x109/0x120 kernel/softirq.c:390\nlocal_bh_enable include/linux/bottom_half.h:32 [inline]\nget_next_corpse net/netfilter/nf_conntrack_core.c:2252 [inline]\nnf_ct_iterate_cleanup+0x15a/0x450 net/netfilter/nf_conntrack_core.c:2275\nnf_conntrack_cleanup_net_list+0x14c/0x4f0 net/netfilter/nf_conntrack_core.c:2469\nops_exit_list+0x10d/0x160 net/core/net_namespace.c:171\nsetup_net+0x639/0xa30 net/core/net_namespace.c:349\ncopy_net_ns+0x319/0x760 net/core/net_namespace.c:470\ncreate_new_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110\nunshare_nsproxy_namespaces+0xc1/0x1f0 kernel/nsproxy.c:226\nksys_unshare+0x445/0x920 kernel/fork.c:3128\n__do_sys_unshare kernel/fork.c:3202 [inline]\n__se_sys_unshare kernel/fork.c:3200 [inline]\n__x64_sys_unshare+0x2d/0x40 kernel/fork.c:3200\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f63da68e739\nRSP: 002b:00007f63d7c05188 EFLAGS: 00000246 ORIG_RAX: 0000000000000110\nRAX: ffffffffffffffda RBX: 00007f63da792f80 RCX: 00007f63da68e739\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000040000000\nRBP: 00007f63da6e8cc4 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 00007f63da792f80\nR13: 00007fff50b75d3f R14: 00007f63d7c05300 R15: 0000000000022000\nShowing all locks held in the system:\n1 lock held by khungtaskd/27:\n#0: ffffffff8b980020 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x53/0x260 kernel/locking/lockdep.c:6446\n2 locks held by kworker/u4:2/153:\n#0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]\n#0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: arch_atomic_long_set include/linux/atomic/atomic-long.h:41 [inline]\n#0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: atomic_long_set include/linux/atomic/atomic-instrumented.h:1198 [inline]\n#0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: set_work_data kernel/workqueue.c:634 [inline]\n#0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: set_work_pool_and_clear_pending kernel/workqueue.c:661 [inline]\n#0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x896/0x1690 kernel/workqueue.c:2268\n#1: ffffc9000140fdb0 ((kfence_timer).work){+.+.}-{0:0}, at: process_one_work+0x8ca/0x1690 kernel/workqueue.c:2272\n1 lock held by systemd-udevd/2970:\n1 lock held by in:imklog/6258:\n#0: ffff88807f970ff0 (&f->f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0xe9/0x100 fs/file.c:990\n3 locks held by kworker/1:6/8158:\n1 lock held by syz-executor.0/8312:\n2 locks held by kworker/u4:13/9320:\n1 lock held by\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\nirqchip/gic-v3-its: Fix potential VPE leak on error\nIn its_vpe_irq_domain_alloc, when its_vpe_init() returns an error,\nthere is an off-by-one in the number of VPEs to be freed.\nFix it by simply passing the number of VPEs allocated, which is the\nindex of the loop iterating over the VPEs.\n[maz: fixed commit message]

In the Linux kernel, the following vulnerability has been resolved:\ntcp: fix tcp_init_transfer() to not reset icsk_ca_initialized\nThis commit fixes a bug (found by syzkaller) that could cause spurious\ndouble-initializations for congestion control modules, which could cause\nmemory leaks or other problems for congestion control modules (like CDG)\nthat allocate memory in their init functions.\nThe buggy scenario constructed by syzkaller was something like:\n(1) create a TCP socket\n(2) initiate a TFO connect via sendto()\n(3) while socket is in TCP_SYN_SENT, call setsockopt(TCP_CONGESTION),\nwhich calls:\ntcp_set_congestion_control() ->\ntcp_reinit_congestion_control() ->\ntcp_init_congestion_control()\n(4) receive ACK, connection is established, call tcp_init_transfer(),\nset icsk_ca_initialized=0 (without first calling cc->release()),\ncall tcp_init_congestion_control() again.\nNote that in this sequence tcp_init_congestion_control() is called\ntwice without a cc->release() call in between. Thus, for CC modules\nthat allocate memory in their init() function, e.g, CDG, a memory leak\nmay occur. The syzkaller tool managed to find a reproducer that\ntriggered such a leak in CDG.\nThe bug was introduced when that commit 8919a9b31eb4 ("tcp: Only init\ncongestion control if not initialized already")\nintroduced icsk_ca_initialized and set icsk_ca_initialized to 0 in\ntcp_init_transfer(), missing the possibility for a sequence like the\none above, where a process could call setsockopt(TCP_CONGESTION) in\nstate TCP_SYN_SENT (i.e. after the connect() or TFO open sendmsg()),\nwhich would call tcp_init_congestion_control(). It did not intend to\nreset any initialization that the user had already explicitly made;\nit just missed the possibility of that particular sequence (which\nsyzkaller managed to find).

In the Linux kernel, the following vulnerability has been resolved:\nisdn: mISDN: netjet: Fix crash in nj_probe:\n'nj_setup' in netjet.c might fail with -EIO and in this case\n'card->irq' is initialized and is bigger than zero. A subsequent call to\n'nj_release' will free the irq that has not been requested.\nFix this bug by deleting the previous assignment to 'card->irq' and just\nkeep the assignment before 'request_irq'.\nThe KASAN's log reveals it:\n[ 3.354615 ] WARNING: CPU: 0 PID: 1 at kernel/irq/manage.c:1826\nfree_irq+0x100/0x480\n[ 3.355112 ] Modules linked in:\n[ 3.355310 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted\n5.13.0-rc1-00144-g25a1298726e #13\n[ 3.355816 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS\nrel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014\n[ 3.356552 ] RIP: 0010:free_irq+0x100/0x480\n[ 3.356820 ] Code: 6e 08 74 6f 4d 89 f4 e8 5e ac 09 00 4d 8b 74 24 18\n4d 85 f6 75 e3 e8 4f ac 09 00 8b 75 c8 48 c7 c7 78 c1 2e 85 e8 e0 cf f5\nff <0f> 0b 48 8b 75 c0 4c 89 ff e8 72 33 0b 03 48 8b 43 40 4c 8b a0 80\n[ 3.358012 ] RSP: 0000:ffffc90000017b48 EFLAGS: 00010082\n[ 3.358357 ] RAX: 0000000000000000 RBX: ffff888104dc8000 RCX:\n0000000000000000\n[ 3.358814 ] RDX: ffff8881003c8000 RSI: ffffffff8124a9e6 RDI:\n00000000ffffffff\n[ 3.359272 ] RBP: ffffc90000017b88 R08: 0000000000000000 R09:\n0000000000000000\n[ 3.359732 ] R10: ffffc900000179f0 R11: 0000000000001d04 R12:\n0000000000000000\n[ 3.360195 ] R13: ffff888107dc6000 R14: ffff888107dc6928 R15:\nffff888104dc80a8\n[ 3.360652 ] FS: 0000000000000000(0000) GS:ffff88817bc00000(0000)\nknlGS:0000000000000000\n[ 3.361170 ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 3.361538 ] CR2: 0000000000000000 CR3: 000000000582e000 CR4:\n00000000000006f0\n[ 3.362003 ] DR0: 0000000000000000 DR1: 0000000000000000 DR2:\n0000000000000000\n[ 3.362175 ] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:\n0000000000000400\n[ 3.362175 ] Call Trace:\n[ 3.362175 ] nj_release+0x51/0x1e0\n[ 3.362175 ] nj_probe+0x450/0x950\n[ 3.362175 ] ? pci_device_remove+0x110/0x110\n[ 3.362175 ] local_pci_probe+0x45/0xa0\n[ 3.362175 ] pci_device_probe+0x12b/0x1d0\n[ 3.362175 ] really_probe+0x2a9/0x610\n[ 3.362175 ] driver_probe_device+0x90/0x1d0\n[ 3.362175 ] ? mutex_lock_nested+0x1b/0x20\n[ 3.362175 ] device_driver_attach+0x68/0x70\n[ 3.362175 ] __driver_attach+0x124/0x1b0\n[ 3.362175 ] ? device_driver_attach+0x70/0x70\n[ 3.362175 ] bus_for_each_dev+0xbb/0x110\n[ 3.362175 ] ? rdinit_setup+0x45/0x45\n[ 3.362175 ] driver_attach+0x27/0x30\n[ 3.362175 ] bus_add_driver+0x1eb/0x2a0\n[ 3.362175 ] driver_register+0xa9/0x180\n[ 3.362175 ] __pci_register_driver+0x82/0x90\n[ 3.362175 ] ? w6692_init+0x38/0x38\n[ 3.362175 ] nj_init+0x36/0x38\n[ 3.362175 ] do_one_initcall+0x7f/0x3d0\n[ 3.362175 ] ? rdinit_setup+0x45/0x45\n[ 3.362175 ] ? rcu_read_lock_sched_held+0x4f/0x80\n[ 3.362175 ] kernel_init_freeable+0x2aa/0x301\n[ 3.362175 ] ? rest_init+0x2c0/0x2c0\n[ 3.362175 ] kernel_init+0x18/0x190\n[ 3.362175 ] ? rest_init+0x2c0/0x2c0\n[ 3.362175 ] ? rest_init+0x2c0/0x2c0\n[ 3.362175 ] ret_from_fork+0x1f/0x30\n[ 3.362175 ] Kernel panic - not syncing: panic_on_warn set ...\n[ 3.362175 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted\n5.13.0-rc1-00144-g25a1298726e #13\n[ 3.362175 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS\nrel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014\n[ 3.362175 ] Call Trace:\n[ 3.362175 ] dump_stack+0xba/0xf5\n[ 3.362175 ] ? free_irq+0x100/0x480\n[ 3.362175 ] panic+0x15a/0x3f2\n[ 3.362175 ] ? __warn+0xf2/0x150\n[ 3.362175 ] ? free_irq+0x100/0x480\n[ 3.362175 ] __warn+0x108/0x150\n[ 3.362175 ] ? free_irq+0x100/0x480\n[ 3.362175 ] report_bug+0x119/0x1c0\n[ 3.362175 ] handle_bug+0x3b/0x80\n[ 3.362175 ] exc_invalid_op+0x18/0x70\n[ 3.362175 ] asm_exc_invalid_op+0x12/0x20\n[ 3.362175 ] RIP: 0010:free_irq+0x100\n---truncated---

In the Linux kernel, the following vulnerability has been resolved:\nnet: ieee802154: fix null deref in parse dev addr\nFix a logic error that could result in a null deref if the user sets\nthe mode incorrectly for the given addr type.

In the Linux kernel, the following vulnerability has been resolved:\npowerpc/64: Fix the definition of the fixmap area\nAt the time being, the fixmap area is defined at the top of\nthe address space or just below KASAN.\nThis definition is not valid for PPC64.\nFor PPC64, use the top of the I/O space.\nBecause of circular dependencies, it is not possible to include\nasm/fixmap.h in asm/book3s/64/pgtable.h , so define a fixed size\nAREA at the top of the I/O space for fixmap and ensure during\nbuild that the size is big enough.

In the Linux kernel, the following vulnerability has been resolved:\ntracing: Restructure trace_clock_global() to never block\nIt was reported that a fix to the ring buffer recursion detection would\ncause a hung machine when performing suspend / resume testing. The\nfollowing backtrace was extracted from debugging that case:\nCall Trace:\ntrace_clock_global+0x91/0xa0\n__rb_reserve_next+0x237/0x460\nring_buffer_lock_reserve+0x12a/0x3f0\ntrace_buffer_lock_reserve+0x10/0x50\n__trace_graph_return+0x1f/0x80\ntrace_graph_return+0xb7/0xf0\n? trace_clock_global+0x91/0xa0\nftrace_return_to_handler+0x8b/0xf0\n? pv_hash+0xa0/0xa0\nreturn_to_handler+0x15/0x30\n? ftrace_graph_caller+0xa0/0xa0\n? trace_clock_global+0x91/0xa0\n? __rb_reserve_next+0x237/0x460\n? ring_buffer_lock_reserve+0x12a/0x3f0\n? trace_event_buffer_lock_reserve+0x3c/0x120\n? trace_event_buffer_reserve+0x6b/0xc0\n? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0\n? dpm_run_callback+0x3b/0xc0\n? pm_ops_is_empty+0x50/0x50\n? platform_get_irq_byname_optional+0x90/0x90\n? trace_device_pm_callback_start+0x82/0xd0\n? dpm_run_callback+0x49/0xc0\nWith the following RIP:\nRIP: 0010:native_queued_spin_lock_slowpath+0x69/0x200\nSince the fix to the recursion detection would allow a single recursion to\nhappen while tracing, this lead to the trace_clock_global() taking a spin\nlock and then trying to take it again:\nring_buffer_lock_reserve() {\ntrace_clock_global() {\narch_spin_lock() {\nqueued_spin_lock_slowpath() {\n/* lock taken */\n(something else gets traced by function graph tracer)\nring_buffer_lock_reserve() {\ntrace_clock_global() {\narch_spin_lock() {\nqueued_spin_lock_slowpath() {\n/* DEAD LOCK! */\nTracing should *never* block, as it can lead to strange lockups like the\nabove.\nRestructure the trace_clock_global() code to instead of simply taking a\nlock to update the recorded "prev_time" simply use it, as two events\nhappening on two different CPUs that calls this at the same time, really\ndoesn't matter which one goes first. Use a trylock to grab the lock for\nupdating the prev_time, and if it fails, simply try again the next time.\nIf it failed to be taken, that means something else is already updating\nit.\nBugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761

RADIUS Protocol under RFC 2865 is susceptible to forgery attacks by a local attacker who can modify any valid Response (Access-Accept, Access-Reject, or Access-Challenge) to any other response using a chosen-prefix collision attack against MD5 Response Authenticator signature.

libata-core是ATA(AdvancedTechnologyAttachment)子系统的一部分，负责处理ATA硬盘驱动器的核心功能。libata是一个用于ATA和SATA（SerialATA）设备的Linux内核库，而libata-core是这个库的核心组件。其中ata_host_alloc和ata_host_release各会kfree(host)一次，导致doublefree，影响版本4.17<=版本<6.10-rc6

linux内核中网络调度相关的net/sched部分存在释放后使用漏洞，原因是ct在clash被resolve后被释放，之后又传入tcf_ct_flow_table_process_conn使用导致的，影响版本5.10.43<=版本<6.10

linux内核的tun模块没有限制Ethernetheader的大小，导致当其小于ETH_HLEN时会导致某些宿主机的网卡驱动崩溃，提交者在mlx5网卡驱动里触发了崩溃，影响版本4.20<=版本<6.11-rc1，包含5.10

linux内核的tap模块没有限制Ethernetheader的大小，导致当其小于ETH_HLEN时会导致某些宿主机的网卡驱动崩溃，提交者在mlx5网卡驱动里触发了崩溃，影响版本4.20<=版本<6.11-rc1，包含5.10