{"schema_version":"1.7.2","id":"OESA-2026-2579","modified":"2026-06-05T15:49:24Z","published":"2026-06-05T15:49:24Z","upstream":["CVE-2025-38263","CVE-2025-38403","CVE-2025-38459","CVE-2025-38602","CVE-2025-38644","CVE-2025-39738","CVE-2025-40020","CVE-2025-68340","CVE-2026-23243","CVE-2026-23273","CVE-2026-31586","CVE-2026-31588","CVE-2026-31678","CVE-2026-31759","CVE-2026-31781","CVE-2026-43037","CVE-2026-43038","CVE-2026-43139","CVE-2026-43158","CVE-2026-43180","CVE-2026-43190","CVE-2026-43233","CVE-2026-43281","CVE-2026-43328","CVE-2026-43336","CVE-2026-43427","CVE-2026-43466","CVE-2026-45840","CVE-2026-46006","CVE-2026-46021","CVE-2026-46023","CVE-2026-46033","CVE-2026-46052","CVE-2026-46227"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbcache: fix NULL pointer in cache_set_flush()\n\n1. LINE#1794 - LINE#1887 is some codes about function of\n   bch_cache_set_alloc().\n2. LINE#2078 - LINE#2142 is some codes about function of\n   register_cache_set().\n3. register_cache_set() will call bch_cache_set_alloc() in LINE#2098.\n\n 1794 struct cache_set *bch_cache_set_alloc(struct cache_sb *sb)\n 1795 {\n ...\n 1860         if (!(c->devices = kcalloc(c->nr_uuids, sizeof(void *), GFP_KERNEL)) ||\n 1861             mempool_init_slab_pool(&c->search, 32, bch_search_cache) ||\n 1862             mempool_init_kmalloc_pool(&c->bio_meta, 2,\n 1863                                 sizeof(struct bbio) + sizeof(struct bio_vec) *\n 1864                                 bucket_pages(c)) ||\n 1865             mempool_init_kmalloc_pool(&c->fill_iter, 1, iter_size) ||\n 1866             bioset_init(&c->bio_split, 4, offsetof(struct bbio, bio),\n 1867                         BIOSET_NEED_BVECS|BIOSET_NEED_RESCUER) ||\n 1868             !(c->uuids = alloc_bucket_pages(GFP_KERNEL, c)) ||\n 1869             !(c->moving_gc_wq = alloc_workqueue("bcache_gc",\n 1870                                                 WQ_MEM_RECLAIM, 0)) ||\n 1871             bch_journal_alloc(c) ||\n 1872             bch_btree_cache_alloc(c) ||\n 1873             bch_open_buckets_alloc(c) ||\n 1874             bch_bset_sort_state_init(&c->sort, ilog2(c->btree_pages)))\n 1875                 goto err;\n                      ^^^^^^^^\n 1876\n ...\n 1883         return c;\n 1884 err:\n 1885         bch_cache_set_unregister(c);\n              ^^^^^^^^^^^^^^^^^^^^^^^^^^^\n 1886         return NULL;\n 1887 }\n ...\n 2078 static const char *register_cache_set(struct cache *ca)\n 2079 {\n ...\n 2098         c = bch_cache_set_alloc(&ca->sb);\n 2099         if (!c)\n 2100                 return err;\n                      ^^^^^^^^^^\n ...\n 2128         ca->set = c;\n 2129         ca->set->cache[ca->sb.nr_this_dev] = ca;\n              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n ...\n 2138         return NULL;\n 2139 err:\n 2140         bch_cache_set_unregister(c);\n 2141         return err;\n 2142 }\n\n(1) If LINE#1860 - LINE#1874 is true, then do 'goto err'(LINE#1875) and\n    call bch_cache_set_unregister()(LINE#1885).\n(2) As (1) return NULL(LINE#1886), LINE#2098 - LINE#2100 would return.\n(3) As (2) has returned, LINE#2128 - LINE#2129 would do *not* give the\n    value to c->cache[], it means that c->cache[] is NULL.\n\nLINE#1624 - LINE#1665 is some codes about function of cache_set_flush().\nAs (1), in LINE#1885 call\nbch_cache_set_unregister()\n---> bch_cache_set_stop()\n     ---> closure_queue()\n          -.-> cache_set_flush() (as below LINE#1624)\n\n 1624 static void cache_set_flush(struct closure *cl)\n 1625 {\n ...\n 1654         for_each_cache(ca, c, i)\n 1655                 if (ca->alloc_thread)\n                          ^^\n 1656                         kthread_stop(ca->alloc_thread);\n ...\n 1665 }\n\n(4) In LINE#1655 ca is NULL(see (3)) in cache_set_flush() then the\n    kernel crash occurred as below:\n[  846.712887] bcache: register_cache() error drbd6: cannot allocate memory\n[  846.713242] bcache: register_bcache() error : failed to register device\n[  846.713336] bcache: cache_set_free() Cache set 2f84bdc1-498a-4f2f-98a7-01946bf54287 unregistered\n[  846.713768] BUG: unable to handle kernel NULL pointer dereference at 00000000000009f8\n[  846.714790] PGD 0 P4D 0\n[  846.715129] Oops: 0000 [#1] SMP PTI\n[  846.715472] CPU: 19 PID: 5057 Comm: kworker/19:16 Kdump: loaded Tainted: G           OE    --------- -  - 4.18.0-147.5.1.el8_1.5es.3.x86_64 #1\n[  846.716082] Hardware name: ESPAN GI-25212/X11DPL-i, BIOS 2.1 06/15/2018\n[  846.716451] Workqueue: events cache_set_flush [bcache]\n[  846.716808] RIP: 0010:cache_set_flush+0xc9/0x1b0 [bcache]\n[  846.717155] Code: 00 4c 89 a5 b0 03 00 00 48 8b 85 68 f6 ff ff a8 08 0f 84 88 00 00 00 31 db 66 83 bd 3c f7 ff ff 00 48 8b 85 48 ff ff ff 74 28 <48> 8b b8 f8 09 00 0\n---truncated---(CVE-2025-38263)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvsock/vmci: Clear the vmci transport packet properly when initializing it\n\nIn vmci_transport_packet_init memset the vmci_transport_packet before\npopulating the fields to avoid any uninitialised data being left in the\nstructure.(CVE-2025-38403)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\natm: clip: Fix infinite recursive call of clip_push().\n\nsyzbot reported the splat below. [0]\n\nThis happens if we call ioctl(ATMARP_MKIP) more than once.\n\nDuring the first call, clip_mkip() sets clip_push() to vcc->push(),\nand the second call copies it to clip_vcc->old_push().\n\nLater, when the socket is close()d, vcc_destroy_socket() passes\nNULL skb to clip_push(), which calls clip_vcc->old_push(),\ntriggering the infinite recursion.\n\nLet's prevent the second ioctl(ATMARP_MKIP) by checking\nvcc->user_back, which is allocated by the first call as clip_vcc.\n\nNote also that we use lock_sock() to prevent racy calls.\n\n[0]:\nBUG: TASK stack guard page was hit at ffffc9000d66fff8 (stack is ffffc9000d670000..ffffc9000d678000)\nOops: stack guard page: 0000 [#1] SMP KASAN NOPTI\nCPU: 0 UID: 0 PID: 5322 Comm: syz.0.0 Not tainted 6.16.0-rc4-syzkaller #0 PREEMPT(full)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nRIP: 0010:clip_push+0x5/0x720 net/atm/clip.c:191\nCode: e0 8f aa 8c e8 1c ad 5b fa eb ae 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 55 <41> 57 41 56 41 55 41 54 53 48 83 ec 20 48 89 f3 49 89 fd 48 bd 00\nRSP: 0018:ffffc9000d670000 EFLAGS: 00010246\nRAX: 1ffff1100235a4a5 RBX: ffff888011ad2508 RCX: ffff8880003c0000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888037f01000\nRBP: dffffc0000000000 R08: ffffffff8fa104f7 R09: 1ffffffff1f4209e\nR10: dffffc0000000000 R11: ffffffff8a99b300 R12: ffffffff8a99b300\nR13: ffff888037f01000 R14: ffff888011ad2500 R15: ffff888037f01578\nFS:  000055557ab6d500(0000) GS:ffff88808d250000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffc9000d66fff8 CR3: 0000000043172000 CR4: 0000000000352ef0\nCall Trace:\n <TASK>\n clip_push+0x6dc/0x720 net/atm/clip.c:200\n clip_push+0x6dc/0x720 net/atm/clip.c:200\n clip_push+0x6dc/0x720 net/atm/clip.c:200\n...\n clip_push+0x6dc/0x720 net/atm/clip.c:200\n clip_push+0x6dc/0x720 net/atm/clip.c:200\n clip_push+0x6dc/0x720 net/atm/clip.c:200\n vcc_destroy_socket net/atm/common.c:183 [inline]\n vcc_release+0x157/0x460 net/atm/common.c:205\n __sock_release net/socket.c:647 [inline]\n sock_close+0xc0/0x240 net/socket.c:1391\n __fput+0x449/0xa70 fs/file_table.c:465\n task_work_run+0x1d1/0x260 kernel/task_work.c:227\n resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]\n exit_to_user_mode_loop+0xec/0x110 kernel/entry/common.c:114\n exit_to_user_mode_prepare include/linux/entry-common.h:330 [inline]\n syscall_exit_to_user_mode_work include/linux/entry-common.h:414 [inline]\n syscall_exit_to_user_mode include/linux/entry-common.h:449 [inline]\n do_syscall_64+0x2bd/0x3b0 arch/x86/entry/syscall_64.c:100\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7ff31c98e929\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fffb5aa1f78 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4\nRAX: 0000000000000000 RBX: 0000000000012747 RCX: 00007ff31c98e929\nRDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003\nRBP: 00007ff31cbb7ba0 R08: 0000000000000001 R09: 0000000db5aa226f\nR10: 00007ff31c7ff030 R11: 0000000000000246 R12: 00007ff31cbb608c\nR13: 00007ff31cbb6080 R14: ffffffffffffffff R15: 00007fffb5aa2090\n </TASK>\nModules linked in:(CVE-2025-38459)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niwlwifi: Add missing check for alloc_ordered_workqueue\n\nAdd check for the return value of alloc_ordered_workqueue since it may\nreturn NULL pointer.(CVE-2025-38602)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: reject TDLS operations when station is not associated\n\nsyzbot triggered a WARN in ieee80211_tdls_oper() by sending\nNL80211_TDLS_ENABLE_LINK immediately after NL80211_CMD_CONNECT,\nbefore association completed and without prior TDLS setup.\n\nThis left internal state like sdata->u.mgd.tdls_peer uninitialized,\nleading to a WARN_ON() in code paths that assumed it was valid.\n\nReject the operation early if not in station mode or not associated.(CVE-2025-38644)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: do not allow relocation of partially dropped subvolumes\n\n[BUG]\nThere is an internal report that balance triggered transaction abort,\nwith the following call trace:\n\n  item 85 key (594509824 169 0) itemoff 12599 itemsize 33\n          extent refs 1 gen 197740 flags 2\n          ref#0: tree block backref root 7\n  item 86 key (594558976 169 0) itemoff 12566 itemsize 33\n          extent refs 1 gen 197522 flags 2\n          ref#0: tree block backref root 7\n ...\n BTRFS error (device loop0): extent item not found for insert, bytenr 594526208 num_bytes 16384 parent 449921024 root_objectid 934 owner 1 offset 0\n BTRFS error (device loop0): failed to run delayed ref for logical 594526208 num_bytes 16384 type 182 action 1 ref_mod 1: -117\n ------------[ cut here ]------------\n BTRFS: Transaction aborted (error -117)\n WARNING: CPU: 1 PID: 6963 at ../fs/btrfs/extent-tree.c:2168 btrfs_run_delayed_refs+0xfa/0x110 [btrfs]\n\nAnd btrfs check doesn't report anything wrong related to the extent\ntree.\n\n[CAUSE]\nThe cause is a little complex, firstly the extent tree indeed doesn't\nhave the backref for 594526208.\n\nThe extent tree only have the following two backrefs around that bytenr\non-disk:\n\n        item 65 key (594509824 METADATA_ITEM 0) itemoff 13880 itemsize 33\n                refs 1 gen 197740 flags TREE_BLOCK\n                tree block skinny level 0\n                (176 0x7) tree block backref root CSUM_TREE\n        item 66 key (594558976 METADATA_ITEM 0) itemoff 13847 itemsize 33\n                refs 1 gen 197522 flags TREE_BLOCK\n                tree block skinny level 0\n                (176 0x7) tree block backref root CSUM_TREE\n\nBut the such missing backref item is not an corruption on disk, as the\noffending delayed ref belongs to subvolume 934, and that subvolume is\nbeing dropped:\n\n        item 0 key (934 ROOT_ITEM 198229) itemoff 15844 itemsize 439\n                generation 198229 root_dirid 256 bytenr 10741039104 byte_limit 0 bytes_used 345571328\n                last_snapshot 198229 flags 0x1000000000001(RDONLY) refs 0\n                drop_progress key (206324 EXTENT_DATA 2711650304) drop_level 2\n                level 2 generation_v2 198229\n\nAnd that offending tree block 594526208 is inside the dropped range of\nthat subvolume.  That explains why there is no backref item for that\nbytenr and why btrfs check is not reporting anything wrong.\n\nBut this also shows another problem, as btrfs will do all the orphan\nsubvolume cleanup at a read-write mount.\n\nSo half-dropped subvolume should not exist after an RW mount, and\nbalance itself is also exclusive to subvolume cleanup, meaning we\nshouldn't hit a subvolume half-dropped during relocation.\n\nThe root cause is, there is no orphan item for this subvolume.\nIn fact there are 5 subvolumes from around 2021 that have the same\nproblem.\n\nIt looks like the original report has some older kernels running, and\ncaused those zombie subvolumes.\n\nThankfully upstream commit 8d488a8c7ba2 ("btrfs: fix subvolume/snapshot\ndeletion not triggered on mount") has long fixed the bug.\n\n[ENHANCEMENT]\nFor repairing such old fs, btrfs-progs will be enhanced.\n\nConsidering how delayed the problem will show up (at run delayed ref\ntime) and at that time we have to abort transaction already, it is too\nlate.\n\nInstead here we reject any half-dropped subvolume for reloc tree at the\nearliest time, preventing confusion and extra time wasted on debugging\nsimilar bugs.(CVE-2025-39738)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: peak_usb: fix shift-out-of-bounds issue\n\nExplicitly uses a 64-bit constant when the number of bits used for its\nshifting is 32 (which is the case for PC CAN FD interfaces supported by\nthis driver).\n\n[mkl: update subject, apply manually](CVE-2025-40020)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nteam: Move team device type change at the end of team_port_add\n\nAttempting to add a port device that is already up will expectedly fail,\nbut not before modifying the team device header_ops.\n\nIn the case of the syzbot reproducer the gre0 device is\nalready in state UP when it attempts to add it as a\nport device of team0, this fails but before that\nheader_ops->create of team0 is changed from eth_header to ipgre_header\nin the call to team_dev_type_check_change.\n\nLater when we end up in ipgre_header() struct ip_tunnel* points to nonsense\nas the private data of the device still holds a struct team.\n\nExample sequence of iproute2 commands to reproduce the hang/BUG():\nip link add dev team0 type team\nip link add dev gre0 type gre\nip link set dev gre0 up\nip link set dev gre0 master team0\nip link set dev team0 up\nping -I team0 1.1.1.1\n\nMove team_dev_type_check_change down where all other checks have passed\nas it changes the dev type with no way to restore it in case\none of the checks that follow it fail.\n\nAlso make sure to preserve the origial mtu assignment:\n  - If port_dev is not the same type as dev, dev takes mtu from port_dev\n  - If port_dev is the same type as dev, port_dev takes mtu from dev\n\nThis is done by adding a conditional before the call to dev_set_mtu\nto prevent it from assigning port_dev->mtu = dev->mtu and instead\nletting team_dev_type_check_change assign dev->mtu = port_dev->mtu.\nThe conditional is needed because the patch moves the call to\nteam_dev_type_check_change past dev_set_mtu.\n\nTesting:\n  - team device driver in-tree selftests\n  - Add/remove various devices as slaves of team device\n  - syzbot(CVE-2025-68340)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/umad: Reject negative data_len in ib_umad_write\n\nib_umad_write computes data_len from user-controlled count and the\nMAD header sizes. With a mismatched user MAD header size and RMPP\nheader length, data_len can become negative and reach ib_create_send_mad().\nThis can make the padding calculation exceed the segment size and trigger\nan out-of-bounds memset in alloc_send_rmpp_list().\n\nAdd an explicit check to reject negative data_len before creating the\nsend buffer.\n\nKASAN splat:\n[  211.363464] BUG: KASAN: slab-out-of-bounds in ib_create_send_mad+0xa01/0x11b0\n[  211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spray_thread/102\n[  211.365867] ib_create_send_mad+0xa01/0x11b0\n[  211.365887] ib_umad_write+0x853/0x1c80(CVE-2026-23243)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmacvlan: observe an RCU grace period in macvlan_common_newlink() error path\n\nvalis reported that a race condition still happens after my prior patch.\n\nmacvlan_common_newlink() might have made @dev visible before\ndetecting an error, and its caller will directly call free_netdev(dev).\n\nWe must respect an RCU period, either in macvlan or the core networking\nstack.\n\nAfter adding a temporary mdelay(1000) in macvlan_forward_source_one()\nto open the race window, valis repro was:\n\nip link add p1 type veth peer p2\nip link set address 00:00:00:00:00:20 dev p1\nip link set up dev p1\nip link set up dev p2\nip link add mv0 link p2 type macvlan mode source\n\n(ip link add invalid% link p2 type macvlan mode source macaddr add\n00:00:00:00:00:20 &) ; sleep 0.5 ; ping -c1 -I p1 1.2.3.4\nPING 1.2.3.4 (1.2.3.4): 56 data bytes\nRTNETLINK answers: Invalid argument\n\nBUG: KASAN: slab-use-after-free in macvlan_forward_source\n(drivers/net/macvlan.c:408 drivers/net/macvlan.c:444)\nRead of size 8 at addr ffff888016bb89c0 by task e/175\n\nCPU: 1 UID: 1000 PID: 175 Comm: e Not tainted 6.19.0-rc8+ #33 NONE\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014\nCall Trace:\n<IRQ>\ndump_stack_lvl (lib/dump_stack.c:123)\nprint_report (mm/kasan/report.c:379 mm/kasan/report.c:482)\n? macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444)\nkasan_report (mm/kasan/report.c:597)\n? macvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444)\nmacvlan_forward_source (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444)\n? tasklet_init (kernel/softirq.c:983)\nmacvlan_handle_frame (drivers/net/macvlan.c:501)\n\nAllocated by task 169:\nkasan_save_stack (mm/kasan/common.c:58)\nkasan_save_track (./arch/x86/include/asm/current.h:25\nmm/kasan/common.c:70 mm/kasan/common.c:79)\n__kasan_kmalloc (mm/kasan/common.c:419)\n__kvmalloc_node_noprof (./include/linux/kasan.h:263 mm/slub.c:5657\nmm/slub.c:7140)\nalloc_netdev_mqs (net/core/dev.c:12012)\nrtnl_create_link (net/core/rtnetlink.c:3648)\nrtnl_newlink (net/core/rtnetlink.c:3830 net/core/rtnetlink.c:3957\nnet/core/rtnetlink.c:4072)\nrtnetlink_rcv_msg (net/core/rtnetlink.c:6958)\nnetlink_rcv_skb (net/netlink/af_netlink.c:2550)\nnetlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)\nnetlink_sendmsg (net/netlink/af_netlink.c:1894)\n__sys_sendto (net/socket.c:727 net/socket.c:742 net/socket.c:2206)\n__x64_sys_sendto (net/socket.c:2209)\ndo_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131)\n\nFreed by task 169:\nkasan_save_stack (mm/kasan/common.c:58)\nkasan_save_track (./arch/x86/include/asm/current.h:25\nmm/kasan/common.c:70 mm/kasan/common.c:79)\nkasan_save_free_info (mm/kasan/generic.c:587)\n__kasan_slab_free (mm/kasan/common.c:287)\nkfree (mm/slub.c:6674 mm/slub.c:6882)\nrtnl_newlink (net/core/rtnetlink.c:3845 net/core/rtnetlink.c:3957\nnet/core/rtnetlink.c:4072)\nrtnetlink_rcv_msg (net/core/rtnetlink.c:6958)\nnetlink_rcv_skb (net/netlink/af_netlink.c:2550)\nnetlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)\nnetlink_sendmsg (net/netlink/af_netlink.c:1894)\n__sys_sendto (net/socket.c:727 net/socket.c:742 net/socket.c:2206)\n__x64_sys_sendto (net/socket.c:2209)\ndo_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131)(CVE-2026-23273)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: blk-cgroup: fix use-after-free in cgwb_release_workfn()\n\ncgwb_release_workfn() calls css_put(wb->blkcg_css) and then later accesses\nwb->blkcg_css again via blkcg_unpin_online().  If css_put() drops the last\nreference, the blkcg can be freed asynchronously (css_free_rwork_fn ->\nblkcg_css_free -> kfree) before blkcg_unpin_online() dereferences the\npointer to access blkcg->online_pin, resulting in a use-after-free:\n\n  BUG: KASAN: slab-use-after-free in blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367)\n  Write of size 4 at addr ff11000117aa6160 by task kworker/71:1/531\n   Workqueue: cgwb_release cgwb_release_workfn\n   Call Trace:\n    <TASK>\n     blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367)\n     cgwb_release_workfn (mm/backing-dev.c:629)\n     process_scheduled_works (kernel/workqueue.c:3278 kernel/workqueue.c:3385)\n\n   Freed by task 1016:\n    kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6246 mm/slub.c:6561)\n    css_free_rwork_fn (kernel/cgroup/cgroup.c:5542)\n    process_scheduled_works (kernel/workqueue.c:3302 kernel/workqueue.c:3385)\n\n** Stack based on commit 66672af7a095 ("Add linux-next specific files\nfor 20260410")\n\nI am seeing this crash sporadically in Meta fleet across multiple kernel\nversions.  A full reproducer is available at:\nhttps://github.com/leitao/debug/blob/main/reproducers/repro_blkcg_uaf.sh\n\n(The race window is narrow.  To make it easily reproducible, inject a\nmsleep(100) between css_put() and blkcg_unpin_online() in\ncgwb_release_workfn().  With that delay and a KASAN-enabled kernel, the\nreproducer triggers the splat reliably in less than a second.)\n\nFix this by moving blkcg_unpin_online() before css_put(), so the\ncgwb's CSS reference keeps the blkcg alive while blkcg_unpin_online()\naccesses it.(CVE-2026-31586)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Use scratch field in MMIO fragment to hold small write values\n\nWhen exiting to userspace to service an emulated MMIO write, copy the\nto-be-written value to a scratch field in the MMIO fragment if the size\nof the data payload is 8 bytes or less, i.e. can fit in a single chunk,\ninstead of pointing the fragment directly at the source value.\n\nThis fixes a class of use-after-free bugs that occur when the emulator\ninitiates a write using an on-stack, local variable as the source, the\nwrite splits a page boundary, *and* both pages are MMIO pages.  Because\nKVM's ABI only allows for physically contiguous MMIO requests, accesses\nthat split MMIO pages are separated into two fragments, and are sent to\nuserspace one at a time.  When KVM attempts to complete userspace MMIO in\nresponse to KVM_RUN after the first fragment, KVM will detect the second\nfragment and generate a second userspace exit, and reference the on-stack\nvariable.\n\nThe issue is most visible if the second KVM_RUN is performed by a separate\ntask, in which case the stack of the initiating task can show up as truly\nfreed data.\n\n  ==================================================================\n  BUG: KASAN: use-after-free in complete_emulated_mmio+0x305/0x420\n  Read of size 1 at addr ffff888009c378d1 by task syz-executor417/984\n\n  CPU: 1 PID: 984 Comm: syz-executor417 Not tainted 5.10.0-182.0.0.95.h2627.eulerosv2r13.x86_64 #3\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Call Trace:\n  dump_stack+0xbe/0xfd\n  print_address_description.constprop.0+0x19/0x170\n  __kasan_report.cold+0x6c/0x84\n  kasan_report+0x3a/0x50\n  check_memory_region+0xfd/0x1f0\n  memcpy+0x20/0x60\n  complete_emulated_mmio+0x305/0x420\n  kvm_arch_vcpu_ioctl_run+0x63f/0x6d0\n  kvm_vcpu_ioctl+0x413/0xb20\n  __se_sys_ioctl+0x111/0x160\n  do_syscall_64+0x30/0x40\n  entry_SYSCALL_64_after_hwframe+0x67/0xd1\n  RIP: 0033:0x42477d\n  Code: <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\n  RSP: 002b:00007faa8e6890e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\n  RAX: ffffffffffffffda RBX: 00000000004d7338 RCX: 000000000042477d\n  RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005\n  RBP: 00000000004d7330 R08: 00007fff28d546df R09: 0000000000000000\n  R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004d733c\n  R13: 0000000000000000 R14: 000000000040a200 R15: 00007fff28d54720\n\n  The buggy address belongs to the page:\n  page:0000000029f6a428 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9c37\n  flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)\n  raw: 000fffffc0000000 0000000000000000 ffffea0000270dc8 0000000000000000\n  raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected\n\n  Memory state around the buggy address:\n  ffff888009c37780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n  ffff888009c37800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n  >ffff888009c37880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n                                                   ^\n  ffff888009c37900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n  ffff888009c37980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n  ==================================================================\n\nThe bug can also be reproduced with a targeted KVM-Unit-Test by hacking\nKVM to fill a large on-stack variable in complete_emulated_mmio(), i.e. by\noverwrite the data value with garbage.\n\nLimit the use of the scratch fields to 8-byte or smaller accesses, and to\njust writes, as larger accesses and reads are not affected thanks to\nimplementation details in the emulator, but add a sanity check to ensure\nthose details don't change in the future.  Specifically, KVM never uses\non-stack variables for accesses larger that 8 bytes, e.g. uses an operand\nin the emulator context, and *al\n---truncated---(CVE-2026-31588)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nopenvswitch: defer tunnel netdev_put to RCU release\n\novs_netdev_tunnel_destroy() may run after NETDEV_UNREGISTER already\ndetached the device. Dropping the netdev reference in destroy can race\nwith concurrent readers that still observe vport->dev.\n\nDo not release vport->dev in ovs_netdev_tunnel_destroy(). Instead, let\nvport_netdev_free() drop the reference from the RCU callback, matching\nthe non-tunnel destroy path and avoiding additional synchronization\nunder RTNL.(CVE-2026-31678)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: ulpi: fix double free in ulpi_register_interface() error path\n\nWhen device_register() fails, ulpi_register() calls put_device() on\nulpi->dev.\n\nThe device release callback ulpi_dev_release() drops the OF node\nreference and frees ulpi, but the current error path in\nulpi_register_interface() then calls kfree(ulpi) again, causing a\ndouble free.\n\nLet put_device() handle the cleanup through ulpi_dev_release() and\navoid freeing ulpi again in ulpi_register_interface().(CVE-2026-31759)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/ioc32: stop speculation on the drm_compat_ioctl path\n\nThe drm compat ioctl path takes a user controlled pointer, and then\ndereferences it into a table of function pointers, the signature method\nof spectre problems.  Fix this up by calling array_index_nospec() on the\nindex to the function pointer list.(CVE-2026-31781)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nip6_tunnel: clear skb2->cb[] in ip4ip6_err()\n\nOskar Kjos reported the following problem.\n\nip4ip6_err() calls icmp_send() on a cloned skb whose cb[] was written\nby the IPv6 receive path as struct inet6_skb_parm. icmp_send() passes\nIPCB(skb2) to __ip_options_echo(), which interprets that cb[] region\nas struct inet_skb_parm (IPv4). The layouts differ: inet6_skb_parm.nhoff\nat offset 14 overlaps inet_skb_parm.opt.rr, producing a non-zero rr\nvalue. __ip_options_echo() then reads optlen from attacker-controlled\npacket data at sptr[rr+1] and copies that many bytes into dopt->__data,\na fixed 40-byte stack buffer (IP_OPTIONS_DATA_FIXED_SIZE).\n\nTo fix this we clear skb2->cb[], as suggested by Oskar Kjos.\n\nAlso add minimal IPv4 header validation (version == 4, ihl >= 5).(CVE-2026-43037)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach()\n\nSashiko AI-review observed:\n\n  In ip6_err_gen_icmpv6_unreach(), the skb is an outer IPv4 ICMP error packet\n  where its cb contains an IPv4 inet_skb_parm. When skb is cloned into skb2\n  and passed to icmp6_send(), it uses IP6CB(skb2).\n\n  IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm. The cipso\n  offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm\n  at offset 18.\n\n  If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao\n  would be a non-zero offset. Inside icmp6_send(), mip6_addr_swap() is called\n  and uses ipv6_find_tlv(skb, opt->dsthao, IPV6_TLV_HAO).\n\n  This would scan the inner, attacker-controlled IPv6 packet starting at that\n  offset, potentially returning a fake TLV without checking if the remaining\n  packet length can hold the full 18-byte struct ipv6_destopt_hao.\n\n  Could mip6_addr_swap() then perform a 16-byte swap that extends past the end\n  of the packet data into skb_shared_info?\n\n  Should the cb array also be cleared in ip6_err_gen_icmpv6_unreach() and\n  ip6ip6_err() to prevent this?\n\nThis patch implements the first suggestion.\n\nI am not sure if ip6ip6_err() needs to be changed.\nA separate patch would be better anyway.(CVE-2026-43038)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm6: fix uninitialized saddr in xfrm6_get_saddr()\n\nxfrm6_get_saddr() does not check the return value of\nipv6_dev_get_saddr(). When ipv6_dev_get_saddr() fails to find a suitable\nsource address (returns -EADDRNOTAVAIL), saddr->in6 is left\nuninitialized, but xfrm6_get_saddr() still returns 0 (success).\n\nThis causes the caller xfrm_tmpl_resolve_one() to use the uninitialized\naddress in xfrm_state_find(), triggering KMSAN warning:\n\n=====================================================\nBUG: KMSAN: uninit-value in xfrm_state_find+0x2424/0xa940\n xfrm_state_find+0x2424/0xa940\n xfrm_resolve_and_create_bundle+0x906/0x5a20\n xfrm_lookup_with_ifid+0xcc0/0x3770\n xfrm_lookup_route+0x63/0x2b0\n ip_route_output_flow+0x1ce/0x270\n udp_sendmsg+0x2ce1/0x3400\n inet_sendmsg+0x1ef/0x2a0\n __sock_sendmsg+0x278/0x3d0\n __sys_sendto+0x593/0x720\n __x64_sys_sendto+0x130/0x200\n x64_sys_call+0x332b/0x3e70\n do_syscall_64+0xd3/0xf80\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nLocal variable tmp.i.i created at:\n xfrm_resolve_and_create_bundle+0x3e3/0x5a20\n xfrm_lookup_with_ifid+0xcc0/0x3770\n=====================================================\n\nFix by checking the return value of ipv6_dev_get_saddr() and propagating\nthe error.(CVE-2026-43139)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfs: fix freemap adjustments when adding xattrs to leaf blocks\n\nxfs/592 and xfs/794 both trip this assertion in the leaf block freemap\nadjustment code after ~20 minutes of running on my test VMs:\n\n ASSERT(ichdr->firstused >= ichdr->count * sizeof(xfs_attr_leaf_entry_t)\n\t\t\t\t\t+ xfs_attr3_leaf_hdr_size(leaf));\n\nUpon enabling quite a lot more debugging code, I narrowed this down to\nfsstress trying to set a local extended attribute with namelen=3 and\nvaluelen=71.  This results in an entry size of 80 bytes.\n\nAt the start of xfs_attr3_leaf_add_work, the freemap looks like this:\n\ni 0 base 448 size 0 rhs 448 count 46\ni 1 base 388 size 132 rhs 448 count 46\ni 2 base 2120 size 4 rhs 448 count 46\nfirstused = 520\n\nwhere "rhs" is the first byte past the end of the leaf entry array.\nThis is inconsistent -- the entries array ends at byte 448, but\nfreemap[1] says there's free space starting at byte 388!\n\nBy the end of the function, the freemap is in worse shape:\n\ni 0 base 456 size 0 rhs 456 count 47\ni 1 base 388 size 52 rhs 456 count 47\ni 2 base 2120 size 4 rhs 456 count 47\nfirstused = 440\n\nImportant note: 388 is not aligned with the entries array element size\nof 8 bytes.\n\nBased on the incorrect freemap, the name area starts at byte 440, which\nis below the end of the entries array!  That's why the assertion\ntriggers and the filesystem shuts down.\n\nHow did we end up here?  First, recall from the previous patch that the\nfreemap array in an xattr leaf block is not intended to be a\ncomprehensive map of all free space in the leaf block.  In other words,\nit's perfectly legal to have a leaf block with:\n\n * 376 bytes in use by the entries array\n * freemap[0] has [base = 376, size = 8]\n * freemap[1] has [base = 388, size = 1500]\n * the space between 376 and 388 is free, but the freemap stopped\n   tracking that some time ago\n\nIf we add one xattr, the entries array grows to 384 bytes, and\nfreemap[0] becomes [base = 384, size = 0].  So far, so good.  But if we\nadd a second xattr, the entries array grows to 392 bytes, and freemap[0]\ngets pushed up to [base = 392, size = 0].  This is bad, because\nfreemap[1] hasn't been updated, and now the entries array and the free\nspace claim the same space.\n\nThe fix here is to adjust all freemap entries so that none of them\ncollide with the entries array.  Note that this fix relies on commit\n2a2b5932db6758 ("xfs: fix attr leaf header freemap.size underflow") and\nthe previous patch that resets zero length freemap entries to have\nbase = 0.(CVE-2026-43158)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: kaweth: remove TX queue manipulation in kaweth_set_rx_mode\n\nkaweth_set_rx_mode(), the ndo_set_rx_mode callback, calls\nnetif_stop_queue() and netif_wake_queue(). These are TX queue flow\ncontrol functions unrelated to RX multicast configuration.\n\nThe premature netif_wake_queue() can re-enable TX while tx_urb is still\nin-flight, leading to a double usb_submit_urb() on the same URB:\n\nkaweth_start_xmit() {\n    netif_stop_queue();\n    usb_submit_urb(kaweth->tx_urb);\n}\n\nkaweth_set_rx_mode() {\n    netif_stop_queue();\n    netif_wake_queue();             // wakes TX queue before URB is done\n}\n\nkaweth_start_xmit() {\n    netif_stop_queue();\n    usb_submit_urb(kaweth->tx_urb); // URB submitted while active\n}\n\nThis triggers the WARN in usb_submit_urb():\n\n  "URB submitted while active"\n\nThis is a similar class of bug fixed in rtl8150 by\n\n- commit 958baf5eaee3 ("net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast").\n\nAlso kaweth_set_rx_mode() is already functionally broken, the\nreal set_rx_mode action is performed by kaweth_async_set_rx_mode(),\nwhich in turn is not a no-op only at ndo_open() time.(CVE-2026-43180)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: xt_tcpmss: check remaining length before reading optlen\n\nQuoting reporter:\n  In net/netfilter/xt_tcpmss.c (lines 53-68), the TCP option parser reads\n op[i+1] directly without validating the remaining option length.\n\n  If the last byte of the option field is not EOL/NOP (0/1), the code attempts\n  to index op[i+1]. In the case where i + 1 == optlen, this causes an\n  out-of-bounds read, accessing memory past the optlen boundary\n  (either reading beyond the stack buffer _opt or the\n  following payload).(CVE-2026-43190)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack_h323: fix OOB read in decode_choice()\n\nIn decode_choice(), the boundary check before get_len() uses the\nvariable `len`, which is still 0 from its initialization at the top of\nthe function:\n\n    unsigned int type, ext, len = 0;\n    ...\n    if (ext || (son->attr & OPEN)) {\n        BYTE_ALIGN(bs);\n        if (nf_h323_error_boundary(bs, len, 0))  /* len is 0 here */\n            return H323_ERROR_BOUND;\n        len = get_len(bs);                        /* OOB read */\n\nWhen the bitstream is exactly consumed (bs->cur == bs->end), the check\nnf_h323_error_boundary(bs, 0, 0) evaluates to (bs->cur + 0 > bs->end),\nwhich is false.  The subsequent get_len() call then dereferences\n*bs->cur++, reading 1 byte past the end of the buffer.  If that byte\nhas bit 7 set, get_len() reads a second byte as well.\n\nThis can be triggered remotely by sending a crafted Q.931 SETUP message\nwith a User-User Information Element containing exactly 2 bytes of\nPER-encoded data ({0x08, 0x00}) to port 1720 through a firewall with\nthe nf_conntrack_h323 helper active.  The decoder fully consumes the\nPER buffer before reaching this code path, resulting in a 1-2 byte\nheap-buffer-overflow read confirmed by AddressSanitizer.\n\nFix this by checking for 2 bytes (the maximum that get_len() may read)\ninstead of the uninitialized `len`.  This matches the pattern used at\nevery other get_len() call site in the same file, where the caller\nchecks for 2 bytes of available data before calling get_len().(CVE-2026-43233)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmailbox: Prevent out-of-bounds access in fw_mbox_index_xlate()\n\nAlthough it is guided that `#mbox-cells` must be at least 1, there are\nmany instances of `#mbox-cells = <0>;` in the device tree. If that is\nthe case and the corresponding mailbox controller does not provide\n`fw_xlate` and of_xlate` function pointers, `fw_mbox_index_xlate()` will\nbe used by default and out-of-bounds accesses could occur due to lack of\nbounds check in that function.(CVE-2026-43281)\n\nIn the Linux kernel, there is a double free vulnerability in the error handling path of cpufreq_dbs_governor_init() function. When kobject_init_and_add() fails, cpufreq_dbs_governor_init() calls kobject_put(&dbs_data->attr_set.kobj). The kobject release callback cpufreq_dbs_data_release() calls gov->exit(dbs_data) and kfree(dbs_data), but the current error path then calls gov->exit(dbs_data) and kfree(dbs_data) again, causing a double free. Keep the direct kfree(dbs_data) for the gov->init() failure path, but after kobject_init_and_add() has been called, let kobject_put() handle the cleanup through cpufreq_dbs_data_release().(CVE-2026-43328)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlib/crypto: chacha: Zeroize permuted_state before it leaves scope\n\nSince the ChaCha permutation is invertible, the local variable\n'permuted_state' is sufficient to compute the original 'state', and thus\nthe key, even after the permutation has been done.\n\nWhile the kernel is quite inconsistent about zeroizing secrets on the\nstack (and some prominent userspace crypto libraries don't bother at all\nsince it's not guaranteed to work anyway), the kernel does try to do it\nas a best practice, especially in cases involving the RNG.\n\nThus, explicitly zeroize 'permuted_state' before it goes out of scope.(CVE-2026-43336)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: class: cdc-wdm: fix reordering issue in read code path\n\nQuoting the bug report:\n\nDue to compiler optimization or CPU out-of-order execution, the\ndesc->length update can be reordered before the memmove. If this\nhappens, wdm_read() can see the new length and call copy_to_user() on\nuninitialized memory. This also violates LKMM data race rules [1].\n\nFix it by using WRITE_ONCE and memory barriers.(CVE-2026-43427)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix DMA FIFO desync on error CQE SQ recovery\n\nIn case of a TX error CQE, a recovery flow is triggered,\nmlx5e_reset_txqsq_cc_pc() resets dma_fifo_cc to 0 but not dma_fifo_pc,\ndesyncing the DMA FIFO producer and consumer.\n\nAfter recovery, the producer pushes new DMA entries at the old\ndma_fifo_pc, while the consumer reads from position 0.\nThis causes us to unmap stale DMA addresses from before the recovery.\n\nThe DMA FIFO is a purely software construct with no HW counterpart.\nAt the point of reset, all WQEs have been flushed so dma_fifo_cc is\nalready equal to dma_fifo_pc. There is no need to reset either counter,\nsimilar to how skb_fifo pc/cc are untouched.\n\nRemove the 'dma_fifo_cc = 0' reset.\n\nThis fixes the following WARNING:\n    WARNING: CPU: 0 PID: 0 at drivers/iommu/dma-iommu.c:1240 iommu_dma_unmap_page+0x79/0x90\n    Modules linked in: mlx5_vdpa vringh vdpa bonding mlx5_ib mlx5_vfio_pci ipip mlx5_fwctl tunnel4 mlx5_core ib_ipoib geneve ip6_gre ip_gre gre nf_tables ip6_tunnel rdma_ucm ib_uverbs ib_umad vfio_pci vfio_pci_core act_mirred act_skbedit act_vlan vhost_net vhost tap ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle cls_matchall nfnetlink_cttimeout act_gact cls_flower sch_ingress vhost_iotlb iptable_raw tunnel6 vfio_iommu_type1 vfio openvswitch nsh rpcsec_gss_krb5 auth_rpcgss oid_registry xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter overlay zram zsmalloc rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core fuse [last unloaded: nf_tables]\n    CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5_for_upstream_min_debug_2024_12_30_21_33 #1\n    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n    RIP: 0010:iommu_dma_unmap_page+0x79/0x90\n    Code: 2b 4d 3b 21 72 26 4d 3b 61 08 73 20 49 89 d8 44 89 f9 5b 4c 89 f2 4c 89 e6 48 89 ef 5d 41 5c 41 5d 41 5e 41 5f e9 c7 ae 9e ff <0f> 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00\n    Call Trace:\n     <IRQ>\n     ? __warn+0x7d/0x110\n     ? iommu_dma_unmap_page+0x79/0x90\n     ? report_bug+0x16d/0x180\n     ? handle_bug+0x4f/0x90\n     ? exc_invalid_op+0x14/0x70\n     ? asm_exc_invalid_op+0x16/0x20\n     ? iommu_dma_unmap_page+0x79/0x90\n     ? iommu_dma_unmap_page+0x2e/0x90\n     dma_unmap_page_attrs+0x10d/0x1b0\n     mlx5e_tx_wi_dma_unmap+0xbe/0x120 [mlx5_core]\n     mlx5e_poll_tx_cq+0x16d/0x690 [mlx5_core]\n     mlx5e_napi_poll+0x8b/0xac0 [mlx5_core]\n     __napi_poll+0x24/0x190\n     net_rx_action+0x32a/0x3b0\n     ? mlx5_eq_comp_int+0x7e/0x270 [mlx5_core]\n     ? notifier_call_chain+0x35/0xa0\n     handle_softirqs+0xc9/0x270\n     irq_exit_rcu+0x71/0xd0\n     common_interrupt+0x7f/0xa0\n     </IRQ>\n     <TASK>\n     asm_common_interrupt+0x22/0x40(CVE-2026-43466)\n\nIn the Linux kernel's openvswitch module, the vport netlink reply helpers allocate a fixed-size skb with nlmsg_new(NLMSG_DEFAULT_SIZE, ...) but serialize the full upcall PID array via ovs_vport_get_upcall_portids(). Since ovs_vport_set_upcall_portids() accepts any non-zero multiple of sizeof(u32) with no upper bound, a CAP_NET_ADMIN user can install a PID array large enough to overflow the reply buffer, causing nla_put() to fail with -EMSGSIZE and hitting BUG_ON(err < 0), leading to a kernel panic. On systems with unprivileged user namespaces enabled (e.g., Ubuntu default), this is reachable via unshare -Urn.(CVE-2026-45840)\n\nIn the Linux kernel, the following vulnerability has been resolved:  drm/nouveau: fix u32 overflow in pushbuf reloc bounds check  nouveau_gem_pushbuf_reloc_apply() validates each relocation with      if (r->reloc_bo_offset + 4 > nvbo->bo.base.size)  but reloc_bo_offset is __u32 (uapi/drm/nouveau_drm.h) and the integer literal 4 promotes to unsigned int, so the addition is performed in 32 bits and wraps before the comparison against the size_t bo size.  Cast to u64 so the addition happens in 64-bit arithmetic.  [ Add Fixes: tag. - Danilo ]  The Linux kernel CVE team has assigned CVE-2026-46006 to this issue.(CVE-2026-46006)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nthermal: core: Fix thermal zone governor cleanup issues\n\nIf thermal_zone_device_register_with_trips() fails after adding\na thermal governor to the thermal zone being registered, the\ngovernor is not removed from it as appropriate which may lead to\na memory leak.\n\nIn turn, thermal_zone_device_unregister() calls thermal_set_governor()\nwithout acquiring the thermal zone lock beforehand which may race with\na governor update via sysfs and may lead to a use-after-free in that\ncase.\n\nAddress these issues by adding two thermal_set_governor() calls, one to\nthermal_release() to remove the governor from the given thermal zone,\nand one to the thermal zone registration error path to cover failures\npreceding the thermal zone device registration.(CVE-2026-46021)\n\nIn the Linux kernel, the following vulnerability has been resolved:  dm mirror: fix integer overflow in create_dirty_log()  The argument count calculation in create_dirty_log() performs `*args_used = 2 + param_count` before validating against argc. When a user provides a param_count close to UINT_MAX via the device mapper table string, this unsigned addition wraps around to a small value, causing the subsequent `argc < *args_used` check to be bypassed.  The overflowed param_count is then passed as argc to dm_dirty_log_create(), where it can cause out-of-bounds reads on the argv array.  Fix by comparing param_count against argc - 2 before performing the addition, following the same pattern used by parse_features() in the same file. Since argc >= 2 is already guaranteed, the subtraction is safe.  The Linux kernel CVE team has assigned CVE-2026-46023 to this issue.(CVE-2026-46023)\n\nIn the Linux kernel, the following vulnerability has been resolved:  crypto: authencesn - reject short ahash digests during instance creation  authencesn requires either a zero authsize or an authsize of at least 4 bytes because the ESN encrypt/decrypt paths always move 4 bytes of high-order sequence number data at the end of the authenticated data.  While crypto_authenc_esn_setauthsize() already rejects explicit non-zero authsizes in the range 1..3, crypto_authenc_esn_create() still copied auth->digestsize into inst->alg.maxauthsize without validating it.  The AEAD core then initialized the tfm's default authsize from that value.  As a result, selecting an ahash with digest size 1..3, such as cbcmac(cipher_null), exposed authencesn instances whose default authsize was invalid even though setauthsize() would have rejected the same value.  AF_ALG could then trigger the ESN tail handling with a too-short tag and hit an out-of-bounds access.  Reject authencesn instances whose ahash digest size is in the invalid non-zero range 1..3 so that no tfm can inherit an unsupported default authsize.  The Linux kernel CVE team has assigned CVE-2026-46033 to this issue.(CVE-2026-46033)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: only d_add() negative dentries when they are unhashed\n\nCeph can call d_add(dentry, NULL) on a negative dentry that is already\npresent in the primary dcache hash.\n\nIn the current VFS that is not safe.  d_add() goes through __d_add()\nto __d_rehash(), which unconditionally reinserts dentry->d_hash into\nthe hlist_bl bucket.  If the dentry is already hashed, reinserting the\nsame node can corrupt the bucket, including creating a self-loop.\nOnce that happens, __d_lookup() can spin forever in the hlist_bl walk,\ntypically looping only on the d_name.hash mismatch check and\neventually triggering RCU stall reports like this one:\n\n rcu: INFO: rcu_sched self-detected stall on CPU\n rcu:         87-....: (2100 ticks this GP) idle=3a4c/1/0x4000000000000000 softirq=25003319/25003319 fqs=829\n rcu:         (t=2101 jiffies g=79058445 q=698988 ncpus=192)\n CPU: 87 UID: 2952868916 PID: 3933303 Comm: php-cgi8.3 Not tainted 6.18.17-i1-amd #950 NONE\n Hardware name: Dell Inc. PowerEdge R7615/0G9DHV, BIOS 1.6.6 09/22/2023\n RIP: 0010:__d_lookup+0x46/0xb0\n Code: c1 e8 07 48 8d 04 c2 48 8b 00 49 89 fc 49 89 f5 48 89 c3 48 83 e3 fe 48 83 f8 01 77 0f eb 2d 0f 1f 44 00 00 48 8b 1b 48 85 db <74> 20 39 6b 18 75 f3 48 8d 7b 78 e8 ba 85 d0 00 4c 39 63 10 74 1f\n RSP: 0018:ff745a70c8253898 EFLAGS: 00000282\n RAX: ff26e470054cb208 RBX: ff26e470054cb208 RCX: 000000006e958966\n RDX: ff26e48267340000 RSI: ff745a70c82539b0 RDI: ff26e458f74655c0\n RBP: 000000006e958966 R08: 0000000000000180 R09: 9cd08d909b919a89\n R10: ff26e458f74655c0 R11: 0000000000000000 R12: ff26e458f74655c0\n R13: ff745a70c82539b0 R14: d0d0d0d0d0d0d0d0 R15: 2f2f2f2f2f2f2f2f\n FS:  00007f5770896980(0000) GS:ff26e482c5d88000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f5764de50c0 CR3: 000000a72abb5001 CR4: 0000000000771ef0\n PKRU: 55555554\n Call Trace:\n  <TASK>\n  lookup_fast+0x9f/0x100\n  walk_component+0x1f/0x150\n  link_path_walk+0x20e/0x3d0\n  path_lookupat+0x68/0x180\n  filename_lookup+0xdc/0x1e0\n  vfs_statx+0x6c/0x140\n  vfs_fstatat+0x67/0xa0\n  __do_sys_newfstatat+0x24/0x60\n  do_syscall_64+0x6a/0x230\n  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThis is reachable with reused cached negative dentries.  A Ceph lookup\nor atomic_open can be handed a negative dentry that is already hashed,\nand fs/ceph/dir.c then hits one of two paths that incorrectly assume\n"negative" also means "unhashed":\n\n  - ceph_finish_lookup():\n      MDS reply is -ENOENT with no trace\n      -> d_add(dentry, NULL)\n\n  - ceph_lookup():\n      local ENOENT fast path for a complete directory with shared caps\n      -> d_add(dentry, NULL)\n\nBoth paths can therefore re-add an already-hashed negative dentry.\n\nCeph already uses the correct pattern elsewhere: ceph_fill_trace() only\ncalls d_add(dn, NULL) for a negative null-dentry reply when d_unhashed(dn)\nis true.\n\nFix both fs/ceph/dir.c sites the same way: only call d_add() for a\nnegative dentry when it is actually unhashed.  If the negative dentry\nis already hashed, leave it in place and reuse it as-is.\n\nThis preserves the existing behavior for unhashed dentries while\navoiding d_hash list corruption for reused hashed negatives.(CVE-2026-46052)\n\nIn the Linux kernel, the following vulnerability has been resolved: sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL. The SCTP_SENDALL path in sctp_sendmsg() iterates ep->asocs with list_for_each_entry_safe(), which caches the next entry in @tmp before the loop body runs. The body calls sctp_sendmsg_to_asoc(), which may drop the socket lock inside sctp_wait_for_sndbuf(). While the lock is dropped, another thread can SCTP_SOCKOPT_PEELOFF the association cached in @tmp, migrating it to a new endpoint via sctp_sock_migrate() (list_del_init() + list_add_tail() to newep->asocs), and optionally close the new socket which frees the association via kfree_rcu(). The cached @tmp can also be freed by a network ABORT for that association, processed in softirq while the lock is dropped. sctp_wait_for_sndbuf() revalidates @asoc (the current entry) on re-lock via the "sk != asoc->base.sk" and "asoc->base.dead" checks, but nothing revalidates @tmp. After a successful return, the iterator advances to the stale @tmp, yielding either a use-after-free (if the peeled socket was closed) or a list-walk onto the new endpoint's list head (type confusion of &newep->asocs as a struct sctp_association *). Both are reachable from CapEff=0; the type-confusion path gives controlled indirect call via the outqueue.sched->init_sid pointer. Fix by re-deriving @tmp from @asoc after sctp_sendmsg_to_asoc() returns. @asoc is known to still be on ep->asocs at that point: the only callers that list_del an association from ep->asocs are sctp_association_free() (which sets asoc->base.dead) and sctp_assoc_migrate() (which changes asoc->base.sk), and sctp_wait_for_sndbuf() checks both under the lock before any successful return; a tripped check propagates as err < 0 and the loop bails before the re-derive. The SCTP_ABORT path in sctp_sendmsg_check_sflags() returns 0 and the loop hits 'continue' before sctp_sendmsg_to_asoc() is ever called, so the @tmp cached by list_for_each_entry_safe() still covers the lock-held free that ba59fb027307 ("sctp: walk the list of asocs safely") was added for.(CVE-2026-46227)","affected":[{"package":{"ecosystem":"openEuler:20.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-20.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.19.90-2606.1.0.0375.oe2003sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-4.19.90-2606.1.0.0375.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2606.1.0.0375.oe2003sp4.aarch64.rpm","kernel-4.19.90-2606.1.0.0375.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2606.1.0.0375.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2606.1.0.0375.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2606.1.0.0375.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2606.1.0.0375.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2606.1.0.0375.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2606.1.0.0375.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2606.1.0.0375.oe2003sp4.aarch64.rpm","perf-4.19.90-2606.1.0.0375.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2606.1.0.0375.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2606.1.0.0375.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2606.1.0.0375.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2606.1.0.0375.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2606.1.0.0375.oe2003sp4.aarch64.rpm"],"src":["kernel-4.19.90-2606.1.0.0375.oe2003sp4.src.rpm"],"x86_64":["bpftool-4.19.90-2606.1.0.0375.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2606.1.0.0375.oe2003sp4.x86_64.rpm","kernel-4.19.90-2606.1.0.0375.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2606.1.0.0375.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2606.1.0.0375.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2606.1.0.0375.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2606.1.0.0375.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2606.1.0.0375.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2606.1.0.0375.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2606.1.0.0375.oe2003sp4.x86_64.rpm","perf-4.19.90-2606.1.0.0375.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2606.1.0.0375.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2606.1.0.0375.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2606.1.0.0375.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2606.1.0.0375.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2606.1.0.0375.oe2003sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2579"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38263"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38403"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38459"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38602"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38644"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39738"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40020"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68340"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23243"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23273"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31586"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31588"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31678"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31759"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31781"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43037"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43038"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43139"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43158"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43180"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43190"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43233"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43281"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43328"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43336"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43427"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43466"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45840"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46006"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46021"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46023"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46033"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46052"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46227"}],"database_specific":{"severity":"Critical"}}