{"schema_version":"1.7.2","id":"OESA-2025-2533","modified":"2025-10-24T14:33:57Z","published":"2025-10-24T14:33:57Z","upstream":["CVE-2022-50299","CVE-2022-50314","CVE-2022-50341","CVE-2022-50402","CVE-2022-50427","CVE-2022-50430","CVE-2022-50449","CVE-2022-50497","CVE-2023-53151","CVE-2023-53299","CVE-2023-53313","CVE-2023-53322","CVE-2023-53357","CVE-2023-53380","CVE-2023-53431","CVE-2023-53456","CVE-2023-53506","CVE-2023-53560","CVE-2025-37792","CVE-2025-38449","CVE-2025-39697","CVE-2025-39898","CVE-2025-39998"],"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\nmd: Replace snprintf with scnprintf\n\nCurrent code produces a warning as shown below when total characters\nin the constituent block device names plus the slashes exceeds 200.\nsnprintf() returns the number of characters generated from the given\ninput, which could cause the expression “200 – len” to wrap around\nto a large positive number. Fix this by using scnprintf() instead,\nwhich returns the actual number of characters written into the buffer.\n\n[ 1513.267938] ------------[ cut here ]------------\n[ 1513.267943] WARNING: CPU: 15 PID: 37247 at <snip>/lib/vsprintf.c:2509 vsnprintf+0x2c8/0x510\n[ 1513.267944] Modules linked in:  <snip>\n[ 1513.267969] CPU: 15 PID: 37247 Comm: mdadm Not tainted 5.4.0-1085-azure #90~18.04.1-Ubuntu\n[ 1513.267969] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022\n[ 1513.267971] RIP: 0010:vsnprintf+0x2c8/0x510\n<-snip->\n[ 1513.267982] Call Trace:\n[ 1513.267986]  snprintf+0x45/0x70\n[ 1513.267990]  ? disk_name+0x71/0xa0\n[ 1513.267993]  dump_zones+0x114/0x240 [raid0]\n[ 1513.267996]  ? _cond_resched+0x19/0x40\n[ 1513.267998]  raid0_run+0x19e/0x270 [raid0]\n[ 1513.268000]  md_run+0x5e0/0xc50\n[ 1513.268003]  ? security_capable+0x3f/0x60\n[ 1513.268005]  do_md_run+0x19/0x110\n[ 1513.268006]  md_ioctl+0x195e/0x1f90\n[ 1513.268007]  blkdev_ioctl+0x91f/0x9f0\n[ 1513.268010]  block_ioctl+0x3d/0x50\n[ 1513.268012]  do_vfs_ioctl+0xa9/0x640\n[ 1513.268014]  ? __fput+0x162/0x260\n[ 1513.268016]  ksys_ioctl+0x75/0x80\n[ 1513.268017]  __x64_sys_ioctl+0x1a/0x20\n[ 1513.268019]  do_syscall_64+0x5e/0x200\n[ 1513.268021]  entry_SYSCALL_64_after_hwframe+0x44/0xa9(CVE-2022-50299)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnbd: Fix hung when signal interrupts nbd_start_device_ioctl()\n\nsyzbot reported hung task [1].  The following program is a simplified\nversion of the reproducer:\n\nint main(void)\n{\n\tint sv[2], fd;\n\n\tif (socketpair(AF_UNIX, SOCK_STREAM, 0, sv) < 0)\n\t\treturn 1;\n\tif ((fd = open("/dev/nbd0", 0)) < 0)\n\t\treturn 1;\n\tif (ioctl(fd, NBD_SET_SIZE_BLOCKS, 0x81) < 0)\n\t\treturn 1;\n\tif (ioctl(fd, NBD_SET_SOCK, sv[0]) < 0)\n\t\treturn 1;\n\tif (ioctl(fd, NBD_DO_IT) < 0)\n\t\treturn 1;\n\treturn 0;\n}\n\nWhen signal interrupt nbd_start_device_ioctl() waiting the condition\natomic_read(&config->recv_threads) == 0, the task can hung because it\nwaits the completion of the inflight IOs.\n\nThis patch fixes the issue by clearing queue, not just shutdown, when\nsignal interrupt nbd_start_device_ioctl().(CVE-2022-50314)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: fix oops during encryption\n\nWhen running xfstests against Azure the following oops occurred on an\narm64 system\n\n  Unable to handle kernel write to read-only memory at virtual address\n  ffff0001221cf000\n  Mem abort info:\n    ESR = 0x9600004f\n    EC = 0x25: DABT (current EL), IL = 32 bits\n    SET = 0, FnV = 0\n    EA = 0, S1PTW = 0\n    FSC = 0x0f: level 3 permission fault\n  Data abort info:\n    ISV = 0, ISS = 0x0000004f\n    CM = 0, WnR = 1\n  swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000294f3000\n  [ffff0001221cf000] pgd=18000001ffff8003, p4d=18000001ffff8003,\n  pud=18000001ff82e003, pmd=18000001ff71d003, pte=00600001221cf787\n  Internal error: Oops: 9600004f [#1] PREEMPT SMP\n  ...\n  pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--)\n  pc : __memcpy+0x40/0x230\n  lr : scatterwalk_copychunks+0xe0/0x200\n  sp : ffff800014e92de0\n  x29: ffff800014e92de0 x28: ffff000114f9de80 x27: 0000000000000008\n  x26: 0000000000000008 x25: ffff800014e92e78 x24: 0000000000000008\n  x23: 0000000000000001 x22: 0000040000000000 x21: ffff000000000000\n  x20: 0000000000000001 x19: ffff0001037c4488 x18: 0000000000000014\n  x17: 235e1c0d6efa9661 x16: a435f9576b6edd6c x15: 0000000000000058\n  x14: 0000000000000001 x13: 0000000000000008 x12: ffff000114f2e590\n  x11: ffffffffffffffff x10: 0000040000000000 x9 : ffff8000105c3580\n  x8 : 2e9413b10000001a x7 : 534b4410fb86b005 x6 : 534b4410fb86b005\n  x5 : ffff0001221cf008 x4 : ffff0001037c4490 x3 : 0000000000000001\n  x2 : 0000000000000008 x1 : ffff0001037c4488 x0 : ffff0001221cf000\n  Call trace:\n   __memcpy+0x40/0x230\n   scatterwalk_map_and_copy+0x98/0x100\n   crypto_ccm_encrypt+0x150/0x180\n   crypto_aead_encrypt+0x2c/0x40\n   crypt_message+0x750/0x880\n   smb3_init_transform_rq+0x298/0x340\n   smb_send_rqst.part.11+0xd8/0x180\n   smb_send_rqst+0x3c/0x100\n   compound_send_recv+0x534/0xbc0\n   smb2_query_info_compound+0x32c/0x440\n   smb2_set_ea+0x438/0x4c0\n   cifs_xattr_set+0x5d4/0x7c0\n\nThis is because in scatterwalk_copychunks(), we attempted to write to\na buffer (@sign) that was allocated in the stack (vmalloc area) by\ncrypt_message() and thus accessing its remaining 8 (x2) bytes ended up\ncrossing a page boundary.\n\nTo simply fix it, we could just pass @sign kmalloc'd from\ncrypt_message() and then we're done.  Luckily, we don't seem to pass\nany other vmalloc'd buffers in smb_rqst::rq_iov...\n\nInstead, let's map the correct pages and offsets from vmalloc buffers\nas well in cifs_sg_set_buf() and then avoiding such oopses.(CVE-2022-50341)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrivers/md/md-bitmap: check the return value of md_bitmap_get_counter()\n\nCheck the return value of md_bitmap_get_counter() in case it returns\nNULL pointer, which will result in a null pointer dereference.\n\nv2: update the check to include other dereference(CVE-2022-50402)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: ac97: fix possible memory leak in snd_ac97_dev_register()\n\nIf device_register() fails in snd_ac97_dev_register(), it should\ncall put_device() to give up reference, or the name allocated in\ndev_set_name() is leaked.(CVE-2022-50427)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmmc: vub300: fix warning - do not call blocking ops when !TASK_RUNNING\n\nvub300_enable_sdio_irq() works with mutex and need TASK_RUNNING here.\nEnsure that we mark current as TASK_RUNNING for sleepable context.\n\n[   77.554641] do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffff92a72c1d>] sdio_irq_thread+0x17d/0x5b0\n[   77.554652] WARNING: CPU: 2 PID: 1983 at kernel/sched/core.c:9813 __might_sleep+0x116/0x160\n[   77.554905] CPU: 2 PID: 1983 Comm: ksdioirqd/mmc1 Tainted: G           OE      6.1.0-rc5 #1\n[   77.554910] Hardware name: Intel(R) Client Systems NUC8i7BEH/NUC8BEB, BIOS BECFL357.86A.0081.2020.0504.1834 05/04/2020\n[   77.554912] RIP: 0010:__might_sleep+0x116/0x160\n[   77.554920] RSP: 0018:ffff888107b7fdb8 EFLAGS: 00010282\n[   77.554923] RAX: 0000000000000000 RBX: ffff888118c1b740 RCX: 0000000000000000\n[   77.554926] RDX: 0000000000000001 RSI: 0000000000000004 RDI: ffffed1020f6ffa9\n[   77.554928] RBP: ffff888107b7fde0 R08: 0000000000000001 R09: ffffed1043ea60ba\n[   77.554930] R10: ffff88821f5305cb R11: ffffed1043ea60b9 R12: ffffffff93aa3a60\n[   77.554932] R13: 000000000000011b R14: 7fffffffffffffff R15: ffffffffc0558660\n[   77.554934] FS:  0000000000000000(0000) GS:ffff88821f500000(0000) knlGS:0000000000000000\n[   77.554937] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[   77.554939] CR2: 00007f8a44010d68 CR3: 000000024421a003 CR4: 00000000003706e0\n[   77.554942] Call Trace:\n[   77.554944]  <TASK>\n[   77.554952]  mutex_lock+0x78/0xf0\n[   77.554973]  vub300_enable_sdio_irq+0x103/0x3c0 [vub300]\n[   77.554981]  sdio_irq_thread+0x25c/0x5b0\n[   77.555006]  kthread+0x2b8/0x370\n[   77.555017]  ret_from_fork+0x1f/0x30\n[   77.555023]  </TASK>\n[   77.555025] ---[ end trace 0000000000000000 ]---(CVE-2022-50430)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclk: samsung: Fix memory leak in _samsung_clk_register_pll()\n\nIf clk_register() fails, @pll->rate_table may have allocated memory by\nkmemdup(), so it needs to be freed, otherwise will cause memory leak\nissue, this patch fixes it.(CVE-2022-50449)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbinfmt_misc: fix shift-out-of-bounds in check_special_flags\n\nUBSAN reported a shift-out-of-bounds warning:\n\n left shift of 1 by 31 places cannot be represented in type 'int'\n Call Trace:\n  <TASK>\n  __dump_stack lib/dump_stack.c:88 [inline]\n  dump_stack_lvl+0x8d/0xcf lib/dump_stack.c:106\n  ubsan_epilogue+0xa/0x44 lib/ubsan.c:151\n  __ubsan_handle_shift_out_of_bounds+0x1e7/0x208 lib/ubsan.c:322\n  check_special_flags fs/binfmt_misc.c:241 [inline]\n  create_entry fs/binfmt_misc.c:456 [inline]\n  bm_register_write+0x9d3/0xa20 fs/binfmt_misc.c:654\n  vfs_write+0x11e/0x580 fs/read_write.c:582\n  ksys_write+0xcf/0x120 fs/read_write.c:637\n  do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n  do_syscall_64+0x34/0x80 arch/x86/entry/common.c:80\n  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n RIP: 0033:0x4194e1\n\nSince the type of Node's flags is unsigned long, we should define these\nmacros with same type too.(CVE-2022-50497)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid10: prevent soft lockup while flush writes\n\nCurrently, there is no limit for raid1/raid10 plugged bio. While flushing\nwrites, raid1 has cond_resched() while raid10 doesn't, and too many\nwrites can cause soft lockup.\n\nFollow up soft lockup can be triggered easily with writeback test for\nraid10 with ramdisks:\n\nwatchdog: BUG: soft lockup - CPU#10 stuck for 27s! [md0_raid10:1293]\nCall Trace:\n <TASK>\n call_rcu+0x16/0x20\n put_object+0x41/0x80\n __delete_object+0x50/0x90\n delete_object_full+0x2b/0x40\n kmemleak_free+0x46/0xa0\n slab_free_freelist_hook.constprop.0+0xed/0x1a0\n kmem_cache_free+0xfd/0x300\n mempool_free_slab+0x1f/0x30\n mempool_free+0x3a/0x100\n bio_free+0x59/0x80\n bio_put+0xcf/0x2c0\n free_r10bio+0xbf/0xf0\n raid_end_bio_io+0x78/0xb0\n one_write_done+0x8a/0xa0\n raid10_end_write_request+0x1b4/0x430\n bio_endio+0x175/0x320\n brd_submit_bio+0x3b9/0x9b7 [brd]\n __submit_bio+0x69/0xe0\n submit_bio_noacct_nocheck+0x1e6/0x5a0\n submit_bio_noacct+0x38c/0x7e0\n flush_pending_writes+0xf0/0x240\n raid10d+0xac/0x1ed0\n\nFix the problem by adding cond_resched() to raid10 like what raid1 did.\n\nNote that unlimited plugged bio still need to be optimized, for example,\nin the case of lots of dirty pages writeback, this will take lots of\nmemory and io will spend a long time in plug, hence io latency is bad.(CVE-2023-53151)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid10: fix leak of 'r10bio->remaining' for recovery\n\nraid10_sync_request() will add 'r10bio->remaining' for both rdev and\nreplacement rdev. However, if the read io fails, recovery_request_write()\nreturns without issuing the write io, in this case, end_sync_request()\nis only called once and 'remaining' is leaked, cause an io hang.\n\nFix the problem by decreasing 'remaining' according to if 'bio' and\n'repl_bio' is valid.(CVE-2023-53299)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid10: fix wrong setting of max_corr_read_errors\n\nThere is no input check when echo md/max_read_errors and overflow might\noccur. Add check of input number.(CVE-2023-53313)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Wait for io return on terminate rport\n\nSystem crash due to use after free.\nCurrent code allows terminate_rport_io to exit before making\nsure all IOs has returned. For FCP-2 device, IO's can hang\non in HW because driver has not tear down the session in FW at\nfirst sign of cable pull. When dev_loss_tmo timer pops,\nterminate_rport_io is called and upper layer is about to\nfree various resources. Terminate_rport_io trigger qla to do\nthe final cleanup, but the cleanup might not be fast enough where it\nleave qla still holding on to the same resource.\n\nWait for IO's to return to upper layer before resources are freed.(CVE-2023-53322)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid10: check slab-out-of-bounds in md_bitmap_get_counter\n\nIf we write a large number to md/bitmap_set_bits, md_bitmap_checkpage()\nwill return -EINVAL because 'page >= bitmap->pages', but the return value\nwas not checked immediately in md_bitmap_get_counter() in order to set\n*blocks value and slab-out-of-bounds occurs.\n\nMove check of 'page >= bitmap->pages' to md_bitmap_get_counter() and\nreturn directly if true.(CVE-2023-53357)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid10: fix null-ptr-deref of mreplace in raid10_sync_request\n\nThere are two check of 'mreplace' in raid10_sync_request(). In the first\ncheck, 'need_replace' will be set and 'mreplace' will be used later if\nno-Faulty 'mreplace' exists, In the second check, 'mreplace' will be\nset to NULL if it is Faulty, but 'need_replace' will not be changed\naccordingly. null-ptr-deref occurs if Faulty is set between two check.\n\nFix it by merging two checks into one. And replace 'need_replace' with\n'mreplace' because their values are always the same.(CVE-2023-53380)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ses: Handle enclosure with just a primary component gracefully\n\nThis reverts commit 3fe97ff3d949 ("scsi: ses: Don't attach if enclosure\nhas no components") and introduces proper handling of case where there are\nno detected secondary components, but primary component (enumerated in\nnum_enclosures) does exist. That fix was originally proposed by Ding Hui\n<(CVE-2023-53431)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla4xxx: Add length check when parsing nlattrs\n\nThere are three places that qla4xxx parses nlattrs:\n\n - qla4xxx_set_chap_entry()\n\n - qla4xxx_iface_set_param()\n\n - qla4xxx_sysfs_ddb_set_param()\n\nand each of them directly converts the nlattr to specific pointer of\nstructure without length checking. This could be dangerous as those\nattributes are not validated and a malformed nlattr (e.g., length 0) could\nresult in an OOB read that leaks heap dirty data.\n\nAdd the nla_len check before accessing the nlattr data and return EINVAL if\nthe length check fails.(CVE-2023-53456)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudf: Do not bother merging very long extents\n\nWhen merging very long extents we try to push as much length as possible\nto the first extent. However this is unnecessarily complicated and not\nreally worth the trouble. Furthermore there was a bug in the logic\nresulting in corrupting extents in the file as syzbot reproducer shows.\nSo just don't bother with the merging of extents that are too long\ntogether.(CVE-2023-53506)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing/histograms: Add histograms to hist_vars if they have referenced variables\n\nHist triggers can have referenced variables without having direct\nvariables fields. This can be the case if referenced variables are added\nfor trigger actions. In this case the newly added references will not\nhave field variables. Not taking such referenced variables into\nconsideration can result in a bug where it would be possible to remove\nhist trigger with variables being refenced. This will result in a bug\nthat is easily reproducable like so\n\n$ cd /sys/kernel/tracing\n$ echo 'synthetic_sys_enter char[] comm; long id' >> synthetic_events\n$ echo 'hist:keys=common_pid.execname,id.syscall:vals=hitcount:comm=common_pid.execname' >> events/raw_syscalls/sys_enter/trigger\n$ echo 'hist:keys=common_pid.execname,id.syscall:onmatch(raw_syscalls.sys_enter).synthetic_sys_enter($comm, id)' >> events/raw_syscalls/sys_enter/trigger\n$ echo '!hist:keys=common_pid.execname,id.syscall:vals=hitcount:comm=common_pid.execname' >> events/raw_syscalls/sys_enter/trigger\n\n[  100.263533] ==================================================================\n[  100.264634] BUG: KASAN: slab-use-after-free in resolve_var_refs+0xc7/0x180\n[  100.265520] Read of size 8 at addr ffff88810375d0f0 by task bash/439\n[  100.266320]\n[  100.266533] CPU: 2 PID: 439 Comm: bash Not tainted 6.5.0-rc1 #4\n[  100.267277] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-20220807_005459-localhost 04/01/2014\n[  100.268561] Call Trace:\n[  100.268902]  <TASK>\n[  100.269189]  dump_stack_lvl+0x4c/0x70\n[  100.269680]  print_report+0xc5/0x600\n[  100.270165]  ? resolve_var_refs+0xc7/0x180\n[  100.270697]  ? kasan_complete_mode_report_info+0x80/0x1f0\n[  100.271389]  ? resolve_var_refs+0xc7/0x180\n[  100.271913]  kasan_report+0xbd/0x100\n[  100.272380]  ? resolve_var_refs+0xc7/0x180\n[  100.272920]  __asan_load8+0x71/0xa0\n[  100.273377]  resolve_var_refs+0xc7/0x180\n[  100.273888]  event_hist_trigger+0x749/0x860\n[  100.274505]  ? kasan_save_stack+0x2a/0x50\n[  100.275024]  ? kasan_set_track+0x29/0x40\n[  100.275536]  ? __pfx_event_hist_trigger+0x10/0x10\n[  100.276138]  ? ksys_write+0xd1/0x170\n[  100.276607]  ? do_syscall_64+0x3c/0x90\n[  100.277099]  ? entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n[  100.277771]  ? destroy_hist_data+0x446/0x470\n[  100.278324]  ? event_hist_trigger_parse+0xa6c/0x3860\n[  100.278962]  ? __pfx_event_hist_trigger_parse+0x10/0x10\n[  100.279627]  ? __kasan_check_write+0x18/0x20\n[  100.280177]  ? mutex_unlock+0x85/0xd0\n[  100.280660]  ? __pfx_mutex_unlock+0x10/0x10\n[  100.281200]  ? kfree+0x7b/0x120\n[  100.281619]  ? ____kasan_slab_free+0x15d/0x1d0\n[  100.282197]  ? event_trigger_write+0xac/0x100\n[  100.282764]  ? __kasan_slab_free+0x16/0x20\n[  100.283293]  ? __kmem_cache_free+0x153/0x2f0\n[  100.283844]  ? sched_mm_cid_remote_clear+0xb1/0x250\n[  100.284550]  ? __pfx_sched_mm_cid_remote_clear+0x10/0x10\n[  100.285221]  ? event_trigger_write+0xbc/0x100\n[  100.285781]  ? __kasan_check_read+0x15/0x20\n[  100.286321]  ? __bitmap_weight+0x66/0xa0\n[  100.286833]  ? _find_next_bit+0x46/0xe0\n[  100.287334]  ? task_mm_cid_work+0x37f/0x450\n[  100.287872]  event_triggers_call+0x84/0x150\n[  100.288408]  trace_event_buffer_commit+0x339/0x430\n[  100.289073]  ? ring_buffer_event_data+0x3f/0x60\n[  100.292189]  trace_event_raw_event_sys_enter+0x8b/0xe0\n[  100.295434]  syscall_trace_enter.constprop.0+0x18f/0x1b0\n[  100.298653]  syscall_enter_from_user_mode+0x32/0x40\n[  100.301808]  do_syscall_64+0x1a/0x90\n[  100.304748]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n[  100.307775] RIP: 0033:0x7f686c75c1cb\n[  100.310617] Code: 73 01 c3 48 8b 0d 65 3c 10 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 21 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 35 3c 10 00 f7 d8 64 89 01 48\n[  100.317847] RSP: 002b:00007ffc60137a38 EFLAGS: 00000246 ORIG_RAX: 0000000000000021\n[  100.321200] RA\n---truncated---(CVE-2023-53560)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btrtl: Prevent potential NULL dereference\n\nThe btrtl_initialize() function checks that rtl_load_file() either\nhad an error or it loaded a zero length file.  However, if it loaded\na zero length file then the error code is not set correctly.  It\nresults in an error pointer vs NULL bug, followed by a NULL pointer\ndereference.  This was detected by Smatch:\n\ndrivers/bluetooth/btrtl.c:592 btrtl_initialize() warn: passing zero to 'ERR_PTR'(CVE-2025-37792)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/gem: Acquire references on GEM handles for framebuffers\n\nA GEM handle can be released while the GEM buffer object is attached\nto a DRM framebuffer. This leads to the release of the dma-buf backing\nthe buffer object, if any. [1] Trying to use the framebuffer in further\nmode-setting operations leads to a segmentation fault. Most easily\nhappens with driver that use shadow planes for vmap-ing the dma-buf\nduring a page flip. An example is shown below.\n\n[  156.791968] ------------[ cut here ]------------\n[  156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430\n[...]\n[  156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430\n[  157.043420] Call Trace:\n[  157.045898]  <TASK>\n[  157.048030]  ? show_trace_log_lvl+0x1af/0x2c0\n[  157.052436]  ? show_trace_log_lvl+0x1af/0x2c0\n[  157.056836]  ? show_trace_log_lvl+0x1af/0x2c0\n[  157.061253]  ? drm_gem_shmem_vmap+0x74/0x710\n[  157.065567]  ? dma_buf_vmap+0x224/0x430\n[  157.069446]  ? __warn.cold+0x58/0xe4\n[  157.073061]  ? dma_buf_vmap+0x224/0x430\n[  157.077111]  ? report_bug+0x1dd/0x390\n[  157.080842]  ? handle_bug+0x5e/0xa0\n[  157.084389]  ? exc_invalid_op+0x14/0x50\n[  157.088291]  ? asm_exc_invalid_op+0x16/0x20\n[  157.092548]  ? dma_buf_vmap+0x224/0x430\n[  157.096663]  ? dma_resv_get_singleton+0x6d/0x230\n[  157.101341]  ? __pfx_dma_buf_vmap+0x10/0x10\n[  157.105588]  ? __pfx_dma_resv_get_singleton+0x10/0x10\n[  157.110697]  drm_gem_shmem_vmap+0x74/0x710\n[  157.114866]  drm_gem_vmap+0xa9/0x1b0\n[  157.118763]  drm_gem_vmap_unlocked+0x46/0xa0\n[  157.123086]  drm_gem_fb_vmap+0xab/0x300\n[  157.126979]  drm_atomic_helper_prepare_planes.part.0+0x487/0xb10\n[  157.133032]  ? lockdep_init_map_type+0x19d/0x880\n[  157.137701]  drm_atomic_helper_commit+0x13d/0x2e0\n[  157.142671]  ? drm_atomic_nonblocking_commit+0xa0/0x180\n[  157.147988]  drm_mode_atomic_ioctl+0x766/0xe40\n[...]\n[  157.346424] ---[ end trace 0000000000000000 ]---\n\nAcquiring GEM handles for the framebuffer's GEM buffer objects prevents\nthis from happening. The framebuffer's cleanup later puts the handle\nreferences.\n\nCommit 1a148af06000 ("drm/gem-shmem: Use dma_buf from GEM object\ninstance") triggers the segmentation fault easily by using the dma-buf\nfield more widely. The underlying issue with reference counting has\nbeen present before.\n\nv2:\n- acquire the handle instead of the BO (Christian)\n- fix comment style (Christian)\n- drop the Fixes tag (Christian)\n- rename err_ gotos\n- add missing Link tag(CVE-2025-38449)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Fix a race when updating an existing write\n\nAfter nfs_lock_and_join_requests() tests for whether the request is\nstill attached to the mapping, nothing prevents a call to\nnfs_inode_remove_request() from succeeding until we actually lock the\npage group.\nThe reason is that whoever called nfs_inode_remove_request() doesn't\nnecessarily have a lock on the page group head.\n\nSo in order to avoid races, let's take the page group lock earlier in\nnfs_lock_and_join_requests(), and hold it across the removal of the\nrequest in nfs_inode_remove_request().(CVE-2025-39697)\n\nA heap-based buffer overflow vulnerability was found in the e1000_set_eeprom function of the Linux kernel. The vulnerability is caused by lack of input validation for the requested length of EEPROM changes, which may lead to heap overflow. Attackers can exploit this vulnerability to compromise confidentiality, integrity, and availability of memory.(CVE-2025-39898)\n\nIn the Linux kernel, a buffer overflow vulnerability exists in the target_lu_gp_members_show function in target_core_configfs.c. The vulnerability arises from the usage of snprintf to write into the buffer "buf" without checking the return value length. When the total formatted string length exceeds LU_GROUP_NAME_BUF (256 bytes), it may cause a buffer overflow. Since snprintf() returns the total number of bytes that would have been written, this value may exceed the buffer length (256 bytes) passed to memcpy(), ultimately causing the memcpy function to report a buffer overflow error. Adding an additional check of the return value of snprintf() can avoid this buffer overflow.(CVE-2025-39998)","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-2510.3.0.0348.oe2003sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-4.19.90-2510.3.0.0348.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2510.3.0.0348.oe2003sp4.aarch64.rpm","kernel-4.19.90-2510.3.0.0348.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2510.3.0.0348.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2510.3.0.0348.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2510.3.0.0348.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2510.3.0.0348.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2510.3.0.0348.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2510.3.0.0348.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2510.3.0.0348.oe2003sp4.aarch64.rpm","perf-4.19.90-2510.3.0.0348.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2510.3.0.0348.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2510.3.0.0348.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2510.3.0.0348.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2510.3.0.0348.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2510.3.0.0348.oe2003sp4.aarch64.rpm"],"src":["kernel-4.19.90-2510.3.0.0348.oe2003sp4.src.rpm"],"x86_64":["bpftool-4.19.90-2510.3.0.0348.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2510.3.0.0348.oe2003sp4.x86_64.rpm","kernel-4.19.90-2510.3.0.0348.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2510.3.0.0348.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2510.3.0.0348.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2510.3.0.0348.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2510.3.0.0348.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2510.3.0.0348.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2510.3.0.0348.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2510.3.0.0348.oe2003sp4.x86_64.rpm","perf-4.19.90-2510.3.0.0348.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2510.3.0.0348.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2510.3.0.0348.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2510.3.0.0348.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2510.3.0.0348.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2510.3.0.0348.oe2003sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2533"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50299"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50314"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50341"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50402"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50427"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50430"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50449"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50497"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53151"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53299"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53313"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53322"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53357"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53380"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53431"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53456"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53506"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53560"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37792"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38449"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39697"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39898"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39998"}],"database_specific":{"severity":"High"}}