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

net/mlx5: E-Switch, pair only capable devices

OFFLOADS paring using devcom is possible only on devices that support LAG. Filter based on lag capabilities.

This fixes an issue where mlx5getnextphysdev() was called without holding the interface lock.

This issue was found when commit bc4c2f2e0179 ("net/mlx5: Lag, filter non compatible devices") added an assert that verifies the interface lock is held.

WARNING: CPU: 9 PID: 1706 at drivers/net/ethernet/mellanox/mlx5/core/dev.c:642 mlx5getnextphysdev+0xd2/0x100 [mlx5core] Modules linked in: mlx5vdpa vringh vhostiotlb vdpa mlx5ib mlx5core xtconntrack xtMASQUERADE nfconntracknetlink nfnetlink xtaddrtype iptablenat nfnat brnetfilter rpcrdma rdmaucm ibiser libiscsi scsitransportiscsi rdmacm iwcm ibumad ibipoib ibcm ibuverbs ibcore overlay fuse [last unloaded: mlx5core] CPU: 9 PID: 1706 Comm: devlink Not tainted 5.18.0-rc7+ #11 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5getnextphysdev+0xd2/0x100 [mlx5core] Code: 02 00 75 48 48 8b 85 80 04 00 00 5d c3 31 c0 5d c3 be ff ff ff ff 48 c7 c7 08 41 5b a0 e8 36 87 28 e3 85 c0 0f 85 6f ff ff ff <0f> 0b e9 68 ff ff ff 48 c7 c7 0c 91 cc 84 e8 cb 36 6f e1 e9 4d ff RSP: 0018:ffff88811bf47458 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88811b398000 RCX: 0000000000000001 RDX: 0000000080000000 RSI: ffffffffa05b4108 RDI: ffff88812daaaa78 RBP: ffff88812d050380 R08: 0000000000000001 R09: ffff88811d6b3437 R10: 0000000000000001 R11: 00000000fddd3581 R12: ffff88815238c000 R13: ffff88812d050380 R14: ffff8881018aa7e0 R15: ffff88811d6b3428 FS: 00007fc82e18ae80(0000) GS:ffff88842e080000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f9630d1b421 CR3: 0000000149802004 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> mlx5eswoffloadsdevcomevent+0x99/0x3b0 [mlx5core] mlx5devcomsendevent+0x167/0x1d0 [mlx5core] eswoffloadsenable+0x1153/0x1500 [mlx5core] ? mlx5eswoffloadscontrollervalid+0x170/0x170 [mlx5core] ? waitforcompletioniotimeout+0x20/0x20 ? mlx5rescandriverslocked+0x318/0x810 [mlx5core] mlx5eswitchenablelocked+0x586/0xc50 [mlx5core] ? mlx5eswitchdisablepfvfvports+0x1d0/0x1d0 [mlx5core] ? mlx5eswtrylock+0x1b/0xb0 [mlx5core] ? mlx5eswitchenable+0x270/0x270 [mlx5core] ? debugfscreatefile+0x260/0x3e0 mlx5devlinkeswitchmodeset+0x27e/0x870 [mlx5core] ? mutexlockionested+0x12c0/0x12c0 ? eswoffloadsdisable+0x250/0x250 [mlx5core] ? devlinknlcmdtrapgetdumpit+0x470/0x470 ? rcureadlockschedheld+0x3f/0x70 devlinknlcmdeswitchsetdoit+0x217/0x620

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

usb: dwc3: host: Stop setting the ACPI companion

It is no longer needed. The sysdev pointer is now used when assigning the ACPI companions to the xHCI ports and USB devices.

Assigning the ACPI companion here resulted in the fwnode->secondary pointer to be replaced also for the parent dwc3 device since the primary fwnode (the ACPI companion) was shared. That was unintentional and it created potential side effects like resource leaks.

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

x86/mce: Work around an erratum on fast string copy instructions

A rare kernel panic scenario can happen when the following conditions are met due to an erratum on fast string copy instructions:

1) An uncorrected error. 2) That error must be in first cache line of a page. 3) Kernel must execute pagecopy from the page immediately before that page.

The fast string copy instructions ("REP; MOVS") could consume an uncorrectable memory error in the cache line right after the desired region to copy and raise an MCE.

Bit 0 of MSRIA32MISCENABLE can be cleared to disable fast string copy and will avoid such spurious machine checks. However, that is less preferable due to the permanent performance impact. Considering memory poison is rare, it's desirable to keep fast string copy enabled until an MCE is seen.

Intel has confirmed the following: 1. The CPU erratum of fast string copy only applies to Skylake, Cascade Lake and Cooper Lake generations.

Directly return from the MCE handler: 2. Will result in complete execution of the "REP; MOVS" with no data loss or corruption. 3. Will not result in another MCE firing on the next poisoned cache line due to "REP; MOVS". 4. Will resume execution from a correct point in code. 5. Will result in the same instruction that triggered the MCE firing a second MCE immediately for any other software recoverable data fetch errors. 6. Is not safe without disabling the fast string copy, as the next fast string copy of the same buffer on the same CPU would result in a PANIC MCE.

This should mitigate the erratum completely with the only caveat that the fast string copy is disabled on the affected hyper thread thus performance degradation.

This is still better than the OS crashing on MCEs raised on an irrelevant process due to "REP; MOVS' accesses in a kernel context, e.g., copypage.

Injected errors on 1st cache line of 8 anonymous pages of process 'proc1' and observed MCE consumption from 'proc2' with no panic (directly returned).

Without the fix, the host panicked within a few minutes on a random 'proc2' process due to kernel access from copypage.

[ bp: Fix comment style + touch ups, zap an unlikely(), improve the quirk function's readability. ]

drm/amd/pm: fix a potential gpumetricstable memory leak

btrfs: scrub: handle RST lookup error correctly

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

lib/generic-radix-tree.c: Don't overflow in peek()

When we started spreading new inode numbers throughout most of the 64 bit inode space, that triggered some corner case bugs, in particular some integer overflows related to the radix tree code. Oops.

hwrng: cavium - fix NULL but dereferenced coccicheck error

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

mlxsw: spectrum: Guard against invalid local ports

When processing events generated by the device's firmware, the driver protects itself from events reported for non-existent local ports, but not for the CPU port (local port 0), which exists, but does not have all the fields as any local port.

This can result in a NULL pointer dereference when trying access 'struct mlxswspport' fields which are not initialized for CPU port.

Commit 63b08b1f6834 ("mlxsw: spectrum: Protect driver from buggy firmware") already handled such issue by bailing early when processing a PUDE event reported for the CPU port.

Generalize the approach by moving the check to a common function and making use of it in all relevant places.

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

net: ethernet: bgmac: Fix refcount leak in bcmamdiomiiregister

ofgetchildbyname() returns a node pointer with refcount incremented, we should use ofnodeput() on it when not need anymore. Add missing ofnodeput() to avoid refcount leak.

drm/amd/display: Wrap dcn301calculatewmanddlg for FPU.

bpf: Reject narrower access to pointer ctx fields

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

net: fix NULL pointer dereference in l3mdevl3rcv

When delete l3s ipvlan:

ip link del link eth0 ipvlan1 type ipvlan mode l3s

This may cause a null pointer dereference:

Call trace: iprcvfinish+0x48/0xd0 iprcv+0x5c/0x100 netifreceiveskbonecore+0x64/0xb0 netifreceiveskb+0x20/0x80 processbacklog+0xb4/0x204 napipoll+0xe8/0x294 netrxaction+0xd8/0x22c dosoftirq+0x12c/0x354

This is because l3mdevl3rcv() visit dev->l3mdevops after ipvlanl3sunregister() assign the dev->l3mdevops to NULL. The process like this:

(CPU1) | (CPU2) l3mdevl3rcv() | check dev->privflags: | master = skb->dev; | | | ipvlanl3sunregister() | set dev->privflags | dev->l3mdevops = NULL; | visit master->l3mdevops |

To avoid this by do not set dev->l3mdevops when unregister l3s ipvlan.

blk-mq: fix NULL dereference on q->elevator in blkmqelvswitchnone

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

net: mscc: ocelot: Fix crash when adding interface under a lag

Commit 15faa1f67ab4 ("lan966x: Fix crash when adding interface under a lag") fixed a similar issue in the lan966x driver caused by a NULL pointer dereference. The ocelotsetaggrpgids() function in the ocelot driver has similar logic and is susceptible to the same crash.

This issue specifically affects the ocelotvsc7514.c frontend, which leaves unused ports as NULL pointers. The felixvsc9959.c frontend is unaffected as it uses the DSA framework which registers all ports.

Fix this by checking if the port pointer is valid before accessing it.

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

net: sock: fix hardened usercopy panic in sockrecverrqueue

skbufffclonecache was created without defining a usercopy region, [1] unlike skbuffheadcache which properly whitelists the cb[] field. [2] This causes a usercopy BUG() when CONFIGHARDENEDUSERCOPY is enabled and the kernel attempts to copy skbuff.cb data to userspace via sockrecverrqueue() -> putcmsg().

The crash occurs when: 1. TCP allocates an skb using allocskbfclone() (from skbufffclonecache) [1] 2. The skb is cloned via skbclone() using the pre-allocated fclone [3] 3. The cloned skb is queued to skerrorqueue for timestamp reporting 4. Userspace reads the error queue via recvmsg(MSGERRQUEUE) 5. sockrecverrqueue() calls putcmsg() to copy serr->ee from skb->cb [4] 6. checkheapobject() fails because skbufffclonecache has no usercopy whitelist [5]

When cloned skbs allocated from skbufffclonecache are used in the socket error queue, accessing the sockexterrskb structure in skb->cb via putcmsg() triggers a usercopy hardening violation:

[ 5.379589] usercopy: Kernel memory exposure attempt detected from SLUB object 'skbufffclonecache' (offset 296, size 16)! [ 5.382796] kernel BUG at mm/usercopy.c:102! [ 5.383923] Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI [ 5.384903] CPU: 1 UID: 0 PID: 138 Comm: pocputcmsg Not tainted 6.12.57 #7 [ 5.384903] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 5.384903] RIP: 0010:usercopyabort+0x6c/0x80 [ 5.384903] Code: 1a 86 51 48 c7 c2 40 15 1a 86 41 52 48 c7 c7 c0 15 1a 86 48 0f 45 d6 48 c7 c6 80 15 1a 86 48 89 c1 49 0f 45 f3 e8 84 27 88 ff <0f> 0b 490 [ 5.384903] RSP: 0018:ffffc900006f77a8 EFLAGS: 00010246 [ 5.384903] RAX: 000000000000006f RBX: ffff88800f0ad2a8 RCX: 1ffffffff0f72e74 [ 5.384903] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff87b973a0 [ 5.384903] RBP: 0000000000000010 R08: 0000000000000000 R09: fffffbfff0f72e74 [ 5.384903] R10: 0000000000000003 R11: 79706f6372657375 R12: 0000000000000001 [ 5.384903] R13: ffff88800f0ad2b8 R14: ffffea00003c2b40 R15: ffffea00003c2b00 [ 5.384903] FS: 0000000011bc4380(0000) GS:ffff8880bf100000(0000) knlGS:0000000000000000 [ 5.384903] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 5.384903] CR2: 000056aa3b8e5fe4 CR3: 000000000ea26004 CR4: 0000000000770ef0 [ 5.384903] PKRU: 55555554 [ 5.384903] Call Trace: [ 5.384903] <TASK> [ 5.384903] checkheapobject+0x9a/0xd0 [ 5.384903] checkobjectsize+0x46c/0x690 [ 5.384903] putcmsg+0x129/0x5e0 [ 5.384903] sockrecverrqueue+0x22f/0x380 [ 5.384903] tlsswrecvmsg+0x7ed/0x1960 [ 5.384903] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 5.384903] ? schedule+0x6d/0x270 [ 5.384903] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 5.384903] ? mutexunlock+0x81/0xd0 [ 5.384903] ? pfxmutexunlock+0x10/0x10 [ 5.384903] ? pfxtlsswrecvmsg+0x10/0x10 [ 5.384903] ? rawspinlockirqsave+0x8f/0xf0 [ 5.384903] ? rawreadunlockirqrestore+0x20/0x40 [ 5.384903] ? srsoaliasreturnthunk+0x5/0xfbef5

The crash offset 296 corresponds to skb2->cb within skbufffclones: - sizeof(struct skbuff) = 232 - offsetof(struct skbuff, cb) = 40 - offset of skb2.cb in fclones = 232 + 40 = 272 - crash offset 296 = 272 + 24 (inside sockexterrskb.ee)

This patch uses a local stack variable as a bounce buffer to avoid the hardened usercopy check failure.

[1] https://elixir.bootlin.com/linux/v6.12.62/source/net/ipv4/tcp.c#L885 [2] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5104 [3] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5566 [4] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5491 [5] https://elixir.bootlin.com/linux/v6.12.62/source/mm/slub.c#L5719

dmaengine: idxd: fix device leaks on compat bind and unbind

bpf: Do not let BPF test infra emit invalid GSO types to stack

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

x86/vmscape: Add conditional IBPB mitigation

VMSCAPE is a vulnerability that exploits insufficient branch predictor isolation between a guest and a userspace hypervisor (like QEMU). Existing mitigations already protect kernel/KVM from a malicious guest. Userspace can additionally be protected by flushing the branch predictors after a VMexit.

Since it is the userspace that consumes the poisoned branch predictors, conditionally issue an IBPB after a VMexit and before returning to userspace. Workloads that frequently switch between hypervisor and userspace will incur the most overhead from the new IBPB.

This new IBPB is not integrated with the existing IBPB sites. For instance, a task can use the existing speculation control prctl() to get an IBPB at context switch time. With this implementation, the IBPB is doubled up: one at context switch and another before running userspace.

The intent is to integrate and optimize these cases post-embargo.

[ dhansen: elaborate on suboptimal IBPB solution ]

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

x86/mm/64: define ARCHPAGETABLESYNCMASK and archsynckernelmappings()

Define ARCHPAGETABLESYNCMASK and archsynckernelmappings() to ensure page tables are properly synchronized when calling pdpopulatekernel().

For 5-level paging, synchronization is performed via pgdpopulatekernel(). In 4-level paging, pgdpopulate() is a no-op, so synchronization is instead performed at the P4D level via p4dpopulatekernel().

This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory:

BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:initsinglepage+0x9/0x6d Call Trace: <TASK> initzonedevicepage+0x17/0x5d memmapinitzonedevice+0x154/0x1bb pagemaprange+0x2e0/0x40f memremappages+0x10b/0x2f0 devmmemremappages+0x1e/0x60 devdaxprobe+0xce/0x2ec [devicedax] daxbusprobe+0x6d/0xc9 [... snip ...] </TASK>

It also fixes a crash in vmemmapsetpmd() caused by accessing vmemmap before syncglobalpgds() [1]:

BUG: unable to handle page fault for address: ffffeb3ff1200000 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 0 P4D 0 Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI Tainted: [W]=WARN RIP: 0010:vmemmapsetpmd+0xff/0x230 <TASK> vmemmappopulatehugepages+0x176/0x180 vmemmappopulate+0x34/0x80 populatesectionmemmap+0x41/0x90 sparseaddsection+0x121/0x3e0 addpages+0xba/0x150 addpages+0x1d/0x70 memremappages+0x3dc/0x810 devmmemremappages+0x1c/0x60 xedevmadd+0x8b/0x100 [xe] xetileinitnoalloc+0x6a/0x70 [xe] xedeviceprobe+0x48c/0x740 [xe] [... snip ...]

block: avoid possible overflow for chunksectors check in blkstacklimits()

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

jbd2: prevent softlockup in jbd2logdocheckpoint()

Both jbd2logdocheckpoint() and jbd2journalshrinkcheckpointlist() periodically release jlistlock after processing a batch of buffers to avoid long hold times on the jlistlock. However, since both functions contend for jlistlock, the combined time spent waiting and processing can be significant.

jbd2journalshrinkcheckpointlist() explicitly calls condresched() when needresched() is true to avoid softlockups during prolonged operations. But jbd2logdocheckpoint() only exits its loop when needresched() is true, relying on potentially sleeping functions like flushbatch() or waitonbuffer() to trigger rescheduling. If those functions do not sleep, the kernel may hit a softlockup.

watchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373] CPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10 Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017 Workqueue: writeback wbworkfn (flush-7:2) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : nativequeuedspinlockslowpath+0x358/0x418 lr : jbd2logdocheckpoint+0x31c/0x438 [jbd2] Call trace: nativequeuedspinlockslowpath+0x358/0x418 jbd2logdocheckpoint+0x31c/0x438 [jbd2] jbd2logwaitforspace+0xfc/0x2f8 [jbd2] addtransactioncredits+0x3bc/0x418 [jbd2] startthishandle+0xf8/0x560 [jbd2] jbd2journalstart+0x118/0x228 [jbd2] ext4journalstartsb+0x110/0x188 [ext4] ext4dowritepages+0x3dc/0x740 [ext4] ext4writepages+0xa4/0x190 [ext4] dowritepages+0x94/0x228 writebacksingleinode+0x48/0x318 writebacksbinodes+0x204/0x590 writebackinodeswb+0x54/0xf8 wbwriteback+0x2cc/0x3d8 wbdowriteback+0x2e0/0x2f8 wbworkfn+0x80/0x2a8 processonework+0x178/0x3e8 workerthread+0x234/0x3b8 kthread+0xf0/0x108 retfromfork+0x10/0x20

So explicitly call condresched() in jbd2logdocheckpoint() to avoid softlockup.

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

net: bridge: fix soft lockup in brmulticastqueryexpired()

When set multicastqueryinterval to a large value, the local variable 'time' in brmulticastsendquery() may overflow. If the time is smaller than jiffies, the timer will expire immediately, and then call modtimer() again, which creates a loop and may trigger the following soft lockup issue.

watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rbconsumer:66] CPU: 1 UID: 0 PID: 66 Comm: rbconsumer Not tainted 6.16.0+ #259 PREEMPT(none) Call Trace: <IRQ> netdevallocskb+0x2e/0x3a0 brip6multicastallocquery+0x212/0x1b70 brmulticastsendquery+0x376/0xac0 brmulticastsendquery+0x299/0x510 brmulticastqueryexpired.constprop.0+0x16d/0x1b0 calltimerfn+0x3b/0x2a0 runtimers+0x619/0x950 runtimersoftirq+0x11c/0x220 handlesoftirqs+0x18e/0x560 irqexitrcu+0x158/0x1a0 sysvecapictimerinterrupt+0x76/0x90 </IRQ>

This issue can be reproduced with: ip link add br0 type bridge echo 1 > /sys/class/net/br0/bridge/multicastquerier echo 0xffffffffffffffff > /sys/class/net/br0/bridge/multicastqueryinterval ip link set dev br0 up

The multicaststartupqueryinterval can also cause this issue. Similar to the commit 99b40610956a ("net: bridge: mcast: add and enforce query interval minimum"), add check for the query interval maximum to fix this issue.

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

netfilter: ctnetlink: remove refcounting in expectation dumpers

Same pattern as previous patch: do not keep the expectation object alive via refcount, only store a cookie value and then use that as the skip hint for dump resumption.

AFAICS this has the same issue as the one resolved in the conntrack dumper, when we do if (!refcountincnotzero(&exp->use))

to increment the refcount, there is a chance that exp == last, which causes a double-increment of the refcount and subsequent memory leak.

bpf: Forget ranges when refining tnum after JSET

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

x86/cpu/hygon: Add missing resctrlcpudetect() in bspinit helper

Since

923f3a2b48bd ("x86/resctrl: Query LLC monitoring properties once during boot")

resctrlcpudetect() has been moved from common CPU initialization code to the vendor-specific BSP init helper, while Hygon didn't put that call in their code.

This triggers a division by zero fault during early booting stage on our machines with X86FEATURECQM supported, where getrdtmonresources() tries to calculate monl3config with uninitialized bootcpudata.x86cacheoccscale.

Add the missing resctrlcpudetect() in the Hygon BSP init helper.

[ bp: Massage commit message. ]

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

net: usb: asixdevices: add phymask for ax88772 mdio bus

Without setting phymask for ax88772 mdio bus, current driver may create at most 32 mdio phy devices with phy address range from 0x00 ~ 0x1f. DLink DUB-E100 H/W Ver B1 is such a device. However, only one main phy device will bind to net phy driver. This is creating issue during system suspend/resume since phypollingmode() in phystatemachine() will directly deference member of phydev->drv for non-main phy devices. Then NULL pointer dereference issue will occur. Due to only external phy or internal phy is necessary, add phymask for ax88772 mdio bus to workarnoud the issue.

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

netfilter: ctnetlink: fix refcount leak on table dump

There is a reference count leak in ctnetlinkdumptable(): if (res < 0) { nfconntrackget(&ct->ctgeneral); // HERE cb->args[1] = (unsigned long)ct; ...

While its very unlikely, its possible that ct == last. If this happens, then the refcount of ct was already incremented. This 2nd increment is never undone.

This prevents the conntrack object from being released, which in turn keeps prevents cnet->count from dropping back to 0.

This will then block the netns dismantle (or conntrack rmmod) as nfconntrackcleanupnetlist() will wait forever.

This can be reproduced by running conntrackresize.sh selftest in a loop. It takes ~20 minutes for me on a preemptible kernel on average before I see a runaway kworker spinning in nfconntrackcleanupnetlist.

One fix would to change this to: if (res < 0) { if (ct != last) nfconntrackget(&ct->ctgeneral);

But this reference counting isn't needed in the first place. We can just store a cookie value instead.

A followup patch will do the same for ctnetlinkexpdumptable, it looks to me as if this has the same problem and like ctnetlinkdumptable, we only need a 'skip hint', not the actual object so we can apply the same cookie strategy there as well.

block: fix resource leak in blkregisterqueue() error path

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

net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY

DSA has 2 kinds of drivers:

1. Those who call dsaswitchsuspend() and dsaswitchresume() from their device PM ops: qca8k-8xxx, bcmsf2, microchip ksz 2. Those who don't: all others. The above methods should be optional.

For type 1, dsaswitchsuspend() calls dsausersuspend() -> phylinkstop(), and dsaswitchresume() calls dsauserresume() -> phylinkstart(). These seem good candidates for setting macmanagedpm = true because that is essentially its definition [1], but that does not seem to be the biggest problem for now, and is not what this change focuses on.

Talking strictly about the 2nd category of DSA drivers here (which do not have MAC managed PM, meaning that for their attached PHYs, mdiobusphysuspend() and mdiobusphyresume() should run in full), I have noticed that the following warning from mdiobusphyresume() is triggered:

WARNON(phydev->state != PHYHALTED && phydev->state != PHYREADY && phydev->state != PHYUP);

because the PHY state machine is running.

It's running as a result of a previous dsauseropen() -> ... -> phylinkstart() -> phystart() having been initiated by the user.

The previous mdiobusphysuspend() was supposed to have called phystopmachine(), but it didn't. So this is why the PHY is in state PHYNOLINK by the time mdiobusphyresume() runs.

mdiobusphysuspend() did not call phystopmachine() because for phylink, the phydev->adjustlink function pointer is NULL. This seems a technicality introduced by commit fddd91016d16 ("phylib: fix PAL state machine restart on resume"). That commit was written before phylink existed, and was intended to avoid crashing with consumer drivers which don't use the PHY state machine - phylink always does, when using a PHY. But phylink itself has historically not been developed with suspend/resume in mind, and apparently not tested too much in that scenario, allowing this bug to exist unnoticed for so long. Plus, prior to the WARNON(), it would have likely been invisible.

This issue is not in fact restricted to type 2 DSA drivers (according to the above ad-hoc classification), but can be extrapolated to any MAC driver with phylink and MDIO-bus-managed PHY PM ops. DSA is just where the issue was reported. Assuming macmanagedpm is set correctly, a quick search indicates the following other drivers might be affected:

$ grep -Zlr PHYLINKNETDEV drivers/ | xargs -0 grep -L macmanagedpm drivers/net/ethernet/atheros/ag71xx.c drivers/net/ethernet/microchip/sparx5/sparx5main.c drivers/net/ethernet/microchip/lan966x/lan966xmain.c drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c drivers/net/ethernet/freescale/fsenet/fsenet-main.c drivers/net/ethernet/freescale/dpaa/dpaaeth.c drivers/net/ethernet/freescale/uccgeth.c drivers/net/ethernet/freescale/enetc/enetcpfcommon.c drivers/net/ethernet/marvell/mvpp2/mvpp2main.c drivers/net/ethernet/marvell/mvneta.c drivers/net/ethernet/marvell/prestera/presteramain.c drivers/net/ethernet/mediatek/mtkethsoc.c drivers/net/ethernet/altera/alteratsemain.c drivers/net/ethernet/wangxun/txgbe/txgbephy.c drivers/net/ethernet/meta/fbnic/fbnicphylink.c drivers/net/ethernet/tehuti/tn40phy.c drivers/net/ethernet/mscc/ocelotnet.c

Make the existing conditions dependent on the PHY device having a phydev->phylinkchange() implementation equal to the default phylinkchange() provided by phylib. Otherwise, we implicitly know that the phydev has the phylink-provided phylinkphychange() callback, and when phylink is used, the PHY state machine always needs to be stopped/ started on the suspend/resume path. The code is structured as such that if phydev->phylinkchange() is absent, it is a matter of time until the kernel will crash - no need to further complicate the test.

Thus, for the situation where the PM is not managed b ---truncated---

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

net: Fix null-ptr-deref by socklockinitclassandname() and rmmod.

When I ran the repro [0] and waited a few seconds, I observed two LOCKDEP splats: a warning immediately followed by a null-ptr-deref. [1]

Reproduction Steps:

1) Mount CIFS 2) Add an iptables rule to drop incoming FIN packets for CIFS 3) Unmount CIFS 4) Unload the CIFS module 5) Remove the iptables rule

At step 3), the CIFS module calls sockrelease() for the underlying TCP socket, and it returns quickly. However, the socket remains in FINWAIT1 because incoming FIN packets are dropped.

At this point, the module's refcnt is 0 while the socket is still alive, so the following rmmod command succeeds.

# ss -tan State Recv-Q Send-Q Local Address:Port Peer Address:Port FIN-WAIT-1 0 477 10.0.2.15:51062 10.0.0.137:445

# lsmod | grep cifs cifs 1159168 0

This highlights a discrepancy between the lifetime of the CIFS module and the underlying TCP socket. Even after CIFS calls sockrelease() and it returns, the TCP socket does not die immediately in order to close the connection gracefully.

While this is generally fine, it causes an issue with LOCKDEP because CIFS assigns a different lock class to the TCP socket's sk->sklock using socklockinitclassandname().

Once an incoming packet is processed for the socket or a timer fires, sk->sklock is acquired.

Then, LOCKDEP checks the lock context in checkwaitcontext(), where hlockclass() is called to retrieve the lock class. However, since the module has already been unloaded, hlockclass() logs a warning and returns NULL, triggering the null-ptr-deref.

If LOCKDEP is enabled, we must ensure that a module calling socklockinitclassandname() (CIFS, NFS, etc) cannot be unloaded while such a socket is still alive to prevent this issue.

Let's hold the module reference in socklockinitclassandname() and release it when the socket is freed in skprotfree().

Note that socklockinit() clears sk->skowner for svccreatesocket() that calls socklockinitclassandname() for a listening socket, which clones a socket by skclonelock() without GFPZERO.

[0]: CIFSSERVER="10.0.0.137" CIFSPATH="//${CIFSSERVER}/Users/Administrator/Desktop/CIFSTEST" DEV="enp0s3" CRED="/root/WindowsCredential.txt"

MNT=$(mktemp -d /tmp/XXXXXX) mount -t cifs ${CIFSPATH} ${MNT} -o vers=3.0,credentials=${CRED},cache=none,echointerval=1

iptables -A INPUT -s ${CIFSSERVER} -j DROP

for i in $(seq 10); do umount ${MNT} rmmod cifs sleep 1 done

rm -r ${MNT}

iptables -D INPUT -s ${CIFSSERVER} -j DROP

[1]: DEBUGLOCKSWARNON(1) WARNING: CPU: 10 PID: 0 at kernel/locking/lockdep.c:234 hlockclass (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223) Modules linked in: cifsarc4 nlsucs2utils cifsmd4 [last unloaded: cifs] CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Not tainted 6.14.0 #36 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:hlockclass (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223) ... Call Trace: <IRQ> lockacquire (kernel/locking/lockdep.c:4853 kernel/locking/lockdep.c:5178) lockacquire (kernel/locking/lockdep.c:469 kernel/locking/lockdep.c:5853 kernel/locking/lockdep.c:5816) rawspinlocknested (kernel/locking/spinlock.c:379) tcpv4rcv (./include/linux/skbuff.h:1678 ./include/net/tcp.h:2547 net/ipv4/tcpipv4.c:2350) ...

BUG: kernel NULL pointer dereference, address: 00000000000000c4 PF: supervisor read access in kernel mode PF: errorcode(0x0000) - not-present page PGD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Tainted: G W 6.14.0 #36 Tainted: [W]=WARN Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:lockacquire (kernel/ ---truncated---