{"schema_version":"1.7.2","id":"OESA-2026-2580","modified":"2026-06-05T15:49:53Z","published":"2026-06-05T15:49:53Z","upstream":["CVE-2023-54285","CVE-2025-38263","CVE-2025-38459","CVE-2025-38512","CVE-2025-38602","CVE-2025-38652","CVE-2025-38734","CVE-2025-39738","CVE-2025-39788","CVE-2025-39864","CVE-2025-39957","CVE-2025-40168","CVE-2025-68223","CVE-2025-68340","CVE-2025-68789","CVE-2025-68813","CVE-2025-71067","CVE-2025-71085","CVE-2026-23001","CVE-2026-23074","CVE-2026-23107","CVE-2026-23272","CVE-2026-23318","CVE-2026-31466","CVE-2026-31588","CVE-2026-31619","CVE-2026-31662","CVE-2026-31678","CVE-2026-31712","CVE-2026-31759","CVE-2026-31777","CVE-2026-31778","CVE-2026-31781","CVE-2026-43033","CVE-2026-43037","CVE-2026-43038","CVE-2026-43180","CVE-2026-43194","CVE-2026-43281","CVE-2026-43287","CVE-2026-43328","CVE-2026-43334","CVE-2026-43336","CVE-2026-43427","CVE-2026-43466","CVE-2026-43475","CVE-2026-43503","CVE-2026-45856","CVE-2026-45968","CVE-2026-45981","CVE-2026-45984","CVE-2026-46021","CVE-2026-46033","CVE-2026-46052","CVE-2026-46151","CVE-2026-46167","CVE-2026-46181","CVE-2026-46187","CVE-2026-46214"],"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\niomap: Fix possible overflow condition in iomap_write_delalloc_scan\n\nfolio_next_index() returns an unsigned long value which left shifted\nby PAGE_SHIFT could possibly cause an overflow on 32-bit system. Instead\nuse folio_pos(folio) + folio_size(folio), which does this correctly.(CVE-2023-54285)\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\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\nwifi: prevent A-MSDU attacks in mesh networks\n\nThis patch is a mitigation to prevent the A-MSDU spoofing vulnerability\nfor mesh networks. The initial update to the IEEE 802.11 standard, in\nresponse to the FragAttacks, missed this case (CVE-2025-27558). It can\nbe considered a variant of CVE-2020-24588 but for mesh networks.\n\nThis patch tries to detect if a standard MSDU was turned into an A-MSDU\nby an adversary. This is done by parsing a received A-MSDU as a standard\nMSDU, calculating the length of the Mesh Control header, and seeing if\nthe 6 bytes after this header equal the start of an rfc1042 header. If\nequal, this is a strong indication of an ongoing attack attempt.\n\nThis defense was tested with mac80211_hwsim against a mesh network that\nuses an empty Mesh Address Extension field, i.e., when four addresses\nare used, and when using a 12-byte Mesh Address Extension field, i.e.,\nwhen six addresses are used. Functionality of normal MSDUs and A-MSDUs\nwas also tested, and confirmed working, when using both an empty and\n12-byte Mesh Address Extension field.\n\nIt was also tested with mac80211_hwsim that A-MSDU attacks in non-mesh\nnetworks keep being detected and prevented.\n\nNote that the vulnerability being patched, and the defense being\nimplemented, was also discussed in the following paper and in the\nfollowing IEEE 802.11 presentation:\n\nhttps://papers.mathyvanhoef.com/wisec2025.pdf\nhttps://mentor.ieee.org/802.11/dcn/25/11-25-0949-00-000m-a-msdu-mesh-spoof-protection.docx(CVE-2025-38512)\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\nf2fs: fix to avoid out-of-boundary access in devs.path\n\n- touch /mnt/f2fs/012345678901234567890123456789012345678901234567890123\n- truncate -s $((1024*1024*1024)) \\\n  /mnt/f2fs/012345678901234567890123456789012345678901234567890123\n- touch /mnt/f2fs/file\n- truncate -s $((1024*1024*1024)) /mnt/f2fs/file\n- mkfs.f2fs /mnt/f2fs/012345678901234567890123456789012345678901234567890123 \\\n  -c /mnt/f2fs/file\n- mount /mnt/f2fs/012345678901234567890123456789012345678901234567890123 \\\n  /mnt/f2fs/loop\n\n[16937.192225] F2FS-fs (loop0): Mount Device [ 0]: /mnt/f2fs/012345678901234567890123456789012345678901234567890123\\xff\\x01,      511,        0 -    3ffff\n[16937.192268] F2FS-fs (loop0): Failed to find devices\n\nIf device path length equals to MAX_PATH_LEN, sbi->devs.path[] may\nnot end up w/ null character due to path array is fully filled, So\naccidently, fields locate after path[] may be treated as part of\ndevice path, result in parsing wrong device path.\n\nstruct f2fs_dev_info {\n...\n\tchar path[MAX_PATH_LEN];\n...\n};\n\nLet's add one byte space for sbi->devs.path[] to store null\ncharacter of device path string.(CVE-2025-38652)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: fix UAF on smcsk after smc_listen_out()\n\nBPF CI testing report a UAF issue:\n\n  [   16.446633] BUG: kernel NULL pointer dereference, address: 000000000000003  0\n  [   16.447134] #PF: supervisor read access in kernel mod  e\n  [   16.447516] #PF: error_code(0x0000) - not-present pag  e\n  [   16.447878] PGD 0 P4D   0\n  [   16.448063] Oops: Oops: 0000 [#1] PREEMPT SMP NOPT  I\n  [   16.448409] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Tainted: G           OE      6.13.0-rc3-g89e8a75fda73-dirty #4  2\n  [   16.449124] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODUL  E\n  [   16.449502] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/201  4\n  [   16.450201] Workqueue: smc_hs_wq smc_listen_wor  k\n  [   16.450531] RIP: 0010:smc_listen_work+0xc02/0x159  0\n  [   16.452158] RSP: 0018:ffffb5ab40053d98 EFLAGS: 0001024  6\n  [   16.452526] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 000000000000030  0\n  [   16.452994] RDX: 0000000000000280 RSI: 00003513840053f0 RDI: 000000000000000  0\n  [   16.453492] RBP: ffffa097808e3800 R08: ffffa09782dba1e0 R09: 000000000000000  5\n  [   16.453987] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa0978274640  0\n  [   16.454497] R13: 0000000000000000 R14: 0000000000000000 R15: ffffa09782d4092  0\n  [   16.454996] FS:  0000000000000000(0000) GS:ffffa097bbc00000(0000) knlGS:000000000000000  0\n  [   16.455557] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003  3\n  [   16.455961] CR2: 0000000000000030 CR3: 0000000102788004 CR4: 0000000000770ef  0\n  [   16.456459] PKRU: 5555555  4\n  [   16.456654] Call Trace  :\n  [   16.456832]  <TASK  >\n  [   16.456989]  ? __die+0x23/0x7  0\n  [   16.457215]  ? page_fault_oops+0x180/0x4c  0\n  [   16.457508]  ? __lock_acquire+0x3e6/0x249  0\n  [   16.457801]  ? exc_page_fault+0x68/0x20  0\n  [   16.458080]  ? asm_exc_page_fault+0x26/0x3  0\n  [   16.458389]  ? smc_listen_work+0xc02/0x159  0\n  [   16.458689]  ? smc_listen_work+0xc02/0x159  0\n  [   16.458987]  ? lock_is_held_type+0x8f/0x10  0\n  [   16.459284]  process_one_work+0x1ea/0x6d  0\n  [   16.459570]  worker_thread+0x1c3/0x38  0\n  [   16.459839]  ? __pfx_worker_thread+0x10/0x1  0\n  [   16.460144]  kthread+0xe0/0x11  0\n  [   16.460372]  ? __pfx_kthread+0x10/0x1  0\n  [   16.460640]  ret_from_fork+0x31/0x5  0\n  [   16.460896]  ? __pfx_kthread+0x10/0x1  0\n  [   16.461166]  ret_from_fork_asm+0x1a/0x3  0\n  [   16.461453]  </TASK  >\n  [   16.461616] Modules linked in: bpf_testmod(OE) [last unloaded: bpf_testmod(OE)  ]\n  [   16.462134] CR2: 000000000000003  0\n  [   16.462380] ---[ end trace 0000000000000000 ]---\n  [   16.462710] RIP: 0010:smc_listen_work+0xc02/0x1590\n\nThe direct cause of this issue is that after smc_listen_out_connected(),\nnewclcsock->sk may be NULL since it will releases the smcsk. Therefore,\nif the application closes the socket immediately after accept,\nnewclcsock->sk can be NULL. A possible execution order could be as\nfollows:\n\nsmc_listen_work                                 | userspace\n-----------------------------------------------------------------\nlock_sock(sk)                                   |\nsmc_listen_out_connected()                      |\n| \\- smc_listen_out                             |\n|    | \\- release_sock                          |\n     | |- sk->sk_data_ready()                   |\n                                                | fd = accept();\n                                                | close(fd);\n                                                |  \\- socket->sk = NULL;\n/* newclcsock->sk is NULL now */\nSMC_STAT_SERV_SUCC_INC(sock_net(newclcsock->sk))\n\nSince smc_listen_out_connected() will not fail, simply swapping the order\nof the code can easily fix this issue.(CVE-2025-38734)\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\nscsi: ufs: exynos: Fix programming of HCI_UTRL_NEXUS_TYPE\n\nOn Google gs101, the number of UTP transfer request slots (nutrs) is 32,\nand in this case the driver ends up programming the UTRL_NEXUS_TYPE\nincorrectly as 0.\n\nThis is because the left hand side of the shift is 1, which is of type\nint, i.e. 31 bits wide. Shifting by more than that width results in\nundefined behaviour.\n\nFix this by switching to the BIT() macro, which applies correct type\ncasting as required. This ensures the correct value is written to\nUTRL_NEXUS_TYPE (0xffffffff on gs101), and it also fixes a UBSAN shift\nwarning:\n\n    UBSAN: shift-out-of-bounds in drivers/ufs/host/ufs-exynos.c:1113:21\n    shift exponent 32 is too large for 32-bit type 'int'\n\nFor consistency, apply the same change to the nutmrs / UTMRL_NEXUS_TYPE\nwrite.(CVE-2025-39788)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: fix use-after-free in cmp_bss()\n\nFollowing bss_free() quirk introduced in commit 776b3580178f\n("cfg80211: track hidden SSID networks properly"), adjust\ncfg80211_update_known_bss() to free the last beacon frame\nelements only if they're not shared via the corresponding\n'hidden_beacon_bss' pointer.(CVE-2025-39864)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: increase scan_ies_len for S1G\n\nCurrently the S1G capability element is not taken into account\nfor the scan_ies_len, which leads to a buffer length validation\nfailure in ieee80211_prep_hw_scan() and subsequent WARN in\n__ieee80211_start_scan(). This prevents hw scanning from functioning.\nTo fix ensure we accommodate for the S1G capability length.(CVE-2025-39957)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmc: Use __sk_dst_get() and dst_dev_rcu() in smc_clc_prfx_match().\n\nsmc_clc_prfx_match() is called from smc_listen_work() and\nnot under RCU nor RTNL.\n\nUsing sk_dst_get(sk)->dev could trigger UAF.\n\nLet's use __sk_dst_get() and dst_dev_rcu().\n\nNote that the returned value of smc_clc_prfx_match() is not\nused in the caller.(CVE-2025-40168)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/radeon: delete radeon_fence_process in is_signaled, no deadlock\n\nDelete the attempt to progress the queue when checking if fence is\nsignaled. This avoids deadlock.\n\ndma-fence_ops::signaled can be called with the fence lock in unknown\nstate. For radeon, the fence lock is also the wait queue lock. This can\ncause a self deadlock when signaled() tries to make forward progress on\nthe wait queue. But advancing the queue is unneeded because incorrectly\nreturning false from signaled() is perfectly acceptable.\n\n(cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)(CVE-2025-68223)\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\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-68789)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: fix ipv4 null-ptr-deref in route error path\n\nThe IPv4 code path in __ip_vs_get_out_rt() calls dst_link_failure()\nwithout ensuring skb->dev is set, leading to a NULL pointer dereference\nin fib_compute_spec_dst() when ipv4_link_failure() attempts to send\nICMP destination unreachable messages.\n\nThe issue emerged after commit ed0de45a1008 ("ipv4: recompile ip options\nin ipv4_link_failure") started calling __ip_options_compile() from\nipv4_link_failure(). This code path eventually calls fib_compute_spec_dst()\nwhich dereferences skb->dev. An attempt was made to fix the NULL skb->dev\ndereference in commit 0113d9c9d1cc ("ipv4: fix null-deref in\nipv4_link_failure"), but it only addressed the immediate dev_net(skb->dev)\ndereference by using a fallback device. The fix was incomplete because\nfib_compute_spec_dst() later in the call chain still accesses skb->dev\ndirectly, which remains NULL when IPVS calls dst_link_failure().\n\nThe crash occurs when:\n1. IPVS processes a packet in NAT mode with a misconfigured destination\n2. Route lookup fails in __ip_vs_get_out_rt() before establishing a route\n3. The error path calls dst_link_failure(skb) with skb->dev == NULL\n4. ipv4_link_failure() → ipv4_send_dest_unreach() →\n   __ip_options_compile() → fib_compute_spec_dst()\n5. fib_compute_spec_dst() dereferences NULL skb->dev\n\nApply the same fix used for IPv6 in commit 326bf17ea5d4 ("ipvs: fix\nipv6 route unreach panic"): set skb->dev from skb_dst(skb)->dev before\ncalling dst_link_failure().\n\nKASAN: null-ptr-deref in range [0x0000000000000328-0x000000000000032f]\nCPU: 1 PID: 12732 Comm: syz.1.3469 Not tainted 6.6.114 #2\nRIP: 0010:__in_dev_get_rcu include/linux/inetdevice.h:233\nRIP: 0010:fib_compute_spec_dst+0x17a/0x9f0 net/ipv4/fib_frontend.c:285\nCall Trace:\n  <TASK>\n  spec_dst_fill net/ipv4/ip_options.c:232\n  spec_dst_fill net/ipv4/ip_options.c:229\n  __ip_options_compile+0x13a1/0x17d0 net/ipv4/ip_options.c:330\n  ipv4_send_dest_unreach net/ipv4/route.c:1252\n  ipv4_link_failure+0x702/0xb80 net/ipv4/route.c:1265\n  dst_link_failure include/net/dst.h:437\n  __ip_vs_get_out_rt+0x15fd/0x19e0 net/netfilter/ipvs/ip_vs_xmit.c:412\n  ip_vs_nat_xmit+0x1d8/0xc80 net/netfilter/ipvs/ip_vs_xmit.c:764(CVE-2025-68813)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nntfs: set dummy blocksize to read boot_block when mounting\n\nWhen mounting, sb->s_blocksize is used to read the boot_block without\nbeing defined or validated. Set a dummy blocksize before attempting to\nread the boot_block.\n\nThe issue can be triggered with the following syz reproducer:\n\n  mkdirat(0xffffffffffffff9c, &(0x7f0000000080)='./file1\\x00', 0x0)\n  r4 = openat$nullb(0xffffffffffffff9c, &(0x7f0000000040), 0x121403, 0x0)\n  ioctl$FS_IOC_SETFLAGS(r4, 0x40081271, &(0x7f0000000980)=0x4000)\n  mount(&(0x7f0000000140)=@nullb, &(0x7f0000000040)='./cgroup\\x00',\n        &(0x7f0000000000)='ntfs3\\x00', 0x2208004, 0x0)\n  syz_clone(0x88200200, 0x0, 0x0, 0x0, 0x0, 0x0)\n\nHere, the ioctl sets the bdev block size to 16384. During mount,\nget_tree_bdev_flags() calls sb_set_blocksize(sb, block_size(bdev)),\nbut since block_size(bdev) > PAGE_SIZE, sb_set_blocksize() leaves\nsb->s_blocksize at zero.\n\nLater, ntfs_init_from_boot() attempts to read the boot_block while\nsb->s_blocksize is still zero, which triggers the bug.\n\n[(CVE-2025-71067)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: BUG() in pskb_expand_head() as part of calipso_skbuff_setattr()\n\nThere exists a kernel oops caused by a BUG_ON(nhead < 0) at\nnet/core/skbuff.c:2232 in pskb_expand_head().\nThis bug is triggered as part of the calipso_skbuff_setattr()\nroutine when skb_cow() is passed headroom > INT_MAX\n(i.e. (int)(skb_headroom(skb) + len_delta) < 0).\n\nThe root cause of the bug is due to an implicit integer cast in\n__skb_cow(). The check (headroom > skb_headroom(skb)) is meant to ensure\nthat delta = headroom - skb_headroom(skb) is never negative, otherwise\nwe will trigger a BUG_ON in pskb_expand_head(). However, if\nheadroom > INT_MAX and delta <= -NET_SKB_PAD, the check passes, delta\nbecomes negative, and pskb_expand_head() is passed a negative value for\nnhead.\n\nFix the trigger condition in calipso_skbuff_setattr(). Avoid passing\n"negative" headroom sizes to skb_cow() within calipso_skbuff_setattr()\nby only using skb_cow() to grow headroom.\n\nPoC:\n\tUsing `netlabelctl` tool:\n\n        netlabelctl map del default\n        netlabelctl calipso add pass doi:7\n        netlabelctl map add default address:0::1/128 protocol:calipso,7\n\n        Then run the following PoC:\n\n        int fd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP);\n\n        // setup msghdr\n        int cmsg_size = 2;\n        int cmsg_len = 0x60;\n        struct msghdr msg;\n        struct sockaddr_in6 dest_addr;\n        struct cmsghdr * cmsg = (struct cmsghdr *) calloc(1,\n                        sizeof(struct cmsghdr) + cmsg_len);\n        msg.msg_name = &dest_addr;\n        msg.msg_namelen = sizeof(dest_addr);\n        msg.msg_iov = NULL;\n        msg.msg_iovlen = 0;\n        msg.msg_control = cmsg;\n        msg.msg_controllen = cmsg_len;\n        msg.msg_flags = 0;\n\n        // setup sockaddr\n        dest_addr.sin6_family = AF_INET6;\n        dest_addr.sin6_port = htons(31337);\n        dest_addr.sin6_flowinfo = htonl(31337);\n        dest_addr.sin6_addr = in6addr_loopback;\n        dest_addr.sin6_scope_id = 31337;\n\n        // setup cmsghdr\n        cmsg->cmsg_len = cmsg_len;\n        cmsg->cmsg_level = IPPROTO_IPV6;\n        cmsg->cmsg_type = IPV6_HOPOPTS;\n        char * hop_hdr = (char *)cmsg + sizeof(struct cmsghdr);\n        hop_hdr[1] = 0x9; //set hop size - (0x9 + 1) * 8 = 80\n\n        sendmsg(fd, &msg, 0);(CVE-2025-71085)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmacvlan: fix possible UAF in macvlan_forward_source()\n\nAdd RCU protection on (struct macvlan_source_entry)->vlan.\n\nWhenever macvlan_hash_del_source() is called, we must clear\nentry->vlan pointer before RCU grace period starts.\n\nThis allows macvlan_forward_source() to skip over\nentries queued for freeing.\n\nNote that macvlan_dev are already RCU protected, as they\nare embedded in a standard netdev (netdev_priv(ndev)).\n\nhttps: //lore.kernel.org/netdev/(CVE-2026-23001)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: Enforce that teql can only be used as root qdisc\n\nDesign intent of teql is that it is only supposed to be used as root qdisc.\nWe need to check for that constraint.\n\nAlthough not important, I will describe the scenario that unearthed this\nissue for the curious.\n\nGangMin Kim <(CVE-2026-23074)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64/fpsimd: signal: Allocate SSVE storage when restoring ZA\n\nThe code to restore a ZA context doesn't attempt to allocate the task's\nsve_state before setting TIF_SME. Consequently, restoring a ZA context\ncan place a task into an invalid state where TIF_SME is set but the\ntask's sve_state is NULL.\n\nIn legitimate but uncommon cases where the ZA signal context was NOT\ncreated by the kernel in the context of the same task (e.g. if the task\nis saved/restored with something like CRIU), we have no guarantee that\nsve_state had been allocated previously. In these cases, userspace can\nenter streaming mode without trapping while sve_state is NULL, causing a\nlater NULL pointer dereference when the kernel attempts to store the\nregister state:\n\n| # ./sigreturn-za\n| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n| Mem abort info:\n|   ESR = 0x0000000096000046\n|   EC = 0x25: DABT (current EL), IL = 32 bits\n|   SET = 0, FnV = 0\n|   EA = 0, S1PTW = 0\n|   FSC = 0x06: level 2 translation fault\n| Data abort info:\n|   ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000\n|   CM = 0, WnR = 1, TnD = 0, TagAccess = 0\n|   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n| user pgtable: 4k pages, 52-bit VAs, pgdp=0000000101f47c00\n| [0000000000000000] pgd=08000001021d8403, p4d=0800000102274403, pud=0800000102275403, pmd=0000000000000000\n| Internal error: Oops: 0000000096000046 [#1]  SMP\n| Modules linked in:\n| CPU: 0 UID: 0 PID: 153 Comm: sigreturn-za Not tainted 6.19.0-rc1 #1 PREEMPT\n| Hardware name: linux,dummy-virt (DT)\n| pstate: 214000c9 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n| pc : sve_save_state+0x4/0xf0\n| lr : fpsimd_save_user_state+0xb0/0x1c0\n| sp : ffff80008070bcc0\n| x29: ffff80008070bcc0 x28: fff00000c1ca4c40 x27: 63cfa172fb5cf658\n| x26: fff00000c1ca5228 x25: 0000000000000000 x24: 0000000000000000\n| x23: 0000000000000000 x22: fff00000c1ca4c40 x21: fff00000c1ca4c40\n| x20: 0000000000000020 x19: fff00000ff6900f0 x18: 0000000000000000\n| x17: fff05e8e0311f000 x16: 0000000000000000 x15: 028fca8f3bdaf21c\n| x14: 0000000000000212 x13: fff00000c0209f10 x12: 0000000000000020\n| x11: 0000000000200b20 x10: 0000000000000000 x9 : fff00000ff69dcc0\n| x8 : 00000000000003f2 x7 : 0000000000000001 x6 : fff00000c1ca5b48\n| x5 : fff05e8e0311f000 x4 : 0000000008000000 x3 : 0000000000000000\n| x2 : 0000000000000001 x1 : fff00000c1ca5970 x0 : 0000000000000440\n| Call trace:\n|  sve_save_state+0x4/0xf0 (P)\n|  fpsimd_thread_switch+0x48/0x198\n|  __switch_to+0x20/0x1c0\n|  __schedule+0x36c/0xce0\n|  schedule+0x34/0x11c\n|  exit_to_user_mode_loop+0x124/0x188\n|  el0_interrupt+0xc8/0xd8\n|  __el0_irq_handler_common+0x18/0x24\n|  el0t_64_irq_handler+0x10/0x1c\n|  el0t_64_irq+0x198/0x19c\n| Code: 54000040 d51b4408 d65f03c0 d503245f (e5bb5800)\n| ---[ end trace 0000000000000000 ]---\n\nFix this by having restore_za_context() ensure that the task's sve_state\nis allocated, matching what we do when taking an SME trap. Any live\nSVE/SSVE state (which is restored earlier from a separate signal\ncontext) must be preserved, and hence this is not zeroed.(CVE-2026-23107)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: unconditionally bump set->nelems before insertion\n\nIn case that the set is full, a new element gets published then removed\nwithout waiting for the RCU grace period, while RCU reader can be\nwalking over it already.\n\nTo address this issue, add the element transaction even if set is full,\nbut toggle the set_full flag to report -ENFILE so the abort path safely\nunwinds the set to its previous state.\n\nAs for element updates, decrement set->nelems to restore it.\n\nA simpler fix is to call synchronize_rcu() in the error path.\nHowever, with a large batch adding elements to already maxed-out set,\nthis could cause noticeable slowdown of such batches.(CVE-2026-23272)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: Use correct version for UAC3 header validation\n\nThe entry of the validators table for UAC3 AC header descriptor is\ndefined with the wrong protocol version UAC_VERSION_2, while it should\nhave been UAC_VERSION_3.  This results in the validator never matching\nfor actual UAC3 devices (protocol == UAC_VERSION_3), causing their\nheader descriptors to bypass validation entirely.  A malicious USB\ndevice presenting a truncated UAC3 header could exploit this to cause\nout-of-bounds reads when the driver later accesses unvalidated\ndescriptor fields.\n\nThe bug was introduced in the same commit as the recently fixed UAC3\nfeature unit sub-type typo, and appears to be from the same copy-paste\nerror when the UAC3 section was created from the UAC2 section.(CVE-2026-23318)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/huge_memory: fix folio isn't locked in softleaf_to_folio()\n\nOn arm64 server, we found folio that get from migration entry isn't locked\nin softleaf_to_folio().  This issue triggers when mTHP splitting and\nzap_nonpresent_ptes() races, and the root cause is lack of memory barrier\nin softleaf_to_folio().  The race is as follows:\n\n\tCPU0                                             CPU1\n\ndeferred_split_scan()                              zap_nonpresent_ptes()\n  lock folio\n  split_folio()\n    unmap_folio()\n      change ptes to migration entries\n    __split_folio_to_order()                         softleaf_to_folio()\n      set flags(including PG_locked) for tail pages    folio = pfn_folio(softleaf_to_pfn(entry))\n      smp_wmb()                                        VM_WARN_ON_ONCE(!folio_test_locked(folio))\n      prep_compound_page() for tail pages\n\nIn __split_folio_to_order(), smp_wmb() guarantees page flags of tail pages\nare visible before the tail page becomes non-compound.  smp_wmb() should\nbe paired with smp_rmb() in softleaf_to_folio(), which is missed.  As a\nresult, if zap_nonpresent_ptes() accesses migration entry that stores tail\npfn, softleaf_to_folio() may see the updated compound_head of tail page\nbefore page->flags.\n\nThis issue will trigger VM_WARN_ON_ONCE() in pfn_swap_entry_folio()\nbecause of the race between folio split and zap_nonpresent_ptes()\nleading to a folio incorrectly undergoing modification without a folio\nlock being held.\n\nThis is a BUG_ON() before commit 93976a20345b ("mm: eliminate further\nswapops predicates"), which in merged in v6.19-rc1.\n\nTo fix it, add missing smp_rmb() if the softleaf entry is migration entry\nin softleaf_to_folio() and softleaf_to_page().\n\n[(CVE-2026-31466)\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\nALSA: fireworks: bound device-supplied status before string array lookup\n\nThe status field in an EFW response is a 32-bit value supplied by the\nfirewire device.  efr_status_names[] has 17 entries so a status value\noutside that range goes off into the weeds when looking at the %s value.\n\nEven worse, the status could return EFR_STATUS_INCOMPLETE which is\n0x80000000, and is obviously not in that array of potential strings.\n\nFix this up by properly bounding the index against the array size and\nprinting "unknown" if it's not recognized.(CVE-2026-31619)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG\n\nThe GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrements\nbc_ackers on every inbound group ACK, even when the same member has\nalready acknowledged the current broadcast round.\n\nBecause bc_ackers is a u16, a duplicate ACK received after the last\nlegitimate ACK wraps the counter to 65535. Once wrapped,\ntipc_group_bc_cong() keeps reporting congestion and later group\nbroadcasts on the affected socket stay blocked until the group is\nrecreated.\n\nFix this by ignoring duplicate or stale ACKs before touching bc_acked or\nbc_ackers. This makes repeated GRP_ACK_MSG handling idempotent and\nprevents the underflow path.(CVE-2026-31662)\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\nksmbd: require minimum ACE size in smb_check_perm_dacl()\n\nBoth ACE-walk loops in smb_check_perm_dacl() only guard against an\nunder-sized remaining buffer, not against an ACE whose declared\n`ace->size` is smaller than the struct it claims to describe:\n\n  if (offsetof(struct smb_ace, access_req) > aces_size)\n      break;\n  ace_size = le16_to_cpu(ace->size);\n  if (ace_size > aces_size)\n      break;\n\nThe first check only requires the 4-byte ACE header to be in bounds;\nit does not require access_req (4 bytes at offset 4) to be readable.\nAn attacker who has set a crafted DACL on a file they own can declare\nace->size == 4 with aces_size == 4, pass both checks, and then\n\n  granted |= le32_to_cpu(ace->access_req);               /* upper loop */\n  compare_sids(&sid, &ace->sid);                         /* lower loop */\n\nreads access_req at offset 4 (OOB by up to 4 bytes) and ace->sid at\noffset 8 (OOB by up to CIFS_SID_BASE_SIZE + SID_MAX_SUB_AUTHORITIES\n* 4 bytes).\n\nTighten both loops to require\n\n  ace_size >= offsetof(struct smb_ace, sid) + CIFS_SID_BASE_SIZE\n\nwhich is the smallest valid on-wire ACE layout (4-byte header +\n4-byte access_req + 8-byte sid base with zero sub-auths).  Also\nreject ACEs whose sid.num_subauth exceeds SID_MAX_SUB_AUTHORITIES\nbefore letting compare_sids() dereference sub_auth[] entries.\n\nparse_sec_desc() already enforces an equivalent check (lines 441-448);\nsmb_check_perm_dacl() simply grew weaker validation over time.\n\nReachability: authenticated SMB client with permission to set an ACL\non a file.  On a subsequent CREATE against that file, the kernel\nwalks the stored DACL via smb_check_perm_dacl() and triggers the\nOOB read.  Not pre-auth, and the OOB read is not reflected to the\nattacker, but KASAN reports and kernel state corruption are\npossible.(CVE-2026-31712)\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\nALSA: ctxfi: Check the error for index mapping\n\nThe ctxfi driver blindly assumed a proper value returned from\ndaio_device_index(), but it's not always true.  Add a proper error\ncheck to deal with the error from the function.(CVE-2026-31777)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: caiaq: fix stack out-of-bounds read in init_card\n\nThe loop creates a whitespace-stripped copy of the card shortname\nwhere `len < sizeof(card->id)` is used for the bounds check. Since\nsizeof(card->id) is 16 and the local id buffer is also 16 bytes,\nwriting 16 non-space characters fills the entire buffer,\noverwriting the terminating nullbyte.\n\nWhen this non-null-terminated string is later passed to\nsnd_card_set_id() -> copy_valid_id_string(), the function scans\nforward with `while (*nid && ...)` and reads past the end of the\nstack buffer, reading the contents of the stack.\n\nA USB device with a product name containing many non-ASCII, non-space\ncharacters (e.g. multibyte UTF-8) will reliably trigger this as follows:\n\n  BUG: KASAN: stack-out-of-bounds in copy_valid_id_string\n       sound/core/init.c:696 [inline]\n  BUG: KASAN: stack-out-of-bounds in snd_card_set_id_no_lock+0x698/0x74c\n       sound/core/init.c:718\n\nThe off-by-one has been present since commit bafeee5b1f8d ("ALSA:\nsnd_usb_caiaq: give better shortname") from June 2009 (v2.6.31-rc1),\nwhich first introduced this whitespace-stripping loop. The original\ncode never accounted for the null terminator when bounding the copy.\n\nFix this by changing the loop bound to `sizeof(card->id) - 1`,\nensuring at least one byte remains as the null terminator.(CVE-2026-31778)\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\ncrypto: authencesn - Do not place hiseq at end of dst for out-of-place decryption\n\nWhen decrypting data that is not in-place (src != dst), there is\nno need to save the high-order sequence bits in dst as it could\nsimply be re-copied from the source.\n\nHowever, the data to be hashed need to be rearranged accordingly.\n\n\nThanks,(CVE-2026-43033)\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\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\nnet: consume xmit errors of GSO frames\n\nudpgro_frglist.sh and udpgro_bench.sh are the flakiest tests\ncurrently in NIPA. They fail in the same exact way, TCP GRO\ntest stalls occasionally and the test gets killed after 10min.\n\nThese tests use veth to simulate GRO. They attach a trivial\n("return XDP_PASS;") XDP program to the veth to force TSO off\nand NAPI on.\n\nDigging into the failure mode we can see that the connection\nis completely stuck after a burst of drops. The sender's snd_nxt\nis at sequence number N [1], but the receiver claims to have\nreceived (rcv_nxt) up to N + 3 * MSS [2]. Last piece of the puzzle\nis that senders rtx queue is not empty (let's say the block in\nthe rtx queue is at sequence number N - 4 * MSS [3]).\n\nIn this state, sender sends a retransmission from the rtx queue\nwith a single segment, and sequence numbers N-4*MSS:N-3*MSS [3].\nReceiver sees it and responds with an ACK all the way up to\nN + 3 * MSS [2]. But sender will reject this ack as TCP_ACK_UNSENT_DATA\nbecause it has no recollection of ever sending data that far out [1].\nAnd we are stuck.\n\nThe root cause is the mess of the xmit return codes. veth returns\nan error when it can't xmit a frame. We end up with a loss event\nlike this:\n\n  -------------------------------------------------\n  |   GSO super frame 1   |   GSO super frame 2   |\n  |-----------------------------------------------|\n  | seg | seg | seg | seg | seg | seg | seg | seg |\n  |  1  |  2  |  3  |  4  |  5  |  6  |  7  |  8  |\n  -------------------------------------------------\n     x    ok    ok    <ok>|  ok    ok    ok   <x>\n                          \\\\\n\t\t\t   snd_nxt\n\n"x" means packet lost by veth, and "ok" means it went thru.\nSince veth has TSO disabled in this test it sees individual segments.\nSegment 1 is on the retransmit queue and will be resent.\n\nSo why did the sender not advance snd_nxt even tho it clearly did\nsend up to seg 8? tcp_write_xmit() interprets the return code\nfrom the core to mean that data has not been sent at all. Since\nTCP deals with GSO super frames, not individual segment the crux\nof the problem is that loss of a single segment can be interpreted\nas loss of all. TCP only sees the last return code for the last\nsegment of the GSO frame (in <> brackets in the diagram above).\n\nOf course for the problem to occur we need a setup or a device\nwithout a Qdisc. Otherwise Qdisc layer disconnects the protocol\nlayer from the device errors completely.\n\nWe have multiple ways to fix this.\n\n 1) make veth not return an error when it lost a packet.\n    While this is what I think we did in the past, the issue keeps\n    reappearing and it's annoying to debug. The game of whack\n    a mole is not great.\n\n 2) fix the damn return codes\n    We only talk about NETDEV_TX_OK and NETDEV_TX_BUSY in the\n    documentation, so maybe we should make the return code from\n    ndo_start_xmit() a boolean. I like that the most, but perhaps\n    some ancient, not-really-networking protocol would suffer.\n\n 3) make TCP ignore the errors\n    It is not entirely clear to me what benefit TCP gets from\n    interpreting the result of ip_queue_xmit()? Specifically once\n    the connection is established and we're pushing data - packet\n    loss is just packet loss?\n\n 4) this fix\n    Ignore the rc in the Qdisc-less+GSO case, since it's unreliable.\n    We already always return OK in the TCQ_F_CAN_BYPASS case.\n    In the Qdisc-less case let's be a bit more conservative and only\n    mask the GSO errors. This path is taken by non-IP-"networks"\n    like CAN, MCTP etc, so we could regress some ancient thing.\n    This is the simplest, but also maybe the hackiest fix?\n\nSimilar fix has been proposed by Eric in the past but never committed\nbecause original reporter was working with an OOT driver and wasn't\nproviding feedback (see Link).(CVE-2026-43194)\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, the following vulnerability has been resolved:\n\ndrm: Account property blob allocations to memcg\n\nDRM_IOCTL_MODE_CREATEPROPBLOB allows userspace to allocate arbitrary-sized\nproperty blobs backed by kernel memory.\n\nCurrently, the blob data allocation is not accounted to the allocating\nprocess's memory cgroup, allowing unprivileged users to trigger unbounded\nkernel memory consumption and potentially cause system-wide OOM.\n\nMark the property blob data allocation with GFP_KERNEL_ACCOUNT so that the memory\nis properly charged to the caller's memcg. This ensures existing cgroup\nmemory limits apply and prevents uncontrolled kernel memory growth without\nintroducing additional policy or per-file limits.(CVE-2026-43287)\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\nBluetooth: SMP: force responder MITM requirements before building the pairing response\n\nsmp_cmd_pairing_req() currently builds the pairing response from the\ninitiator auth_req before enforcing the local BT_SECURITY_HIGH\nrequirement. If the initiator omits SMP_AUTH_MITM, the response can\nalso omit it even though the local side still requires MITM.\n\ntk_request() then sees an auth value without SMP_AUTH_MITM and may\nselect JUST_CFM, making method selection inconsistent with the pairing\npolicy the responder already enforces.\n\nWhen the local side requires HIGH security, first verify that MITM can\nbe achieved from the IO capabilities and then force SMP_AUTH_MITM in the\nresponse in both rsp.auth_req and auth. This keeps the responder auth bits\nand later method selection aligned.(CVE-2026-43334)\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, the following vulnerability has been resolved:\n\nscsi: storvsc: Fix scheduling while atomic on PREEMPT_RT\n\nThis resolves the follow splat and lock-up when running with PREEMPT_RT\nenabled on Hyper-V:\n\n[  415.140818] BUG: scheduling while atomic: stress-ng-iomix/1048/0x00000002\n[  415.140822] INFO: lockdep is turned off.\n[  415.140823] Modules linked in: intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry intel_vsec ghash_clmulni_intel aesni_intel rapl binfmt_misc nls_ascii nls_cp437 vfat fat snd_pcm hyperv_drm snd_timer drm_client_lib drm_shmem_helper snd sg soundcore drm_kms_helper pcspkr hv_balloon hv_utils evdev joydev drm configfs efi_pstore nfnetlink vsock_loopback vmw_vsock_virtio_transport_common hv_sock vmw_vsock_vmci_transport vsock vmw_vmci efivarfs autofs4 ext4 crc16 mbcache jbd2 sr_mod sd_mod cdrom hv_storvsc serio_raw hid_generic scsi_transport_fc hid_hyperv scsi_mod hid hv_netvsc hyperv_keyboard scsi_common\n[  415.140846] Preemption disabled at:\n[  415.140847] [<ffffffffc0656171>] storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc]\n[  415.140854] CPU: 8 UID: 0 PID: 1048 Comm: stress-ng-iomix Not tainted 6.19.0-rc7 #30 PREEMPT_{RT,(full)}\n[  415.140856] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/04/2024\n[  415.140857] Call Trace:\n[  415.140861]  <TASK>\n[  415.140861]  ? storvsc_queuecommand+0x2e1/0xbe0 [hv_storvsc]\n[  415.140863]  dump_stack_lvl+0x91/0xb0\n[  415.140870]  __schedule_bug+0x9c/0xc0\n[  415.140875]  __schedule+0xdf6/0x1300\n[  415.140877]  ? rtlock_slowlock_locked+0x56c/0x1980\n[  415.140879]  ? rcu_is_watching+0x12/0x60\n[  415.140883]  schedule_rtlock+0x21/0x40\n[  415.140885]  rtlock_slowlock_locked+0x502/0x1980\n[  415.140891]  rt_spin_lock+0x89/0x1e0\n[  415.140893]  hv_ringbuffer_write+0x87/0x2a0\n[  415.140899]  vmbus_sendpacket_mpb_desc+0xb6/0xe0\n[  415.140900]  ? rcu_is_watching+0x12/0x60\n[  415.140902]  storvsc_queuecommand+0x669/0xbe0 [hv_storvsc]\n[  415.140904]  ? HARDIRQ_verbose+0x10/0x10\n[  415.140908]  ? __rq_qos_issue+0x28/0x40\n[  415.140911]  scsi_queue_rq+0x760/0xd80 [scsi_mod]\n[  415.140926]  __blk_mq_issue_directly+0x4a/0xc0\n[  415.140928]  blk_mq_issue_direct+0x87/0x2b0\n[  415.140931]  blk_mq_dispatch_queue_requests+0x120/0x440\n[  415.140933]  blk_mq_flush_plug_list+0x7a/0x1a0\n[  415.140935]  __blk_flush_plug+0xf4/0x150\n[  415.140940]  __submit_bio+0x2b2/0x5c0\n[  415.140944]  ? submit_bio_noacct_nocheck+0x272/0x360\n[  415.140946]  submit_bio_noacct_nocheck+0x272/0x360\n[  415.140951]  ext4_read_bh_lock+0x3e/0x60 [ext4]\n[  415.140995]  ext4_block_write_begin+0x396/0x650 [ext4]\n[  415.141018]  ? __pfx_ext4_da_get_block_prep+0x10/0x10 [ext4]\n[  415.141038]  ext4_da_write_begin+0x1c4/0x350 [ext4]\n[  415.141060]  generic_perform_write+0x14e/0x2c0\n[  415.141065]  ext4_buffered_write_iter+0x6b/0x120 [ext4]\n[  415.141083]  vfs_write+0x2ca/0x570\n[  415.141087]  ksys_write+0x76/0xf0\n[  415.141089]  do_syscall_64+0x99/0x1490\n[  415.141093]  ? rcu_is_watching+0x12/0x60\n[  415.141095]  ? finish_task_switch.isra.0+0xdf/0x3d0\n[  415.141097]  ? rcu_is_watching+0x12/0x60\n[  415.141098]  ? lock_release+0x1f0/0x2a0\n[  415.141100]  ? rcu_is_watching+0x12/0x60\n[  415.141101]  ? finish_task_switch.isra.0+0xe4/0x3d0\n[  415.141103]  ? rcu_is_watching+0x12/0x60\n[  415.141104]  ? __schedule+0xb34/0x1300\n[  415.141106]  ? hrtimer_try_to_cancel+0x1d/0x170\n[  415.141109]  ? do_nanosleep+0x8b/0x160\n[  415.141111]  ? hrtimer_nanosleep+0x89/0x100\n[  415.141114]  ? __pfx_hrtimer_wakeup+0x10/0x10\n[  415.141116]  ? xfd_validate_state+0x26/0x90\n[  415.141118]  ? rcu_is_watching+0x12/0x60\n[  415.141120]  ? do_syscall_64+0x1e0/0x1490\n[  415.141121]  ? do_syscall_64+0x1e0/0x1490\n[  415.141123]  ? rcu_is_watching+0x12/0x60\n[  415.141124]  ? do_syscall_64+0x1e0/0x1490\n[  415.141125]  ? do_syscall_64+0x1e0/0x1490\n[  415.141127]  ? irqentry_exit+0x140/0\n---truncated---(CVE-2026-43475)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: skbuff: propagate shared-frag marker through frag-transfer helpers\n\nTwo frag-transfer helpers (__pskb_copy_fclone() and skb_shift()) fail\nto propagate the SKBFL_SHARED_FRAG bit in skb_shinfo()->flags when\nmoving frags from source to destination.  __pskb_copy_fclone() defers\nthe rest of the shinfo metadata to skb_copy_header() after copying\nfrag descriptors, but that helper only carries over gso_{size,segs,\ntype} and never touches skb_shinfo()->flags; skb_shift() moves frag\ndescriptors directly and leaves flags untouched.  As a result, the\ndestination skb keeps a reference to the same externally-owned or\npage-cache-backed pages while reporting skb_has_shared_frag() as\nfalse.\n\nThe mismatch is harmful in any in-place writer that uses\nskb_has_shared_frag() to decide whether shared pages must be detoured\nthrough skb_cow_data().  ESP input is one such writer (esp4.c,\nesp6.c), and a single nft 'dup to <local>' rule -- or any other\nnf_dup_ipv4() / xt_TEE caller -- is enough to land a pskb_copy()'d\nskb in esp_input() with the marker stripped, letting an unprivileged\nuser write into the page cache of a root-owned read-only file via\nauthencesn-ESN stray writes.\n\nSet SKBFL_SHARED_FRAG on the destination whenever frag descriptors\nwere actually moved from the source.  skb_copy() and skb_copy_expand()\nshare skb_copy_header() too but linearize all paged data into freshly\nallocated head storage and emerge with nr_frags == 0, so\nskb_has_shared_frag() returns false on its own; they need no change.\n\nThe same omission exists in skb_gro_receive() and skb_gro_receive_list().\nThe former moves the incoming skb's frag descriptors into the\naccumulator's last sub-skb via two paths (a direct frag-move loop and\nthe head_frag + memcpy path); the latter chains the incoming skb whole\nonto p's frag_list.  Downstream skb_segment() reads only\nskb_shinfo(p)->flags, and skb_segment_list() reuses each sub-skb's\nshinfo as the nskb -- both p and lp must carry the marker.\n\nThe same omission also exists in tcp_clone_payload(), which builds an\nMTU probe skb by moving frag descriptors from skbs on sk_write_queue\ninto a freshly allocated nskb.  The helper falls into the same family\nand warrants the same fix for consistency; no TCP TX-side in-place\nwriter is currently known to reach a user page through this gap, but\na future consumer depending on the marker would regress silently.\n\nThe same omission exists in skb_segment(): the per-iteration flag\nmerge takes only head_skb's flag, and the inner switch that rebinds\nfrag_skb to list_skb on head_skb-frags exhaustion does not fold the\nnew frag_skb's flag into nskb.  Fold frag_skb's flag at both sites\nso segments drawing frags from frag_list members carry the marker.(CVE-2026-43503)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/uverbs: Validate wqe_size before using it in ib_uverbs_post_send\n\nib_uverbs_post_send() uses cmd.wqe_size from userspace without any\nvalidation before passing it to kmalloc() and using the allocated\nbuffer as struct ib_uverbs_send_wr.\n\nIf a user provides a small wqe_size value (e.g., 1), kmalloc() will\nsucceed, but subsequent accesses to user_wr->opcode, user_wr->num_sge,\nand other fields will read beyond the allocated buffer, resulting in\nan out-of-bounds read from kernel heap memory. This could potentially\nleak sensitive kernel information to userspace.\n\nAdditionally, providing an excessively large wqe_size can trigger a\nWARNING in the memory allocation path, as reported by syzkaller.\n\nThis is inconsistent with ib_uverbs_unmarshall_recv() which properly\nvalidates that wqe_size >= sizeof(struct ib_uverbs_recv_wr) before\nproceeding.\n\nAdd the same validation for ib_uverbs_post_send() to ensure wqe_size\nis at least sizeof(struct ib_uverbs_send_wr).(CVE-2026-45856)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncpuidle: Skip governor when only one idle state is available\n\nOn certain platforms (PowerNV systems without a power-mgt DT node),\ncpuidle may register only a single idle state. In cases where that\nsingle state is a polling state (state 0), the ladder governor may\nincorrectly treat state 1 as the first usable state and pass an\nout-of-bounds index. This can lead to a NULL enter callback being\ninvoked, ultimately resulting in a system crash.\n\n[   13.342636] cpuidle-powernv : Only Snooze is available\n[   13.351854] Faulting instruction address: 0x00000000\n[   13.376489] NIP [0000000000000000] 0x0\n[   13.378351] LR  [c000000001e01974] cpuidle_enter_state+0x2c4/0x668\n\nFix this by adding a bail-out in cpuidle_select() that returns state 0\ndirectly when state_count <= 1, bypassing the governor and keeping the\ntick running.(CVE-2026-45968)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/cio: Fix device lifecycle handling in css_alloc_subchannel()\n\n`css_alloc_subchannel()` calls `device_initialize()` before setting up\nthe DMA masks. If `dma_set_coherent_mask()` or `dma_set_mask()` fails,\nthe error path frees the subchannel structure directly, bypassing\nthe device model reference counting.\n\nOnce `device_initialize()` has been called, the embedded struct device\nmust be released via `put_device()`, allowing the release callback to\nfree the container structure.\n\nFix the error path by dropping the initial device reference with\n`put_device()` instead of calling `kfree()` directly.\n\nThis ensures correct device lifetime handling and avoids potential\nuse-after-free or double-free issues.(CVE-2026-45981)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: Fix use-after-free in iomap inline data write path\n\nThe inline data buffer head (dibh) is being released prematurely in\ngfs2_iomap_begin() via release_metapath() while iomap->inline_data\nstill points to dibh->b_data. This causes a use-after-free when\niomap_write_end_inline() later attempts to write to the inline data\narea.\n\nThe bug sequence:\n1. gfs2_iomap_begin() calls gfs2_meta_inode_buffer() to read inode\n   metadata into dibh\n2. Sets iomap->inline_data = dibh->b_data + sizeof(struct gfs2_dinode)\n3. Calls release_metapath() which calls brelse(dibh), dropping refcount\n   to 0\n4. kswapd reclaims the page (~39ms later in the syzbot report)\n5. iomap_write_end_inline() tries to memcpy() to iomap->inline_data\n6. KASAN detects use-after-free write to freed memory\n\nFix by storing dibh in iomap->private and incrementing its refcount\nwith get_bh() in gfs2_iomap_begin(). The buffer is then properly\nreleased in gfs2_iomap_end() after the inline write completes,\nensuring the page stays alive for the entire iomap operation.\n\nNote: A C reproducer is not available for this issue. The fix is based\non analysis of the KASAN report and code review showing the buffer head\nis freed before use.\n\n[agruenba: Take buffer head reference in gfs2_iomap_begin() to avoid\nleaks in gfs2_iomap_get() and gfs2_iomap_alloc().](CVE-2026-45984)\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:  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:\n\nusb: usblp: fix heap leak in IEEE 1284 device ID via short response\n\nusblp_ctrl_msg() collapses the usb_control_msg() return value to\n0/-errno, discarding the actual number of bytes transferred.  A broken\nprinter can complete the GET_DEVICE_ID control transfer short and the\ndriver has no way to know.\n\nusblp_cache_device_id_string() reads the 2-byte big-endian length prefix\nfrom the response and trusts it (clamped only to the buffer bounds).\nThe buffer is kmalloc(1024) at probe time. A device that sends exactly\ntwo bytes (e.g. 0x03 0xFF, claiming a 1023-byte ID) leaves\ndevice_id_string[2..1022] holding stale kmalloc heap.\n\nThat stale data is then exposed:\n  - via the ieee1284_id sysfs attribute (sprintf("%s", buf+2), truncated\n    at the first NUL in the stale heap), and\n  - via the IOCNR_GET_DEVICE_ID ioctl, which copy_to_user()s the full\n    claimed length regardless of NULs, up to 1021 bytes of uninitialized\n    heap, with the leak size chosen by the device.\n\nFix this up by just zapping the buffer with zeros before each request\nsent to the device.(CVE-2026-46151)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: usblp: fix uninitialized heap leak via LPGETSTATUS ioctl\n\nJust like in a previous problem in this driver, usblp_ctrl_msg() will\ncollapse the usb_control_msg() return value to 0/-errno, discarding the\nactual number of bytes transferred.\n\nIdeally that short command should be detected and error out, but many\nprinters are known to send "incorrect" responses back so we can't just\ndo that.\n\nstatusbuf is kmalloc(8) at probe time and never filled before the first\nLPGETSTATUS ioctl.\n\nusblp_read_status() requests 1 byte. If a malicious printer responds\nwith zero bytes, *statusbuf is one byte of stale kmalloc heap,\nsign-extended into the local int status, which the LPGETSTATUS path then\ncopy_to_user()s directly to the ioctl caller.\n\nFix this all by just zapping out the memory buffer when allocated at\nprobe time.  If a later call does a short read, the data will be\nidentical to what the device sent it the last time, so there is no\n"leak" of information happening.(CVE-2026-46167)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx4: Fix mis-use of RCU in mlx4_srq_event()\n\nSashiko points out the radix_tree itself is RCU safe, but nothing ever\nfrees the mlx4_srq struct with RCU, and it isn't even accessed within the\nRCU critical section. It also will crash if an event is delivered before\nthe srq object is finished initializing.\n\nUse the spinlock since it isn't easy to make RCU work, use\nrefcount_inc_not_zero() to protect against partially initialized objects,\nand order the refcount_set() to be after the srq is fully initialized.(CVE-2026-46181)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rsi: fix kthread lifetime race between self-exit and external-stop\n\nRSI driver use both self-exit(kthread_complete_and_exit) and external-stop\n(kthread_stop) when killing a kthread. Generally, kthread_stop() is called\nfirst, and in this case, no particular issues occur.\n\nHowever, in rare instances where kthread_complete_and_exit() is called\nfirst and then kthread_stop() is called, a UAF occurs because the kthread\nobject, which has already exited and been freed, is accessed again.\n\nTherefore, to prevent this with minimal modification, you must remove\nkthread_stop() and change the code to wait until the self-exit operation\nis completed.(CVE-2026-46187)\n\nIn the Linux kernel's vsock/virtio implementation, virtio_transport_recv_listen() calls sk_acceptq_added() before vsock_assign_transport(). If vsock_assign_transport() fails or selects a different transport, the error path returns without calling sk_acceptq_removed(), permanently incrementing sk_ack_backlog. After approximately backlog+1 such failures, sk_acceptq_is_full() returns true, causing the listener to reject all new connections, leading to a denial of service.(CVE-2026-46214)","affected":[{"package":{"ecosystem":"openEuler:22.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-22.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-317.0.0.220.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-5.10.0-317.0.0.220.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-317.0.0.220.oe2203sp4.aarch64.rpm","kernel-5.10.0-317.0.0.220.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-317.0.0.220.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-317.0.0.220.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-317.0.0.220.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-317.0.0.220.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-317.0.0.220.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-317.0.0.220.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-317.0.0.220.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-317.0.0.220.oe2203sp4.aarch64.rpm","perf-5.10.0-317.0.0.220.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-317.0.0.220.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-317.0.0.220.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-317.0.0.220.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-317.0.0.220.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-317.0.0.220.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-317.0.0.220.oe2203sp4.x86_64.rpm","kernel-5.10.0-317.0.0.220.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-317.0.0.220.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-317.0.0.220.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-317.0.0.220.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-317.0.0.220.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-317.0.0.220.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-317.0.0.220.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-317.0.0.220.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-317.0.0.220.oe2203sp4.x86_64.rpm","perf-5.10.0-317.0.0.220.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-317.0.0.220.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-317.0.0.220.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-317.0.0.220.oe2203sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2580"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-54285"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38263"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38459"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38512"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38602"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38652"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38734"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39738"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39788"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39864"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39957"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40168"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68223"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68340"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68789"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68813"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71067"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71085"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23001"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23074"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23107"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23272"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23318"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31466"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31588"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31619"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31662"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31678"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31712"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31759"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31777"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31778"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31781"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43033"},{"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-43180"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43194"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43281"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43287"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43328"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43334"},{"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-43475"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43503"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45856"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45968"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45981"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45984"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46021"},{"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-46151"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46167"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46181"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46187"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46214"}],"database_specific":{"severity":"Critical"}}