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

fuse: clear intrentry in fuseresend and fuseremovependingreq

When fuseresend() moves a request from fpq->processing back to fiq->pending, it sets FRPENDING and clears FRSENT but does not remove the requests intrentry from fiq->interrupts. If the request had FRINTERRUPTED set from a prior signal, intrentry remains dangling on fiq->interrupts. When the requesting task then receives a fatal signal, fuseremovependingreq() sees FRPENDING=1, removes the request from fiq->pending and frees it via the refcount path, also without cleaning intrentry. The stale intrentry causes use-after-free when fusereadinterrupt() iterates fiq->interrupts: - listdelinit(&req->intrentry) -> UAF write on freed slab - req->in.h.unique -> UAF read, data leaked to userspace

Remove intrentry from fiq->interrupts in fuseresend() for interrupted requests before they are placed back on fiq->pending.

Add a WARNON if the intrentry is not empty on request destruction.

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

x86/ftrace: Relocate %rip-relative percpu refs in dynamic trampolines

With CONFIGCALLDEPTHTRACKING enabled on an x86 retbleed-affected platform (eg: Skylake), with retbleed=stuff, registering a dynamic ftrace trampoline crashes on the first call into the traced function:

BUG: unable to handle page fault for address: ffff88817ae18880 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 4b53067 P4D 4b53067 PUD 0 Oops: Oops: 0002 [#1] SMP PTI CPU: 3 UID: 0 PID: 187 Comm: usleep Not tainted 7.0.10 #243 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 Code: 24 78 00 00 00 00 48 89 ea 48 89 54 24 20 48 8b b4 24 b8 00 00 00 48 8b bc 24 b0 00 00 00 48 89 bc 24 80 00 00 00 48 83 ef 05 <65> 48 c1 3d 1f a8 b6 02 05 48 8b 15 f6 00 00 00 4c 89 3c 24 4c 89 Call Trace: <TASK> ? findheldlock ? excpagefault ? lockrelease ? x64sysclocknanosleep ? lockdephardirqsonprepare ? tracehardirqson x64sysclocknanosleep dosyscall64 ? excpagefault ? calldepthreturnthunk entrySYSCALL64afterhwframe ... Kernel panic - not syncing: Fatal exception

This small reproducer allows to easily trigger the crash:

# echo 'p x64sysclocknanosleep' > /sys/kernel/tracing/kprobeevents # echo 1 > /sys/kernel/tracing/events/kprobes/px64sysclocknanosleep0/enable # usleep 1

Monitoring the crash under GDB points to the exact instruction in charge of incrementing the call depth:

sarq $5, %gs:x86calldepth(%rip)

This instruction matches the one inserted by the ftraceregscaller from ftrace64.S. This emitted code was likely working fine until the introduction of

59bec00ace28 ("x86/percpu: Introduce %rip-relative addressing to PERCPUVAR()"):

it has made the call depth accounting addressing relative to $rip, instead of being based on an absolute address.

As this code exact location depends on where the trampoline lives in memory, the corresponding displacement needs to be adjusted at runtime to actually correctly find the per-cpu x86calldepth value, otherwise the targeted address is wrong, leading to the page fault seen above.

Fix the %rip-relative displacement of the copied CALLDEPTHACCOUNT instruction (from ftraceregscaller) by calling textpokeapplyrelocation(), as it is done for example by the x86 BPF JIT compiler through x86calldepthemitaccounting(). This corrects both CALLDEPTHACCOUNT slots, in ftracecaller and ftraceregscaller.

[ bp: Massage. ]

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

wifi: mac80211: consume only present negotiated TTLM maps

ieee80211tidtolinkmapsizeok() validates negotiated TTLM elements against the number of link-map entries indicated by linkmappresence. ieee80211parsenegttlm() must consume the same layout.

The parser advanced its cursor for every TID, including TIDs whose presence bit is clear and therefore have no map bytes in the element. A sparse map can then make a later present TID read past the validated element.

The bad bytes land in negttlm->{up,down}link[tid] but are gated by validlinks before being applied to driver state, so a peer cannot turn the read into a policy change. Under KUnit + KASAN with an exact-sized element allocation the OOB read is reported as a slab-out-of-bounds; whether the same trigger fires under the production RX path depends on surrounding allocator state.

Advance the cursor only when the current TID has a map present.

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

ksmbd: fix null pointer dereference in compareguidkey()

sessionfdcheck() walks the per-inode moplist during durable-handle session teardown and sets op->conn = NULL for every opinfo whose conn matched the closing session's connection. The matching opinfo, however, stays linked in its per-ClientGuid leasetablelist entry's lb->leaselist because destroyleasetable() only runs on full TCP-connection teardown, not on SESSIONLOGOFF.

If the same TCP connection then negotiates a fresh session with the same ClientGuid (ClientGuid is bound to NEGOTIATE, not the session, and is unchanged across LOGOFF + SETUP) and issues a SMB2 CREATE with a lease context on a different inode, findsameleasekey() walks lb->leaselist, reaches the stale opinfo, and calls compareguidkey(), which unconditionally dereferences opinfo->conn->ClientGUID. The conn pointer is NULL and the kernel panics.

Reproducer requires only a successful SMB2 SESSIONSETUP and a share configured with 'durable handles = yes'. KASAN report on mainline 70390501d194:

general protection fault, probably for non-canonical address 0xdffffc0000000069: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000348-0x000000000000034f] Workqueue: ksmbd-io handleksmbdwork RIP: 0010:bcmp+0x5b/0x230 Call Trace: compareguidkey+0x4b/0xd0 findsameleasekey+0x324/0x690 smb2open+0x6aea/0x8e60 handleksmbdwork+0x796/0xee0 ...

Faulting address 0x348 is the offset of ClientGUID within struct ksmbdconn, confirming opinfo->conn was NULL.

Read opinfo->conn once and bail out if it has been cleared by a concurrent sessionfdcheck(). A half-detached opinfo cannot be the owner of an active lease, so returning 0 is the correct match result.

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

iio: adc: ti-ads1298: add bounds check to pgasettings index

ads1298pgasettings has 7 elements but ADS1298MASKCHPGA can yield values 0-7. If it yields a value >= 7, this causes an out-of-bounds array access. Add a bounds check and return -EINVAL if the index is out of range.

Note that the remaining value b111 is reserved so should not be seen in a correctly functioning system.

afunix: Set gcinprogress to true in unixgc().

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

timers/migration: Fix livelock in tmigrhandleremoteup()

tmigrhandleremotecpu() skips timerexpireremote() when cpu == smpprocessorid(), assuming the local softirq path already handled this CPU's timers.

This assumption is wrong because jiffies can advance after the handling of the CPU's global timers in runtimerbase(BASEGLOBAL) and before tmigrhandleremote() evaluates the expiry times.

As a consequence a timer which expires after the CPU local timer wheel advanced and becomes expired in the remote handling is ignored and the callback is never invoked and removed from the timer wheel.

What's worse is that fetchnexttimerinterruptremote() keeps reporting it as expired, and the event is re-queued with expires == now on each iteration. The goto-again loop spins indefinitely.

Fix this by calling timerexpireremote() unconditionally. That's minimal overhead for the common case as runtimerbase() returns immediately if there is nothing to expire in the local wheel.

[ tglx: Amend change log and add a comment ]

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

bpf: Validate nodeid in arenaallocpages()

arenaallocpages() accepts a plain int nodeid and forwards it through the entire allocation chain without any bounds checking.

Validate nodeid before passing it down the allocation chain in arenaallocpages().

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

iio: pressure: mprls0025pa: fix spitransfer struct initialisation

Make sure that the spitransfer struct is zeroed out before use.

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

drm/amd/display: Fix out-of-bounds stream encoder index v3

engid can be negative and that streamencregs[] can be indexed out of bounds.

engid is used directly as an index into streamencregs[], which has only 5 entries. When engid is 5 (ENGINEIDDIGF) or negative, this can access memory past the end of the array.

Add a bounds check using ARRAYSIZE() before using engid as an index. The unsigned cast also rejects negative values.

This avoids out-of-bounds access.

Fixes the below smatch error: dcnresource.c: streamencodercreate() may index streamencregs[engid] out of bounds (size 5).

drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn351/dcn351resource.c 1246 static struct streamencoder dcn35streamencodercreate( 1247 enum engineid engid, 1248 struct dccontext ctx) 1249 {

...

1255 1256 / Mapping of VPG, AFMT, DME register blocks to DIO block instance / 1257 if (engid <= ENGINEIDDIGF) {

ENGINEIDDIGF is 5. should <= be <?

Unrelated but, ugh, why is Smatch saying that "engid" can be negative? endid is type signed long, but there are checks in the caller which prevent it from being negative.

1258 vpginst = engid; 1259 afmtinst = engid; 1260 } else 1261 return NULL; 1262

...

1281 1282 dcn35diostreamencoderconstruct(enc1, ctx, ctx->dcbios, 1283 engid, vpg, afmt, --> 1284 &streamencregs[engid], ^^^^^^^^^^^^^^^^^^^^^^^ This streamencregs[] array has 5 elements so we are one element beyond the end of the array.

...

1287 return &enc1->base; 1288 }

v2: use explicit bounds check as suggested by Roman/Dan; avoid unsigned int cast

v3: The compiler already knows how to compare the two values, so the cast (int) is not needed. (Roman)

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

mm/vmalloc: take vmappurgelock in shrinker

decayvapoolnode() can be invoked concurrently from two paths: purgevmaparealazy() when pools are being purged, and the shrinker via vmapnodeshrinkscan().

However, decayvapoolnode() is not safe to run concurrently, and the shrinker path currently lacks serialization, leading to races and possible leaks.

Protect decayvapoolnode() by taking vmappurgelock in the shrinker path to ensure serialization with purge users.

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

net: ks8851: Reinstate disabling of BHs around IRQ handler

If the driver executes ks8851irq() AND a TX packet has been sent, then the driver enables TX queue via netifwakequeue() which schedules TX softirq to queue packets for this device.

If CONFIGPREEMPTRT=y is set AND a packet has also been received by the MAC, then ks8851rxpkts() calls netdevallocskbipalign() to allocate SKBs for the received packets. If netdevallocskbipalign() is called with BH enabled, then localbhenable() at the end of netdevallocskbipalign() will trigger the pending softirq processing, which may ultimately call the .xmit callback ks8851startxmitpar(). The ks8851startxmitpar() will try to lock struct ks8851netpar .lock spinlock, which is already locked by ks8851irq() from which ks8851startxmitpar() was called. This leads to a deadlock, which is reported by the kernel, including a trace listed below.

If CONFIGPREEMPTRT is not set, then since commit 0913ec336a6c0 ("net: ks8851: Fix deadlock with the SPI chip variant") the deadlock can also be triggered without received packet in the RX FIFO. The pending softirqs will be processed on return from spinunlockbh(&ks->statelock) in ks8851irq(), which triggers the deadlock as well.

Fix the problem by disabling BH around critical sections, including the IRQ handler, thus preventing the nettxaction() softirq from triggering during these critical sections. The nettxaction() softirq is triggered once BH are re-enabled and at the end of the IRQ handler, once all the other IRQ handler actions have been completed.

schedule from schedulertlock+0x1c/0x34 schedulertlock from rtlockslowlocklocked+0x548/0x904 rtlockslowlocklocked from rtspinlock+0x60/0x9c rtspinlock from ks8851startxmitpar+0x74/0x1a8 ks8851startxmitpar from netdevstartxmit+0x20/0x44 netdevstartxmit from devhardstartxmit+0xd0/0x188 devhardstartxmit from schdirectxmit+0xb8/0x25c schdirectxmit from qdiscrun+0x1f8/0x4ec qdiscrun from qdiscrun+0x1c/0x28 qdiscrun from nettxaction+0x1f0/0x268 nettxaction from handlesoftirqs+0x1a4/0x270 handlesoftirqs from localbhenableip+0xcc/0xe0 localbhenableip from allocskb+0xd8/0x128 allocskb from netdevallocskb+0x3c/0x19c netdevallocskb from ks8851irq+0x388/0x4d4 ks8851irq from irqthreadfn+0x24/0x64 irqthreadfn from irqthread+0x178/0x28c irqthread from kthread+0x12c/0x138 kthread from retfromfork+0x14/0x28

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

hwmon: (pt5161l) Fix bugs in pt5161lreadblockdata()

Fix two bugs in pt5161lreadblockdata():

1. Buffer overrun: The local buffer rbuf is declared as u8 rbuf[24], but i2csmbusreadblockdata() can return up to I2CSMBUSBLOCKMAX (32) bytes. The i2c-core copies the data into the caller's buffer before the return value can be checked, so the post-read length validation does not prevent a stack overrun if a device returns more than 24 bytes. Resize the buffer to I2CSMBUSBLOCKMAX.

2. Unexpected positive return on length mismatch: When all three retries are exhausted because the device returns data with an unexpected length, i2csmbusreadblockdata() returns a positive byte count. The function returns this directly, and callers treat any non-negative return as success, processing stale or incomplete buffer contents. Return -EIO when retries are exhausted with a positive return value, preserving the negative error code on I2C failure.

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

bpf: Fix use-after-free in arenavmclose on fork

arenavmopen() only bumps vml->mmapcount but never registers the child VMA in arena->vmalist. The vml->vma always points at the parent VMA, so after parent munmap the pointer dangles. If the child then calls bpfarenafreepages(), zappages() reads the stale vml->vma triggering use-after-free.

Fix this by preventing the arena VMA from being inherited across fork with VMDONTCOPY, and preventing VMA splits via the maysplit callback.

Also reject mremap with a .mremap callback returning -EINVAL. A same-size mremap(MREMAPFIXED) on the full arena VMA reaches copyvma() through the following path:

checkprepvma() - returns 0 early: newlen == oldlen skips VMDONTEXPAND check prepmovevma() - vmstart == oldaddr and vmend == oldaddr + oldlen so maysplit is never called movevma() copyvmaanddata() copyvma() vmareadup() - copies vmprivatedata (vml pointer) vmops->open() - bumps vml->mmapcount vmops->mremap() - returns -EINVAL, rollback unmaps new VMA

The refcount ensures the rollback's arenavmclose does not free the vml shared with the original VMA.

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

net: nexthop: fix percpu use-after-free in removenhgrpentry

When removing a nexthop from a group, removenhgrpentry() publishes the new group via rcuassignpointer() then immediately frees the removed entry's percpu stats with freepercpu(). However, the synchronizenet() grace period in the caller removenexthopfromgroups() runs after the free. RCU readers that entered before the publish still see the old group and can dereference the freed stats via nhgrpentrystatsinc() -> getcpuptr(nhge->stats), causing a use-after-free on percpu memory.

Fix by deferring the freepercpu() until after synchronizenet() in the caller. Removed entries are chained via nhlist onto a local deferred free list. After the grace period completes and all RCU readers have finished, the percpu stats are safely freed.

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

Revert "arm64: zynqmp: Add an OP-TEE node to the device tree"

This reverts commit 06d22ed6b6635b17551f386b50bb5aaff9b75fbe.

OP-TEE logic in U-Boot automatically injects a reserved-memory node along with optee firmware node to kernel device tree. The injection logic is dependent on that there is no manually defined optee node. Having the node in zynqmp.dtsi effectively breaks OP-TEE's insertion of the reserved-memory node, causing memory access violations during runtime.

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

reset: gpio: suppress bind attributes in sysfs

This is a special device that's created dynamically and is supposed to stay in memory forever. We also currently don't have a devlink between it and the actual reset consumer. Suppress sysfs bind attributes so that user-space can't unbind the device because - as of now - it will cause a use-after-free splat from any user that puts the reset control handle.

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

nvmem: zynqmpnvmem: Fix buffer size in DMA and memcpy

Buffer size used in dma allocation and memcpy is wrong. It can lead to undersized DMA buffer access and possible memory corruption. use correct buffer size in dmaalloccoherent and memcpy.

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

ksmbd: validate owner of durable handle on reconnect

Currently, ksmbd does not verify if the user attempting to reconnect to a durable handle is the same user who originally opened the file. This allows any authenticated user to hijack an orphaned durable handle by predicting or brute-forcing the persistent ID.

According to MS-SMB2, the server MUST verify that the SecurityContext of the reconnect request matches the SecurityContext associated with the existing open. Add a durableowner structure to ksmbdfile to store the original opener's UID, GID, and account name. and catpure the owner information when a file handle becomes orphaned. and implementing ksmbdvfscomparedurableowner() to validate the identity of the requester during SMB2CREATE (DHnC).

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

smb: client: fix off-by-8 bounds check in checkwsleas()

The bounds check uses (u8 )ea + nlen + 1 + vlen as the end of the EA name and value, but eadata sits at offset sizeof(struct smb2filefulleainfo) = 8 from ea, not at offset 0. The strncmp() later reads ea->eadata[0..nlen-1] and the value bytes follow at eadata[nlen+1..nlen+vlen], so the actual end is ea->eadata + nlen + 1 + vlen. Isn't pointer math fun?

The earlier check (u8 )ea > end - sizeof(ea) only guarantees the 8-byte header is in bounds, but since the last EA is placed within 8 bytes of the end of the response, the name and value bytes are read past the end of iov.

Fix this mess all up by using ea->eadata as the base for the bounds check.

An "untrusted" server can use this to leak up to 8 bytes of kernel heap into the EA name comparison and influence which WSL xattr the data is interpreted as.

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

x86/fred: Correct speculative safety in fredextint()

arrayindexnospec() is no use if the result gets spilled to the stack, as it makes the believed safe-under-speculation value subject to memory predictions.

For all practical purposes, this means arrayindexnospec() must be used in the expression that accesses the array.

As the code currently stands, it's the wrong side of irqentryenter(), and 'index' is put into %ebp across the function call.

Remove the index variable and reposition arrayindexnospec(), so it's calculated immediately before the array access.

f2fs: fix to avoid mapping wrong physical block for swapfile

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

xfs: fix UAF in xchkbtreecheckblockowner

We cannot dereference bs->cur when trying to determine if bs->cur aliases bs->sc->sa.{bno,rmap}cur after the latter has been freed. Fix this by sampling before type before any freeing could happen. The correct temporal ordering was broken when we removed xfsbtnumt.

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

wifi: rtl8xxxu: fix slab-out-of-bounds in rtl8xxxustaadd

The driver does not set hw->stadatasize, which causes mac80211 to allocate insufficient space for driver private station data in stainfoalloc(). When rtl8xxxustaadd() accesses members of struct rtl8xxxustainfo through sta->drvpriv, this results in a slab-out-of-bounds write.

KASAN report on RISC-V (VisionFive 2) with RTL8192EU adapter:

BUG: KASAN: slab-out-of-bounds in rtl8xxxustaadd+0x31c/0x346 Write of size 8 at addr ffffffd6d3e9ae88 by task kworker/u16:0/12

Set hw->stadatasize to sizeof(struct rtl8xxxustainfo) during probe, similar to how hw->vifdatasize is configured. This ensures mac80211 allocates sufficient space for the driver's per-station private data.

Tested on StarFive VisionFive 2 v1.2A board.

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

smb/server: fix refcount leak in parsedurablehandlecontext()

When the command is a replay operation and -ENOEXEC is returned, the refcount of ksmbdfile must be released.

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

net: octeonepvf: fix freeirq devid mismatch in IRQ rollback

octepvfrequestirqs() requests MSI-X queue IRQs with devid set to ioqvector. If requestirq() fails part-way, the rollback loop calls freeirq() with devid set to 'oct', which does not match the original devid and may leave the irqaction registered.

This can keep IRQ handlers alive while ioqvector is later freed during unwind/teardown, leading to a use-after-free or crash when an interrupt fires.

Fix the error path to free IRQs with the same ioqvector devid used during requestirq().

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

gve: defer interrupt enabling until NAPI registration

Currently, interrupts are automatically enabled immediately upon request. This allows interrupt to fire before the associated NAPI context is fully initialized and cause failures like below:

[ 0.946369] Call Trace: [ 0.946369] <IRQ> [ 0.946369] napipoll+0x2a/0x1e0 [ 0.946369] netrxaction+0x2f9/0x3f0 [ 0.946369] handlesoftirqs+0xd6/0x2c0 [ 0.946369] ? handleedgeirq+0xc1/0x1b0 [ 0.946369] irqexitrcu+0xc3/0xe0 [ 0.946369] commoninterrupt+0x81/0xa0 [ 0.946369] </IRQ> [ 0.946369] <TASK> [ 0.946369] asmcommoninterrupt+0x22/0x40 [ 0.946369] RIP: 0010:pvnativesafehalt+0xb/0x10

Use the IRQFNOAUTOEN flag when requesting interrupts to prevent auto enablement and explicitly enable the interrupt in NAPI initialization path (and disable it during NAPI teardown).

This ensures that interrupt lifecycle is strictly coupled with readiness of NAPI context.

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

wifi: rtlwifi: 8192cu: fix tid out of range in rtl92cutxfilldesc()

TID getting from ieee80211gettid() might be out of range of array size of staentry->tids[], so check TID is less than MAXTIDCOUNT. Othwerwise, UBSAN warn:

UBSAN: array-index-out-of-bounds in drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:514:30 index 10 is out of range for type 'rtltiddata [9]'

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

igc: don't fail igcprobe() on LED setup error

When igcledsetup() fails, igcprobe() fails and triggers kernel panic in freenetdev() since unregisternetdev() is not called. [1] This behavior can be tested using fault-injection framework, especially the failslab feature. [2]

Since LED support is not mandatory, treat LED setup failures as non-fatal and continue probe with a warning message, consequently avoiding the kernel panic.

[1] kernel BUG at net/core/dev.c:12047! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 937 Comm: repro-igc-led-e Not tainted 6.17.0-rc4-enjuk-tnguy-00865-gc4940196ab02 #64 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:freenetdev+0x278/0x2b0 [...] Call Trace: <TASK> igcprobe+0x370/0x910 localpciprobe+0x3a/0x80 pcideviceprobe+0xd1/0x200 [...]

[2] #!/bin/bash -ex

FAILSLABPATH=/sys/kernel/debug/failslab/ DEVICE=0000:00:05.0 STARTADDR=$(grep " igcledsetup" /proc/kallsyms \ | awk '{printf("0x%s", $1)}') ENDADDR=$(printf "0x%x" $((STARTADDR + 0x100)))

echo $STARTADDR > $FAILSLABPATH/require-start echo $ENDADDR > $FAILSLABPATH/require-end echo 1 > $FAILSLABPATH/times echo 100 > $FAILSLABPATH/probability echo N > $FAILSLABPATH/ignore-gfp-wait

echo $DEVICE > /sys/bus/pci/drivers/igc/bind

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

ixgbe: fix incorrect map used in eee linkmode

incorrectly used ixgbelpmap in loops intended to populate the supported and advertised EEE linkmode bitmaps based on ixgbelsmap. This results in incorrect bit setting and potential out-of-bounds access, since ixgbelpmap and ixgbelsmap have different sizes and purposes.

ixgbelpmap[i] -> ixgbelsmap[i]

Use ixgbelsmap for supported and advertised linkmodes, and keep ixgbelpmap usage only for link partner (lpadvertised) mapping.