OESA-2025-2533

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

md: Replace snprintf with scnprintf

Current code produces a warning as shown below when total characters in the constituent block device names plus the slashes exceeds 200. snprintf() returns the number of characters generated from the given input, which could cause the expression “200 – len” to wrap around to a large positive number. Fix this by using scnprintf() instead, which returns the actual number of characters written into the buffer.

[ 1513.267938] ------------[ cut here ]------------ [ 1513.267943] WARNING: CPU: 15 PID: 37247 at <snip>/lib/vsprintf.c:2509 vsnprintf+0x2c8/0x510 [ 1513.267944] Modules linked in: <snip> [ 1513.267969] CPU: 15 PID: 37247 Comm: mdadm Not tainted 5.4.0-1085-azure #90~18.04.1-Ubuntu [ 1513.267969] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022 [ 1513.267971] RIP: 0010:vsnprintf+0x2c8/0x510 <-snip-> [ 1513.267982] Call Trace: [ 1513.267986] snprintf+0x45/0x70 [ 1513.267990] ? diskname+0x71/0xa0 [ 1513.267993] dumpzones+0x114/0x240 [raid0] [ 1513.267996] ? condresched+0x19/0x40 [ 1513.267998] raid0run+0x19e/0x270 [raid0] [ 1513.268000] mdrun+0x5e0/0xc50 [ 1513.268003] ? securitycapable+0x3f/0x60 [ 1513.268005] domdrun+0x19/0x110 [ 1513.268006] mdioctl+0x195e/0x1f90 [ 1513.268007] blkdevioctl+0x91f/0x9f0 [ 1513.268010] blockioctl+0x3d/0x50 [ 1513.268012] dovfsioctl+0xa9/0x640 [ 1513.268014] ? _fput+0x162/0x260 [ 1513.268016] ksysioctl+0x75/0x80 [ 1513.268017] _x64sysioctl+0x1a/0x20 [ 1513.268019] dosyscall64+0x5e/0x200 [ 1513.268021] entrySYSCALL64after_hwframe+0x44/0xa9(CVE-2022-50299)

In the Linux kernel, the following vulnerability has been resolved:

nbd: Fix hung when signal interrupts nbdstartdevice_ioctl()

syzbot reported hung task [1]. The following program is a simplified version of the reproducer:

int main(void) { int sv[2], fd;

if (socketpair(AF_UNIX, SOCK_STREAM, 0, sv) < 0)
    return 1;
if ((fd = open("/dev/nbd0", 0)) < 0)
    return 1;
if (ioctl(fd, NBD_SET_SIZE_BLOCKS, 0x81) < 0)
    return 1;
if (ioctl(fd, NBD_SET_SOCK, sv[0]) < 0)
    return 1;
if (ioctl(fd, NBD_DO_IT) < 0)
    return 1;
return 0;

}

When signal interrupt nbdstartdeviceioctl() waiting the condition atomicread(&config->recv_threads) == 0, the task can hung because it waits the completion of the inflight IOs.

This patch fixes the issue by clearing queue, not just shutdown, when signal interrupt nbdstartdevice_ioctl().(CVE-2022-50314)

In the Linux kernel, the following vulnerability has been resolved:

cifs: fix oops during encryption

When running xfstests against Azure the following oops occurred on an arm64 system

Unable to handle kernel write to read-only memory at virtual address ffff0001221cf000 Mem abort info: ESR = 0x9600004f EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x0f: level 3 permission fault Data abort info: ISV = 0, ISS = 0x0000004f CM = 0, WnR = 1 swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000294f3000 [ffff0001221cf000] pgd=18000001ffff8003, p4d=18000001ffff8003, pud=18000001ff82e003, pmd=18000001ff71d003, pte=00600001221cf787 Internal error: Oops: 9600004f [#1] PREEMPT SMP ... pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) pc : _memcpy+0x40/0x230 lr : scatterwalkcopychunks+0xe0/0x200 sp : ffff800014e92de0 x29: ffff800014e92de0 x28: ffff000114f9de80 x27: 0000000000000008 x26: 0000000000000008 x25: ffff800014e92e78 x24: 0000000000000008 x23: 0000000000000001 x22: 0000040000000000 x21: ffff000000000000 x20: 0000000000000001 x19: ffff0001037c4488 x18: 0000000000000014 x17: 235e1c0d6efa9661 x16: a435f9576b6edd6c x15: 0000000000000058 x14: 0000000000000001 x13: 0000000000000008 x12: ffff000114f2e590 x11: ffffffffffffffff x10: 0000040000000000 x9 : ffff8000105c3580 x8 : 2e9413b10000001a x7 : 534b4410fb86b005 x6 : 534b4410fb86b005 x5 : ffff0001221cf008 x4 : ffff0001037c4490 x3 : 0000000000000001 x2 : 0000000000000008 x1 : ffff0001037c4488 x0 : ffff0001221cf000 Call trace: _memcpy+0x40/0x230 scatterwalkmapandcopy+0x98/0x100 cryptoccmencrypt+0x150/0x180 cryptoaeadencrypt+0x2c/0x40 cryptmessage+0x750/0x880 smb3inittransformrq+0x298/0x340 smbsendrqst.part.11+0xd8/0x180 smbsendrqst+0x3c/0x100 compoundsendrecv+0x534/0xbc0 smb2queryinfocompound+0x32c/0x440 smb2setea+0x438/0x4c0 cifsxattr_set+0x5d4/0x7c0

This is because in scatterwalkcopychunks(), we attempted to write to a buffer (@sign) that was allocated in the stack (vmalloc area) by cryptmessage() and thus accessing its remaining 8 (x2) bytes ended up crossing a page boundary.

To simply fix it, we could just pass @sign kmalloc'd from cryptmessage() and then we're done. Luckily, we don't seem to pass any other vmalloc'd buffers in smbrqst::rq_iov...

Instead, let's map the correct pages and offsets from vmalloc buffers as well in cifssgset_buf() and then avoiding such oopses.(CVE-2022-50341)

In the Linux kernel, the following vulnerability has been resolved:

drivers/md/md-bitmap: check the return value of mdbitmapget_counter()

Check the return value of mdbitmapget_counter() in case it returns NULL pointer, which will result in a null pointer dereference.

v2: update the check to include other dereference(CVE-2022-50402)

In the Linux kernel, the following vulnerability has been resolved:

ALSA: ac97: fix possible memory leak in sndac97dev_register()

If deviceregister() fails in sndac97devregister(), it should call putdevice() to give up reference, or the name allocated in devset_name() is leaked.(CVE-2022-50427)

In the Linux kernel, the following vulnerability has been resolved:

mmc: vub300: fix warning - do not call blocking ops when !TASK_RUNNING

vub300enablesdioirq() works with mutex and need TASKRUNNING here. Ensure that we mark current as TASK_RUNNING for sleepable context.

[ 77.554641] do not call blocking ops when !TASKRUNNING; state=1 set at [<ffffffff92a72c1d>] sdioirqthread+0x17d/0x5b0 [ 77.554652] WARNING: CPU: 2 PID: 1983 at kernel/sched/core.c:9813 mightsleep+0x116/0x160 [ 77.554905] CPU: 2 PID: 1983 Comm: ksdioirqd/mmc1 Tainted: G OE 6.1.0-rc5 #1 [ 77.554910] Hardware name: Intel(R) Client Systems NUC8i7BEH/NUC8BEB, BIOS BECFL357.86A.0081.2020.0504.1834 05/04/2020 [ 77.554912] RIP: 0010:mightsleep+0x116/0x160 [ 77.554920] RSP: 0018:ffff888107b7fdb8 EFLAGS: 00010282 [ 77.554923] RAX: 0000000000000000 RBX: ffff888118c1b740 RCX: 0000000000000000 [ 77.554926] RDX: 0000000000000001 RSI: 0000000000000004 RDI: ffffed1020f6ffa9 [ 77.554928] RBP: ffff888107b7fde0 R08: 0000000000000001 R09: ffffed1043ea60ba [ 77.554930] R10: ffff88821f5305cb R11: ffffed1043ea60b9 R12: ffffffff93aa3a60 [ 77.554932] R13: 000000000000011b R14: 7fffffffffffffff R15: ffffffffc0558660 [ 77.554934] FS: 0000000000000000(0000) GS:ffff88821f500000(0000) knlGS:0000000000000000 [ 77.554937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 77.554939] CR2: 00007f8a44010d68 CR3: 000000024421a003 CR4: 00000000003706e0 [ 77.554942] Call Trace: [ 77.554944] <TASK> [ 77.554952] mutexlock+0x78/0xf0 [ 77.554973] vub300enablesdioirq+0x103/0x3c0 [vub300] [ 77.554981] sdioirqthread+0x25c/0x5b0 [ 77.555006] kthread+0x2b8/0x370 [ 77.555017] retfrom_fork+0x1f/0x30 [ 77.555023] </TASK> [ 77.555025] ---[ end trace 0000000000000000 ]---(CVE-2022-50430)

In the Linux kernel, the following vulnerability has been resolved:

clk: samsung: Fix memory leak in samsungclkregisterpll()

If clkregister() fails, @pll->ratetable may have allocated memory by kmemdup(), so it needs to be freed, otherwise will cause memory leak issue, this patch fixes it.(CVE-2022-50449)

In the Linux kernel, the following vulnerability has been resolved:

binfmtmisc: fix shift-out-of-bounds in checkspecial_flags

UBSAN reported a shift-out-of-bounds warning:

left shift of 1 by 31 places cannot be represented in type 'int' Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x8d/0xcf lib/dumpstack.c:106 ubsanepilogue+0xa/0x44 lib/ubsan.c:151 _ubsanhandleshiftoutofbounds+0x1e7/0x208 lib/ubsan.c:322 checkspecialflags fs/binfmtmisc.c:241 [inline] createentry fs/binfmtmisc.c:456 [inline] bmregisterwrite+0x9d3/0xa20 fs/binfmtmisc.c:654 vfswrite+0x11e/0x580 fs/readwrite.c:582 ksyswrite+0xcf/0x120 fs/readwrite.c:637 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x34/0x80 arch/x86/entry/common.c:80 entrySYSCALL64after_hwframe+0x63/0xcd RIP: 0033:0x4194e1

Since the type of Node's flags is unsigned long, we should define these macros with same type too.(CVE-2022-50497)

In the Linux kernel, the following vulnerability has been resolved:

md/raid10: prevent soft lockup while flush writes

Currently, there is no limit for raid1/raid10 plugged bio. While flushing writes, raid1 has cond_resched() while raid10 doesn't, and too many writes can cause soft lockup.

Follow up soft lockup can be triggered easily with writeback test for raid10 with ramdisks:

watchdog: BUG: soft lockup - CPU#10 stuck for 27s! [md0raid10:1293] Call Trace: <TASK> callrcu+0x16/0x20 putobject+0x41/0x80 _deleteobject+0x50/0x90 deleteobjectfull+0x2b/0x40 kmemleakfree+0x46/0xa0 slabfreefreelisthook.constprop.0+0xed/0x1a0 kmemcachefree+0xfd/0x300 mempoolfreeslab+0x1f/0x30 mempoolfree+0x3a/0x100 biofree+0x59/0x80 bioput+0xcf/0x2c0 freer10bio+0xbf/0xf0 raidendbioio+0x78/0xb0 onewritedone+0x8a/0xa0 raid10endwriterequest+0x1b4/0x430 bioendio+0x175/0x320 brdsubmitbio+0x3b9/0x9b7 [brd] _submitbio+0x69/0xe0 submitbionoacctnocheck+0x1e6/0x5a0 submitbionoacct+0x38c/0x7e0 flushpending_writes+0xf0/0x240 raid10d+0xac/0x1ed0

Fix the problem by adding cond_resched() to raid10 like what raid1 did.

Note that unlimited plugged bio still need to be optimized, for example, in the case of lots of dirty pages writeback, this will take lots of memory and io will spend a long time in plug, hence io latency is bad.(CVE-2023-53151)

In the Linux kernel, the following vulnerability has been resolved:

md/raid10: fix leak of 'r10bio->remaining' for recovery

raid10syncrequest() will add 'r10bio->remaining' for both rdev and replacement rdev. However, if the read io fails, recoveryrequestwrite() returns without issuing the write io, in this case, endsyncrequest() is only called once and 'remaining' is leaked, cause an io hang.

Fix the problem by decreasing 'remaining' according to if 'bio' and 'repl_bio' is valid.(CVE-2023-53299)

In the Linux kernel, the following vulnerability has been resolved:

md/raid10: fix wrong setting of maxcorrread_errors

There is no input check when echo md/maxreaderrors and overflow might occur. Add check of input number.(CVE-2023-53313)

In the Linux kernel, the following vulnerability has been resolved:

scsi: qla2xxx: Wait for io return on terminate rport

System crash due to use after free. Current code allows terminaterportio to exit before making sure all IOs has returned. For FCP-2 device, IO's can hang on in HW because driver has not tear down the session in FW at first sign of cable pull. When devlosstmo timer pops, terminaterportio is called and upper layer is about to free various resources. Terminaterportio trigger qla to do the final cleanup, but the cleanup might not be fast enough where it leave qla still holding on to the same resource.

Wait for IO's to return to upper layer before resources are freed.(CVE-2023-53322)

In the Linux kernel, the following vulnerability has been resolved:

md/raid10: check slab-out-of-bounds in mdbitmapget_counter

If we write a large number to md/bitmapsetbits, mdbitmapcheckpage() will return -EINVAL because 'page >= bitmap->pages', but the return value was not checked immediately in mdbitmapget_counter() in order to set *blocks value and slab-out-of-bounds occurs.

Move check of 'page >= bitmap->pages' to mdbitmapget_counter() and return directly if true.(CVE-2023-53357)

In the Linux kernel, the following vulnerability has been resolved:

md/raid10: fix null-ptr-deref of mreplace in raid10syncrequest

There are two check of 'mreplace' in raid10syncrequest(). In the first check, 'needreplace' will be set and 'mreplace' will be used later if no-Faulty 'mreplace' exists, In the second check, 'mreplace' will be set to NULL if it is Faulty, but 'needreplace' will not be changed accordingly. null-ptr-deref occurs if Faulty is set between two check.

Fix it by merging two checks into one. And replace 'need_replace' with 'mreplace' because their values are always the same.(CVE-2023-53380)

In the Linux kernel, the following vulnerability has been resolved:

scsi: ses: Handle enclosure with just a primary component gracefully

This reverts commit 3fe97ff3d949 ("scsi: ses: Don't attach if enclosure has no components") and introduces proper handling of case where there are no detected secondary components, but primary component (enumerated in num_enclosures) does exist. That fix was originally proposed by Ding Hui <(CVE-2023-53431)

In the Linux kernel, the following vulnerability has been resolved:

scsi: qla4xxx: Add length check when parsing nlattrs

There are three places that qla4xxx parses nlattrs:

• qla4xxxsetchap_entry()

• qla4xxxifaceset_param()

• qla4xxxsysfsddbsetparam()

and each of them directly converts the nlattr to specific pointer of structure without length checking. This could be dangerous as those attributes are not validated and a malformed nlattr (e.g., length 0) could result in an OOB read that leaks heap dirty data.

Add the nla_len check before accessing the nlattr data and return EINVAL if the length check fails.(CVE-2023-53456)

In the Linux kernel, the following vulnerability has been resolved:

udf: Do not bother merging very long extents

When merging very long extents we try to push as much length as possible to the first extent. However this is unnecessarily complicated and not really worth the trouble. Furthermore there was a bug in the logic resulting in corrupting extents in the file as syzbot reproducer shows. So just don't bother with the merging of extents that are too long together.(CVE-2023-53506)

In the Linux kernel, the following vulnerability has been resolved:

tracing/histograms: Add histograms to hist_vars if they have referenced variables

Hist triggers can have referenced variables without having direct variables fields. This can be the case if referenced variables are added for trigger actions. In this case the newly added references will not have field variables. Not taking such referenced variables into consideration can result in a bug where it would be possible to remove hist trigger with variables being refenced. This will result in a bug that is easily reproducable like so

$ cd /sys/kernel/tracing $ echo 'syntheticsysenter char[] comm; long id' >> syntheticevents $ echo 'hist:keys=commonpid.execname,id.syscall:vals=hitcount:comm=commonpid.execname' >> events/rawsyscalls/sysenter/trigger $ echo 'hist:keys=commonpid.execname,id.syscall:onmatch(rawsyscalls.sysenter).syntheticsysenter($comm, id)' >> events/rawsyscalls/sysenter/trigger $ echo '!hist:keys=commonpid.execname,id.syscall:vals=hitcount:comm=commonpid.execname' >> events/rawsyscalls/sysenter/trigger

[ 100.263533] ================================================================== [ 100.264634] BUG: KASAN: slab-use-after-free in resolvevarrefs+0xc7/0x180 [ 100.265520] Read of size 8 at addr ffff88810375d0f0 by task bash/439 [ 100.266320] [ 100.266533] CPU: 2 PID: 439 Comm: bash Not tainted 6.5.0-rc1 #4 [ 100.267277] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-20220807005459-localhost 04/01/2014 [ 100.268561] Call Trace: [ 100.268902] <TASK> [ 100.269189] dumpstacklvl+0x4c/0x70 [ 100.269680] printreport+0xc5/0x600 [ 100.270165] ? resolvevarrefs+0xc7/0x180 [ 100.270697] ? kasancompletemodereportinfo+0x80/0x1f0 [ 100.271389] ? resolvevarrefs+0xc7/0x180 [ 100.271913] kasanreport+0xbd/0x100 [ 100.272380] ? resolvevarrefs+0xc7/0x180 [ 100.272920] asanload8+0x71/0xa0 [ 100.273377] resolvevarrefs+0xc7/0x180 [ 100.273888] eventhisttrigger+0x749/0x860 [ 100.274505] ? kasansavestack+0x2a/0x50 [ 100.275024] ? kasansettrack+0x29/0x40 [ 100.275536] ? _pfxeventhisttrigger+0x10/0x10 [ 100.276138] ? ksyswrite+0xd1/0x170 [ 100.276607] ? dosyscall64+0x3c/0x90 [ 100.277099] ? entrySYSCALL64afterhwframe+0x6e/0xd8 [ 100.277771] ? destroyhistdata+0x446/0x470 [ 100.278324] ? eventhisttriggerparse+0xa6c/0x3860 [ 100.278962] ? _pfxeventhisttriggerparse+0x10/0x10 [ 100.279627] ? _kasancheckwrite+0x18/0x20 [ 100.280177] ? mutexunlock+0x85/0xd0 [ 100.280660] ? _pfxmutexunlock+0x10/0x10 [ 100.281200] ? kfree+0x7b/0x120 [ 100.281619] ? kasanslabfree+0x15d/0x1d0 [ 100.282197] ? eventtriggerwrite+0xac/0x100 [ 100.282764] ? _kasanslabfree+0x16/0x20 [ 100.283293] ? _kmemcachefree+0x153/0x2f0 [ 100.283844] ? schedmmcidremoteclear+0xb1/0x250 [ 100.284550] ? _pfxschedmmcidremoteclear+0x10/0x10 [ 100.285221] ? eventtriggerwrite+0xbc/0x100 [ 100.285781] ? _kasancheckread+0x15/0x20 [ 100.286321] ? _bitmapweight+0x66/0xa0 [ 100.286833] ? _findnextbit+0x46/0xe0 [ 100.287334] ? taskmmcidwork+0x37f/0x450 [ 100.287872] eventtriggerscall+0x84/0x150 [ 100.288408] traceeventbuffercommit+0x339/0x430 [ 100.289073] ? ringbuffereventdata+0x3f/0x60 [ 100.292189] traceeventraweventsysenter+0x8b/0xe0 [ 100.295434] syscalltraceenter.constprop.0+0x18f/0x1b0 [ 100.298653] syscallenterfromusermode+0x32/0x40 [ 100.301808] dosyscall64+0x1a/0x90 [ 100.304748] entrySYSCALL64afterhwframe+0x6e/0xd8 [ 100.307775] RIP: 0033:0x7f686c75c1cb [ 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 [ 100.317847] RSP: 002b:00007ffc60137a38 EFLAGS: 00000246 ORIGRAX: 0000000000000021 [ 100.321200] RA ---truncated---(CVE-2023-53560)

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: btrtl: Prevent potential NULL dereference

The btrtlinitialize() function checks that rtlload_file() either had an error or it loaded a zero length file. However, if it loaded a zero length file then the error code is not set correctly. It results in an error pointer vs NULL bug, followed by a NULL pointer dereference. This was detected by Smatch:

drivers/bluetooth/btrtl.c:592 btrtlinitialize() warn: passing zero to 'ERRPTR'(CVE-2025-37792)

In the Linux kernel, the following vulnerability has been resolved:

drm/gem: Acquire references on GEM handles for framebuffers

A GEM handle can be released while the GEM buffer object is attached to a DRM framebuffer. This leads to the release of the dma-buf backing the buffer object, if any. [1] Trying to use the framebuffer in further mode-setting operations leads to a segmentation fault. Most easily happens with driver that use shadow planes for vmap-ing the dma-buf during a page flip. An example is shown below.

[ 156.791968] ------------[ cut here ]------------ [ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dmabufvmap+0x224/0x430 [...] [ 156.942028] RIP: 0010:dmabufvmap+0x224/0x430 [ 157.043420] Call Trace: [ 157.045898] <TASK> [ 157.048030] ? showtraceloglvl+0x1af/0x2c0 [ 157.052436] ? showtraceloglvl+0x1af/0x2c0 [ 157.056836] ? showtraceloglvl+0x1af/0x2c0 [ 157.061253] ? drmgemshmemvmap+0x74/0x710 [ 157.065567] ? dmabufvmap+0x224/0x430 [ 157.069446] ? _warn.cold+0x58/0xe4 [ 157.073061] ? dmabufvmap+0x224/0x430 [ 157.077111] ? reportbug+0x1dd/0x390 [ 157.080842] ? handlebug+0x5e/0xa0 [ 157.084389] ? excinvalidop+0x14/0x50 [ 157.088291] ? asmexcinvalidop+0x16/0x20 [ 157.092548] ? dmabufvmap+0x224/0x430 [ 157.096663] ? dmaresvgetsingleton+0x6d/0x230 [ 157.101341] ? _pfxdmabufvmap+0x10/0x10 [ 157.105588] ? _pfxdmaresvgetsingleton+0x10/0x10 [ 157.110697] drmgemshmemvmap+0x74/0x710 [ 157.114866] drmgemvmap+0xa9/0x1b0 [ 157.118763] drmgemvmapunlocked+0x46/0xa0 [ 157.123086] drmgemfbvmap+0xab/0x300 [ 157.126979] drmatomichelperprepareplanes.part.0+0x487/0xb10 [ 157.133032] ? lockdepinitmaptype+0x19d/0x880 [ 157.137701] drmatomichelpercommit+0x13d/0x2e0 [ 157.142671] ? drmatomicnonblockingcommit+0xa0/0x180 [ 157.147988] drmmodeatomic_ioctl+0x766/0xe40 [...] [ 157.346424] ---[ end trace 0000000000000000 ]---

Acquiring GEM handles for the framebuffer's GEM buffer objects prevents this from happening. The framebuffer's cleanup later puts the handle references.

Commit 1a148af06000 ("drm/gem-shmem: Use dma_buf from GEM object instance") triggers the segmentation fault easily by using the dma-buf field more widely. The underlying issue with reference counting has been present before.

v2: - acquire the handle instead of the BO (Christian) - fix comment style (Christian) - drop the Fixes tag (Christian) - rename err_ gotos - add missing Link tag(CVE-2025-38449)

In the Linux kernel, the following vulnerability has been resolved:

NFS: Fix a race when updating an existing write

After nfslockandjoinrequests() tests for whether the request is still attached to the mapping, nothing prevents a call to nfsinoderemoverequest() from succeeding until we actually lock the page group. The reason is that whoever called nfsinoderemoverequest() doesn't necessarily have a lock on the page group head.

So in order to avoid races, let's take the page group lock earlier in nfslockandjoinrequests(), and hold it across the removal of the request in nfsinoderemove_request().(CVE-2025-39697)

A heap-based buffer overflow vulnerability was found in the e1000seteeprom 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)

In the Linux kernel, a buffer overflow vulnerability exists in the targetlugpmembersshow function in targetcoreconfigfs.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 LUGROUPNAME_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)