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

media: uvcvideo: Mark invalid entities with id UVCINVALIDENTITYID

Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero unique ID.

Each Unit and Terminal within the video function is assigned a unique identification number, the Unit ID (UID) or Terminal ID (TID), contained in the bUnitID or bTerminalID field of the descriptor. The value 0x00 is reserved for undefined ID,

If we add a new entity with id 0 or a duplicated ID, it will be marked as UVCINVALIDENTITYID.

In a previous attempt commit 3dd075fe8ebb ("media: uvcvideo: Require entities to have a non-zero unique ID"), we ignored all the invalid units, this broke a lot of non-compatible cameras. Hopefully we are more lucky this time.

This also prevents some syzkaller reproducers from triggering warnings due to a chain of entities referring to themselves. In one particular case, an Output Unit is connected to an Input Unit, both with the same ID of 1. But when looking up for the source ID of the Output Unit, that same entity is found instead of the input entity, which leads to such warnings.

In another case, a backward chain was considered finished as the source ID was 0. Later on, that entity was found, but its pads were not valid.

Here is a sample stack trace for one of those cases.

[ 20.650953] usb 1-1: new high-speed USB device number 2 using dummyhcd [ 20.830206] usb 1-1: Using ep0 maxpacket: 8 [ 20.833501] usb 1-1: config 0 descriptor?? [ 21.038518] usb 1-1: string descriptor 0 read error: -71 [ 21.038893] usb 1-1: Found UVC 0.00 device <unnamed> (2833:0201) [ 21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized! [ 21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized! [ 21.042218] ------------[ cut here ]------------ [ 21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 mediacreatepadlink+0x2c4/0x2e0 [ 21.043195] Modules linked in: [ 21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444 [ 21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 21.044639] Workqueue: usbhubwq hubevent [ 21.045100] RIP: 0010:mediacreatepadlink+0x2c4/0x2e0 [ 21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 <0f> 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00 [ 21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246 [ 21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1 [ 21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290 [ 21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000 [ 21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003 [ 21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000 [ 21.049648] FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 [ 21.050271] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0 [ 21.051136] PKRU: 55555554 [ 21.051331] Call Trace: [ 21.051480] <TASK> [ 21.051611] ? warn+0xc4/0x210 [ 21.051861] ? mediacreatepadlink+0x2c4/0x2e0 [ 21.052252] ? reportbug+0x11b/0x1a0 [ 21.052540] ? tracehardirqson+0x31/0x40 [ 21.052901] ? handlebug+0x3d/0x70 [ 21.053197] ? excinvalidop+0x1a/0x50 [ 21.053511] ? asmexcinvalidop+0x1a/0x20 [ 21.053924] ? mediacreatepadlink+0x91/0x2e0 [ 21.054364] ? mediacreatepadlink+0x2c4/0x2e0 [ 21.054834] ? mediacreatepadlink+0x91/0x2e0 [ 21.055131] ? rawspinunlock+0x1e/0x40 [ 21.055441] ? v4l2deviceregistersubdev+0x202/0x210 [ 21.055837] uvcmcregisterentities+0x358/0x400 [ 21.056144] uvcregisterchains+0x1 ---truncated---

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

spi: cadence-quadspi: Implement refcount to handle unbind during busy

driver support indirect read and indirect write operation with assumption no force device removal(unbind) operation. However force device removal(removal) is still available to root superuser.

Unbinding driver during operation causes kernel crash. This changes ensure driver able to handle such operation for indirect read and indirect write by implementing refcount to track attached devices to the controller and gracefully wait and until attached devices remove operation completed before proceed with removal operation.

cgroup: split cgroupdestroywq into 3 workqueues

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

net/mlx5e: Harden uplink netdev access against device unbind

The function mlx5uplinknetdevget() gets the uplink netdevice pointer from mdev->mlx5eres.uplinknetdev. However, the netdevice can be removed and its pointer cleared when unbound from the mlx5core.eth driver. This results in a NULL pointer, causing a kernel panic.

BUG: unable to handle page fault for address: 0000000000001300 at RIP: 0010:mlx5evportrepload+0x22a/0x270 [mlx5core] Call Trace: <TASK> mlx5eswoffloadsrepload+0x68/0xe0 [mlx5core] eswoffloadsenable+0x593/0x910 [mlx5core] mlx5eswitchenablelocked+0x341/0x420 [mlx5core] mlx5devlinkeswitchmodeset+0x17e/0x3a0 [mlx5core] devlinknleswitchsetdoit+0x60/0xd0 genlfamilyrcvmsgdoit+0xe0/0x130 genlrcvmsg+0x183/0x290 netlinkrcvskb+0x4b/0xf0 genlrcv+0x24/0x40 netlinkunicast+0x255/0x380 netlinksendmsg+0x1f3/0x420 socksendmsg+0x38/0x60 syssendto+0x119/0x180 dosyscall64+0x53/0x1d0 entrySYSCALL64afterhwframe+0x4b/0x53

Ensure the pointer is valid before use by checking it for NULL. If it is valid, immediately call netdevhold() to take a reference, and preventing the netdevice from being freed while it is in use.

dm-stripe: fix a possible integer overflow

ASoC: qcom: q6apm-lpass-dais: Fix NULL pointer dereference if source graph failed

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

net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer

Since commit 7d5e9737efda ("net: rfkill: gpio: get the name and type from device property") rfkillfindtype() gets called with the possibly uninitialized "const char typename;" local variable.

On x86 systems when rfkill-gpio binds to a "BCM4752" or "LNV4752" acpidevice, the rfkill->type is set based on the ACPI acpideviceid:

rfkill->type = (unsigned)id->driverdata;

and there is no "type" property so devicepropertyreadstring() will fail and leave typename uninitialized, leading to a potential crash.

rfkillfindtype() does accept a NULL pointer, fix the potential crash by initializing typename to NULL.

Note likely sofar this has not been caught because:

1. Not many x86 machines actually have a "BCM4752"/"LNV4752" acpidevice 2. The stack happened to contain NULL where typename is stored

drm: bridge: anx7625: Fix NULL pointer dereference with early IRQ

dmaengine: qcom: bamdma: Fix DT error handling for num-channels/ees

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

pcmcia: Add error handling for addinterval() in dovalidatemem()

In the dovalidatemem(), the call to addinterval() does not handle errors. If kmalloc() fails in addinterval(), it could result in a null pointer being inserted into the linked list, leading to illegal memory access when subinterval() is called next.

This patch adds an error handling for the addinterval(). If addinterval() returns an error, the function will return early with the error code.

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

mm/damon/reclaim: avoid divide-by-zero in damonreclaimapplyparameters()

When creating a new scheme of DAMONRECLAIM, the calculation of 'minageregion' uses 'aggrinterval' as the divisor, which may lead to division-by-zero errors. Fix it by directly returning -EINVAL when such a case occurs.

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

tracing: Silence warning when chunk allocation fails in tracepidwrite

Syzkaller trigger a fault injection warning:

WARNING: CPU: 1 PID: 12326 at tracepointaddfunc+0xbfc/0xeb0 Modules linked in: CPU: 1 UID: 0 PID: 12326 Comm: syz.6.10325 Tainted: G U 6.14.0-rc5-syzkaller #0 Tainted: [U]=USER Hardware name: Google Compute Engine/Google Compute Engine RIP: 0010:tracepointaddfunc+0xbfc/0xeb0 kernel/tracepoint.c:294 Code: 09 fe ff 90 0f 0b 90 0f b6 74 24 43 31 ff 41 bc ea ff ff ff RSP: 0018:ffffc9000414fb48 EFLAGS: 00010283 RAX: 00000000000012a1 RBX: ffffffff8e240ae0 RCX: ffffc90014b78000 RDX: 0000000000080000 RSI: ffffffff81bbd78b RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffffffffffffffef R13: 0000000000000000 R14: dffffc0000000000 R15: ffffffff81c264f0 FS: 00007f27217f66c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2e80dff8 CR3: 00000000268f8000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> tracepointproberegisterprio+0xc0/0x110 kernel/tracepoint.c:464 registertraceprioschedswitch include/trace/events/sched.h:222 [inline] registerpidevents kernel/trace/traceevents.c:2354 [inline] eventpidwrite.isra.0+0x439/0x7a0 kernel/trace/traceevents.c:2425 vfswrite+0x24c/0x1150 fs/readwrite.c:677 ksyswrite+0x12b/0x250 fs/readwrite.c:731 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x250 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

We can reproduce the warning by following the steps below: 1. echo 8 >> seteventnotracepid. Let tr->filteredpids owns one pid and register schedswitch tracepoint. 2. echo ' ' >> seteventpid, and perform fault injection during chunk allocation of tracepidlistalloc. Let pidlist with no pid and assign to tr->filteredpids. 3. echo ' ' >> seteventpid. Let pidlist is NULL and assign to tr->filteredpids. 4. echo 9 >> seteventpid, will trigger the double register schedswitch tracepoint warning.

The reason is that syzkaller injects a fault into the chunk allocation in tracepidlistalloc, causing a failure in tracepidlistset, which may trigger double register of the same tracepoint. This only occurs when the system is about to crash, but to suppress this warning, let's add failure handling logic to tracepidlistset.

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

mm/damon/lrusort: avoid divide-by-zero in damonlrusortapplyparameters()

Patch series "mm/damon: avoid divide-by-zero in DAMON module's parameters application".

DAMON's RECLAIM and LRUSORT modules perform no validation on user-configured parameters during application, which may lead to division-by-zero errors.

Avoid the divide-by-zero by adding validation checks when DAMON modules attempt to apply the parameters.

This patch (of 2):

During the calculation of 'hotthres' and 'coldthres', either 'sampleinterval' or 'aggrinterval' is used as the divisor, which may lead to division-by-zero errors. Fix it by directly returning -EINVAL when such a case occurs. Additionally, since 'aggrinterval' is already required to be set no smaller than 'sampleinterval' in damonsetattrs(), only the case where 'sampleinterval' is zero needs to be checked.

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

sched: Fix schednumafindnthcpu() if mask offline

schednumafindnthcpu() uses a bsearch to look for the 'closest' CPU in scheddomainsnumamasks and given cpus mask. However they might not intersect if all CPUs in the cpus mask are offline. bsearch will return NULL in that case, bail out instead of dereferencing a bogus pointer.

The previous behaviour lead to this bug when using maxcpus=4 on an rk3399 (LLLLbb) (i.e. booting with all big CPUs offline):

[ 1.422922] Unable to handle kernel paging request at virtual address ffffff8000000000 [ 1.423635] Mem abort info: [ 1.423889] ESR = 0x0000000096000006 [ 1.424227] EC = 0x25: DABT (current EL), IL = 32 bits [ 1.424715] SET = 0, FnV = 0 [ 1.424995] EA = 0, S1PTW = 0 [ 1.425279] FSC = 0x06: level 2 translation fault [ 1.425735] Data abort info: [ 1.425998] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000 [ 1.426499] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 1.426952] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1.427428] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000004a9f000 [ 1.428038] [ffffff8000000000] pgd=18000000f7fff403, p4d=18000000f7fff403, pud=18000000f7fff403, pmd=0000000000000000 [ 1.429014] Internal error: Oops: 0000000096000006 [#1] SMP [ 1.429525] Modules linked in: [ 1.429813] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc4-dirty #343 PREEMPT [ 1.430559] Hardware name: Pine64 RockPro64 v2.1 (DT) [ 1.431012] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.431634] pc : schednumafindnthcpu+0x2a0/0x488 [ 1.432094] lr : schednumafindnthcpu+0x284/0x488 [ 1.432543] sp : ffffffc084e1b960 [ 1.432843] x29: ffffffc084e1b960 x28: ffffff80078a8800 x27: ffffffc0846eb1d0 [ 1.433495] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 [ 1.434144] x23: 0000000000000000 x22: fffffffffff7f093 x21: ffffffc081de6378 [ 1.434792] x20: 0000000000000000 x19: 0000000ffff7f093 x18: 00000000ffffffff [ 1.435441] x17: 3030303866666666 x16: 66663d736b73616d x15: ffffffc104e1b5b7 [ 1.436091] x14: 0000000000000000 x13: ffffffc084712860 x12: 0000000000000372 [ 1.436739] x11: 0000000000000126 x10: ffffffc08476a860 x9 : ffffffc084712860 [ 1.437389] x8 : 00000000ffffefff x7 : ffffffc08476a860 x6 : 0000000000000000 [ 1.438036] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000 [ 1.438683] x2 : 0000000000000000 x1 : ffffffc0846eb000 x0 : ffffff8000407b68 [ 1.439332] Call trace: [ 1.439559] schednumafindnthcpu+0x2a0/0x488 (P) [ 1.440016] smpcallfunctionany+0xc8/0xd0 [ 1.440416] armv8pmuinit+0x58/0x27c [ 1.440770] armv8cortexa72pmuinit+0x20/0x2c [ 1.441199] armpmudeviceprobe+0x1e4/0x5e8 [ 1.441603] armv8pmudeviceprobe+0x1c/0x28 [ 1.442007] platformprobe+0x5c/0xac [ 1.442347] reallyprobe+0xbc/0x298 [ 1.442683] driverprobedevice+0x78/0x12c [ 1.443087] driverprobedevice+0xdc/0x160 [ 1.443475] driverattach+0x94/0x19c [ 1.443833] busforeachdev+0x74/0xd4 [ 1.444190] driverattach+0x24/0x30 [ 1.444525] busadddriver+0xe4/0x208 [ 1.444874] driverregister+0x60/0x128 [ 1.445233] platformdriverregister+0x24/0x30 [ 1.445662] armv8pmudriverinit+0x28/0x4c [ 1.446059] dooneinitcall+0x44/0x25c [ 1.446416] kernelinitfreeable+0x1dc/0x3bc [ 1.446820] kernelinit+0x20/0x1d8 [ 1.447151] retfromfork+0x10/0x20 [ 1.447493] Code: 90022e21 f000e5f5 910de2b5 2a1703e2 (f8767803) [ 1.448040] ---[ end trace 0000000000000000 ]--- [ 1.448483] note: swapper/0[1] exited with preemptcount 1 [ 1.449047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 1.449741] SMP: stopping secondary CPUs [ 1.450105] Kernel Offset: disabled [ 1.450419] CPU features: 0x000000,00080000,20002001,0400421b [ ---truncated---

bpf: Tell memcg to use allowspinning=false path in bpftimerinit()

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

net: fec: Fix possible NPD in fecenetphyresetafterclkenable()

The function ofphyfinddevice may return NULL, so we need to take care before dereferencing phydev.

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

ppp: fix memory leak in padcompressskb

If allocskb() fails in padcompressskb(), it returns NULL without releasing the old skb. The caller does:

skb = padcompressskb(ppp, skb); if (!skb) goto drop;

drop: kfreeskb(skb);

When padcompressskb() returns NULL, the reference to the old skb is lost and kfreeskb(skb) ends up doing nothing, leading to a memory leak.

Align padcompressskb() semantics with realloc(): only free the old skb if allocation and compression succeed. At the call site, use the newskb variable so the original skb is not lost when padcompressskb() fails.

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

pcmcia: Fix a NULL pointer dereference in iodynfindioregion()

In iodynfindioregion(), pcmciamakeresource() is assigned to res and used in pcibusallocresource(). There is a dereference of res in pcibusallocresource(), which could lead to a NULL pointer dereference on failure of pcmciamakeresource().

Fix this bug by adding a check of res.

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 ...]

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

mm: move page table sync declarations to linux/pgtable.h

During our internal testing, we started observing intermittent boot failures when the machine uses 4-level paging and has 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 turns out that the kernel panics while initializing vmemmap (struct page array) when the vmemmap region spans two PGD entries, because the new PGD entry is only installed in initmm.pgd, but not in the page tables of other tasks.

And looking at populatesectionmemmap(): if (vmemmapcanoptimize(altmap, pgmap)) // does not sync top level page tables r = vmemmappopulatecompoundpages(pfn, start, end, nid, pgmap); else // sync top level page tables in x86 r = vmemmappopulate(start, end, nid, altmap);

In the normal path, vmemmappopulate() in arch/x86/mm/init64.c synchronizes the top level page table (See commit 9b861528a801 ("x86-64, mem: Update all PGDs for direct mapping and vmemmap mapping changes")) so that all tasks in the system can see the new vmemmap area.

However, when vmemmapcanoptimize() returns true, the optimized path skips synchronization of top-level page tables. This is because vmemmappopulatecompoundpages() is implemented in core MM code, which does not handle synchronization of the top-level page tables. Instead, the core MM has historically relied on each architecture to perform this synchronization manually.

We're not the first party to encounter a crash caused by not-sync'd top level page tables: earlier this year, Gwan-gyeong Mun attempted to address the issue [1] [2] after hitting a kernel panic when x86 code accessed the vmemmap area before the corresponding top-level entries were synced. At that time, the issue was believed to be triggered only when struct page was enlarged for debugging purposes, and the patch did not get further updates.

It turns out that current approach of relying on each arch to handle the page table sync manually is fragile because 1) it's easy to forget to sync the top level page table, and 2) it's also easy to overlook that the kernel should not access the vmemmap and direct mapping areas before the sync.

The solution: Make page table sync more code robust and harder to miss

To address this, Dave Hansen suggested [3] [4] introducing {pgd,p4d}populatekernel() for updating kernel portion of the page tables and allow each architecture to explicitly perform synchronization when installing top-level entries. With this approach, we no longer need to worry about missing the sync step, reducing the risk of future regressions.

The new interface reuses existing ARCHPAGETABLESYNCMASK, PGTBLPDMODIFIED and archsynckernelmappings() facility used by vmalloc and ioremap to synchronize page tables.

pgdpopulatekernel() looks like this: static inline void pgdpopulatekernel(unsigned long addr, pgdt pgd, p4dt p4d) { pgdpopulate(&initmm, pgd, p4d); if (ARCHPAGETABLESYNCMASK & PGTBLPGDMODIFIED) archsynckernelmappings(addr, addr); }

It is worth noting that vmalloc() and applytorange() carefully synchronizes page tables by calling pdalloctrack() and archsynckernelmappings(), and thus they are not affected by ---truncated---

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

ocfs2: prevent release journal inode after journal shutdown

Before calling ocfs2deleteosb(), ocfs2journalshutdown() has already been executed in ocfs2dismountvolume(), so osb->journal must be NULL. Therefore, the following calltrace will inevitably fail when it reaches jbd2journalreleasejbdinode().

ocfs2dismountvolume()-> ocfs2deleteosb()-> ocfs2freeslotinfo()-> ocfs2freeslotinfo()-> evict()-> ocfs2evictinode()-> ocfs2clearinode()-> jbd2journalreleasejbdinode(osb->journal->jjournal,

Adding osb->journal checks will prevent null-ptr-deref during the above execution path.

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

mm: /proc/pid/smapsrollup: fix no vma's null-deref

Commit 258f669e7e88 ("mm: /proc/pid/smapsrollup: convert to single value seqfile") introduced a null-deref if there are no vma's in the task in showsmapsrollup.

fs/smb: Fix inconsistent refcnt update

ftrace: Fix potential warning in traceprintkseq during ftracedump

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

sctp: initialize more fields in sctpv6fromsk()

syzbot found that sin6scopeid was not properly initialized, leading to undefined behavior.

Clear sin6scopeid and sin6flowinfo.

BUG: KMSAN: uninit-value in sctpv6cmpaddr+0x887/0x8c0 net/sctp/ipv6.c:649 sctpv6cmpaddr+0x887/0x8c0 net/sctp/ipv6.c:649 sctpinet6cmpaddr+0x4f2/0x510 net/sctp/ipv6.c:983 sctpbindaddrconflict+0x22a/0x3b0 net/sctp/bindaddr.c:390 sctpgetportlocal+0x21eb/0x2440 net/sctp/socket.c:8452 sctpgetport net/sctp/socket.c:8523 [inline] sctplistenstart net/sctp/socket.c:8567 [inline] sctpinetlisten+0x710/0xfd0 net/sctp/socket.c:8636 syslistensocket net/socket.c:1912 [inline] syslisten net/socket.c:1927 [inline] dosyslisten net/socket.c:1932 [inline] sesyslisten net/socket.c:1930 [inline] x64syslisten+0x343/0x4c0 net/socket.c:1930 x64syscall+0x271d/0x3e20 arch/x86/include/generated/asm/syscalls64.h:51 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xd9/0x210 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

Local variable addr.i.i created at: sctpgetport net/sctp/socket.c:8515 [inline] sctplistenstart net/sctp/socket.c:8567 [inline] sctpinetlisten+0x650/0xfd0 net/sctp/socket.c:8636 syslistensocket net/socket.c:1912 [inline] syslisten net/socket.c:1927 [inline] dosyslisten net/socket.c:1932 [inline] sesyslisten net/socket.c:1930 [inline] x64syslisten+0x343/0x4c0 net/socket.c:1930

HID: hid-ntrig: fix unable to handle page fault in ntrigreportversion()

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

net: macb: fix unregisternetdev call order in macbremove()

When removing a macb device, the driver calls phyexit() before unregisternetdev(). This leads to a WARN from kernfs:

------------[ cut here ]------------ kernfs: can not remove 'attacheddev', no directory WARNING: CPU: 1 PID: 27146 at fs/kernfs/dir.c:1683 Call trace: kernfsremovebynamens+0xd8/0xf0 sysfsremovelink+0x24/0x58 phydetach+0x5c/0x168 phydisconnect+0x4c/0x70 phylinkdisconnectphy+0x6c/0xc0 [phylink] macbclose+0x6c/0x170 [macb] ... macbremove+0x60/0x168 [macb] platformremove+0x5c/0x80 ...

The warning happens because the PHY is being exited while the netdev is still registered. The correct order is to unregister the netdev before shutting down the PHY and cleaning up the MDIO bus.

Fix this by moving unregisternetdev() ahead of phyexit() in macbremove().

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

usb: dwc3: Remove WARNON for device endpoint command timeouts

This commit addresses a rarely observed endpoint command timeout which causes kernel panic due to warn when 'paniconwarn' is enabled and unnecessary call trace prints when 'paniconwarn' is disabled. It is seen during fast software-controlled connect/disconnect testcases. The following is one such endpoint command timeout that we observed:

1. Connect ======= ->dwc3threadinterrupt ->dwc3ep0interrupt ->configfscompositesetup ->compositesetup ->usbepqueue ->dwc3gadgetep0queue ->dwc3gadgetep0queue ->dwc3ep0docontroldata ->dwc3sendgadgetepcmd

2. Disconnect ========== ->dwc3threadinterrupt ->dwc3gadgetdisconnectinterrupt ->dwc3ep0resetstate ->dwc3ep0endcontroldata ->dwc3sendgadgetepcmd

In the issue scenario, in Exynos platforms, we observed that control transfers for the previous connect have not yet been completed and end transfer command sent as a part of the disconnect sequence and processing of USBENDPOINTHALT feature request from the host timeout. This maybe an expected scenario since the controller is processing EP commands sent as a part of the previous connect. It maybe better to remove WARNON in all places where device endpoint commands are sent to avoid unnecessary kernel panic due to warn.

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

ARM: tegra: Use I/O memcpy to write to IRAM