The Linux Kernel, the operating system core itself.

Security Fix(es):

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

btrfs: zoned: fix use-after-free in dozonefinish()

Shinichiro reported the following use-after-free triggered by the device replace operation in fstests btrfs/070.

BTRFS info (device nullb1): scrub: finished on devid 1 with status: 0 ================================================================== BUG: KASAN: slab-use-after-free in dozonefinish+0x91a/0xb90 [btrfs] Read of size 8 at addr ffff8881543c8060 by task btrfs-cleaner/3494007

CPU: 0 PID: 3494007 Comm: btrfs-cleaner Tainted: G W 6.8.0-rc5-kts #1 Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020 Call Trace: <TASK> dumpstacklvl+0x5b/0x90 printreport+0xcf/0x670 ? _virtaddrvalid+0x200/0x3e0 kasanreport+0xd8/0x110 ? dozonefinish+0x91a/0xb90 [btrfs] ? dozonefinish+0x91a/0xb90 [btrfs] dozonefinish+0x91a/0xb90 [btrfs] btrfsdeleteunusedbgs+0x5e1/0x1750 [btrfs] ? _pfxbtrfsdeleteunusedbgs+0x10/0x10 [btrfs] ? btrfsputroot+0x2d/0x220 [btrfs] ? btrfscleanonedeletedsnapshot+0x299/0x430 [btrfs] cleanerkthread+0x21e/0x380 [btrfs] ? _pfxcleanerkthread+0x10/0x10 [btrfs] kthread+0x2e3/0x3c0 ? _pfxkthread+0x10/0x10 retfromfork+0x31/0x70 ? _pfxkthread+0x10/0x10 retfromforkasm+0x1b/0x30 </TASK>

Allocated by task 3493983: kasansavestack+0x33/0x60 kasansavetrack+0x14/0x30 _kasankmalloc+0xaa/0xb0 btrfsallocdevice+0xb3/0x4e0 [btrfs] devicelistadd.constprop.0+0x993/0x1630 [btrfs] btrfsscanonedevice+0x219/0x3d0 [btrfs] btrfscontrolioctl+0x26e/0x310 [btrfs] _x64sysioctl+0x134/0x1b0 dosyscall64+0x99/0x190 entrySYSCALL64afterhwframe+0x6e/0x76

Freed by task 3494056: kasansavestack+0x33/0x60 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3f/0x60 poisonslabobject+0x102/0x170 _kasanslabfree+0x32/0x70 kfree+0x11b/0x320 btrfsrmdevreplacefreesrcdev+0xca/0x280 [btrfs] btrfsdevreplacefinishing+0xd7e/0x14f0 [btrfs] btrfsdevreplacebyioctl+0x1286/0x25a0 [btrfs] btrfsioctl+0xb27/0x57d0 [btrfs] _x64sysioctl+0x134/0x1b0 dosyscall64+0x99/0x190 entrySYSCALL64afterhwframe+0x6e/0x76

The buggy address belongs to the object at ffff8881543c8000 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 96 bytes inside of freed 1024-byte region [ffff8881543c8000, ffff8881543c8400)

The buggy address belongs to the physical page: page:00000000fe2c1285 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1543c8 head:00000000fe2c1285 order:3 entiremapcount:0 nrpagesmapped:0 pincount:0 flags: 0x17ffffc0000840(slab|head|node=0|zone=2|lastcpupid=0x1fffff) pagetype: 0xffffffff() raw: 0017ffffc0000840 ffff888100042dc0 ffffea0019e8f200 dead000000000002 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffff8881543c7f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8881543c7f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff8881543c8000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881543c8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881543c8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

This UAF happens because we're accessing stale zone information of a already removed btrfsdevice in dozone_finish().

The sequence of events is as follows:

btrfsdevreplacestart btrfsscrubdev btrfsdevreplacefinishing btrfsdevreplaceupdatedeviceinmappingtree <-- devices replaced btrfsrmdevreplacefreesrcdev btrfsfreedevice <-- device freed

cleanerkthread btrfsdeleteunusedbgs btrfszonefinish dozonefinish <-- refers the freed device

The reason for this is that we're using a ---truncated---(CVE-2024-26944)

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

Bluetooth: HCI: Fix potential null-ptr-deref

Fix potential null-ptr-deref in hcilebigsyncestablished_evt().(CVE-2024-36011)

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

virtionet: Fix napiskbcacheput warning

After the commit bdacf3e34945 ("net: Use nested-BH locking for napialloccache.") was merged, the following warning began to appear:

 WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0

  __warn+0x12f/0x340
  napi_skb_cache_put+0x82/0x4b0
  napi_skb_cache_put+0x82/0x4b0
  report_bug+0x165/0x370
  handle_bug+0x3d/0x80
  exc_invalid_op+0x1a/0x50
  asm_exc_invalid_op+0x1a/0x20
  __free_old_xmit+0x1c8/0x510
  napi_skb_cache_put+0x82/0x4b0
  __free_old_xmit+0x1c8/0x510
  __free_old_xmit+0x1c8/0x510
  __pfx___free_old_xmit+0x10/0x10

The issue arises because virtio is assuming it's running in NAPI context even when it's not, such as in the netpoll case.

To resolve this, modify virtnetpolltx() to only set NAPI when budget is available. Same for virtnetpollcleantx(), which always assumed that it was in a NAPI context.(CVE-2024-43835)

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

wifi: mac80211: fix NULL dereference at band check in starting tx ba session

In MLD connection, linkdata/linkconf are dynamically allocated. They don't point to vif->bssconf. So, there will be no chanreq assigned to vif->bssconf and then the chan will be NULL. Tweak the code to check htsupported/vhtsupported/hashe/haseht on sta deflink.

Crash log (with rtw89 version under MLO development): [ 9890.526087] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 9890.526102] #PF: supervisor read access in kernel mode [ 9890.526105] #PF: errorcode(0x0000) - not-present page [ 9890.526109] PGD 0 P4D 0 [ 9890.526114] Oops: 0000 [#1] PREEMPT SMP PTI [ 9890.526119] CPU: 2 PID: 6367 Comm: kworker/u16:2 Kdump: loaded Tainted: G OE 6.9.0 #1 [ 9890.526123] Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB3WW (2.73 ) 11/28/2018 [ 9890.526126] Workqueue: phy2 rtw89corebawork [rtw89core] [ 9890.526203] RIP: 0010:ieee80211starttxba_session (net/mac80211/agg-tx.c:618 (discriminator 1)) mac80211 [ 9890.526279] Code: f7 e8 d5 93 3e ea 48 83 c4 28 89 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 49 8b 84 24 e0 f1 ff ff 48 8b 80 90 1b 00 00 <83> 38 03 0f 84 37 fe ff ff bb ea ff ff ff eb cc 49 8b 84 24 10 f3

All code

0: f7 e8 imul %eax 2: d5 (bad) 3: 93 xchg %eax,%ebx 4: 3e ea ds (bad) 6: 48 83 c4 28 add $0x28,%rsp a: 89 d8 mov %ebx,%eax c: 5b pop %rbx d: 41 5c pop %r12 f: 41 5d pop %r13 11: 41 5e pop %r14 13: 41 5f pop %r15 15: 5d pop %rbp 16: c3 retq 17: cc int3 18: cc int3 19: cc int3 1a: cc int3 1b: 49 8b 84 24 e0 f1 ff mov -0xe20(%r12),%rax 22: ff 23: 48 8b 80 90 1b 00 00 mov 0x1b90(%rax),%rax 2a:* 83 38 03 cmpl $0x3,(%rax) <-- trapping instruction 2d: 0f 84 37 fe ff ff je 0xfffffffffffffe6a 33: bb ea ff ff ff mov $0xffffffea,%ebx 38: eb cc jmp 0x6 3a: 49 rex.WB 3b: 8b .byte 0x8b 3c: 84 24 10 test %ah,(%rax,%rdx,1) 3f: f3 repz

Code starting with the faulting instruction

0: 83 38 03 cmpl $0x3,(%rax) 3: 0f 84 37 fe ff ff je 0xfffffffffffffe40 9: bb ea ff ff ff mov $0xffffffea,%ebx e: eb cc jmp 0xffffffffffffffdc 10: 49 rex.WB 11: 8b .byte 0x8b 12: 84 24 10 test %ah,(%rax,%rdx,1) 15: f3 repz [ 9890.526285] RSP: 0018:ffffb8db09013d68 EFLAGS: 00010246 [ 9890.526291] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9308e0d656c8 [ 9890.526295] RDX: 0000000000000000 RSI: ffffffffab99460b RDI: ffffffffab9a7685 [ 9890.526300] RBP: ffffb8db09013db8 R08: 0000000000000000 R09: 0000000000000873 [ 9890.526304] R10: ffff9308e0d64800 R11: 0000000000000002 R12: ffff9308e5ff6e70 [ 9890.526308] R13: ffff930952500e20 R14: ffff9309192a8c00 R15: 0000000000000000 [ 9890.526313] FS: 0000000000000000(0000) GS:ffff930b4e700000(0000) knlGS:0000000000000000 [ 9890.526316] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 9890.526318] CR2: 0000000000000000 CR3: 0000000391c58005 CR4: 00000000001706f0 [ 9890.526321] Call Trace: [ 9890.526324] <TASK> [ 9890.526327] ? showregs (arch/x86/kernel/dumpstack.c:479) [ 9890.526335] ? _die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 9890.526340] ? pagefaultoops (arch/x86/mm/fault.c:713) [ 9890.526347] ? searchmoduleextables (kernel/module/main.c:3256 (discriminator ---truncated---(CVE-2024-43911)

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

bonding: fix xfrm real_dev null pointer dereference

We shouldn't set realdev to NULL because packets can be in transit and xfrm might call xdodevoffloadok() in parallel. All callbacks assume real_dev is set.

Example trace: kernel: BUG: unable to handle page fault for address: 0000000000001030 kernel: bond0: (slave eni0np1): making interface the new active one kernel: #PF: supervisor write access in kernel mode kernel: #PF: errorcode(0x0002) - not-present page kernel: PGD 0 P4D 0 kernel: Oops: 0002 [#1] PREEMPT SMP kernel: CPU: 4 PID: 2237 Comm: ping Not tainted 6.7.7+ #12 kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 kernel: RIP: 0010:nsimipsecoffloadok+0xc/0x20 [netdevsim] kernel: bond0: (slave eni0np1): bondipsecaddsaall: failed to add SA kernel: Code: e0 0f 0b 48 83 7f 38 00 74 de 0f 0b 48 8b 47 08 48 8b 37 48 8b 78 40 e9 b2 e5 9a d7 66 90 0f 1f 44 00 00 48 8b 86 80 02 00 00 <83> 80 30 10 00 00 01 b8 01 00 00 00 c3 0f 1f 80 00 00 00 00 0f 1f kernel: bond0: (slave eni0np1): making interface the new active one kernel: RSP: 0018:ffffabde81553b98 EFLAGS: 00010246 kernel: bond0: (slave eni0np1): bondipsecaddsaall: failed to add SA kernel: kernel: RAX: 0000000000000000 RBX: ffff9eb404e74900 RCX: ffff9eb403d97c60 kernel: RDX: ffffffffc090de10 RSI: ffff9eb404e74900 RDI: ffff9eb3c5de9e00 kernel: RBP: ffff9eb3c0a42000 R08: 0000000000000010 R09: 0000000000000014 kernel: R10: 7974203030303030 R11: 3030303030303030 R12: 0000000000000000 kernel: R13: ffff9eb3c5de9e00 R14: ffffabde81553cc8 R15: ffff9eb404c53000 kernel: FS: 00007f2a77a3ad00(0000) GS:ffff9eb43bd00000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 0000000000001030 CR3: 00000001122ab000 CR4: 0000000000350ef0 kernel: bond0: (slave eni0np1): making interface the new active one kernel: Call Trace: kernel: <TASK> kernel: ? _die+0x1f/0x60 kernel: bond0: (slave eni0np1): bondipsecaddsaall: failed to add SA kernel: ? pagefaultoops+0x142/0x4c0 kernel: ? douseraddrfault+0x65/0x670 kernel: ? kvmreadandresetapfflags+0x3b/0x50 kernel: bond0: (slave eni0np1): making interface the new active one kernel: ? excpagefault+0x7b/0x180 kernel: ? asmexcpagefault+0x22/0x30 kernel: ? nsimbpfuninit+0x50/0x50 [netdevsim] kernel: bond0: (slave eni0np1): bondipsecaddsaall: failed to add SA kernel: ? nsimipsecoffloadok+0xc/0x20 [netdevsim] kernel: bond0: (slave eni0np1): making interface the new active one kernel: bondipsecoffloadok+0x7b/0x90 [bonding] kernel: xfrmoutput+0x61/0x3b0 kernel: bond0: (slave eni0np1): bondipsecaddsaall: failed to add SA kernel: ippushpendingframes+0x56/0x80(CVE-2024-44989)

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

igb: cope with large MAXSKBFRAGS

Sabrina reports that the igb driver does not cope well with large MAXSKBFRAG values: setting MAXSKBFRAG to 45 causes payload corruption on TX.

An easy reproducer is to run ssh to connect to the machine. With MAXSKBFRAGS=17 it works, with MAXSKBFRAGS=45 it fails. This has been reported originally in https://bugzilla.redhat.com/show_bug.cgi?id=2265320

The root cause of the issue is that the driver does not take into account properly the (possibly large) shared info size when selecting the ring layout, and will try to fit two packets inside the same 4K page even when the 1st fraglist will trump over the 2nd head.

Address the issue by checking if 2K buffers are insufficient.(CVE-2024-45030)

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

bonding: change ipsec_lock from spin lock to mutex

In the cited commit, bond->ipseclock is added to protect ipseclist, hence xdodevstateadd and xdodevstatedelete are called inside this lock. As ipsec_lock is a spin lock and such xfrmdev ops may sleep, "scheduling while atomic" will be triggered when changing bond's active slave.

[ 101.055189] BUG: scheduling while atomic: bash/902/0x00000200 [ 101.055726] Modules linked in: [ 101.058211] CPU: 3 PID: 902 Comm: bash Not tainted 6.9.0-rc4+ #1 [ 101.058760] Hardware name: [ 101.059434] Call Trace: [ 101.059436] <TASK> [ 101.060873] dumpstacklvl+0x51/0x60 [ 101.061275] _schedulebug+0x4e/0x60 [ 101.061682] _schedule+0x612/0x7c0 [ 101.062078] ? _modtimer+0x25c/0x370 [ 101.062486] schedule+0x25/0xd0 [ 101.062845] scheduletimeout+0x77/0xf0 [ 101.063265] ? asmcommoninterrupt+0x22/0x40 [ 101.063724] ? _bpftraceitimerstate+0x10/0x10 [ 101.064215] _waitforcommon+0x87/0x190 [ 101.064648] ? usleeprangestate+0x90/0x90 [ 101.065091] cmdexec+0x437/0xb20 [mlx5core] [ 101.065569] mlx5cmddo+0x1e/0x40 [mlx5core] [ 101.066051] mlx5cmdexec+0x18/0x30 [mlx5core] [ 101.066552] mlx5cryptocreatedekkey+0xea/0x120 [mlx5core] [ 101.067163] ? bondingsysfsstoreoption+0x4d/0x80 [bonding] [ 101.067738] ? kmalloctrace+0x4d/0x350 [ 101.068156] mlx5ipseccreatesactx+0x33/0x100 [mlx5core] [ 101.068747] mlx5exfrmaddstate+0x47b/0xaa0 [mlx5core] [ 101.069312] bondchangeactiveslave+0x392/0x900 [bonding] [ 101.069868] bondoptionactiveslaveset+0x1c2/0x240 [bonding] [ 101.070454] _bondoptset+0xa6/0x430 [bonding] [ 101.070935] _bondoptsetnotify+0x2f/0x90 [bonding] [ 101.071453] bondopttrysetrtnl+0x72/0xb0 [bonding] [ 101.071965] bondingsysfsstoreoption+0x4d/0x80 [bonding] [ 101.072567] kernfsfopwriteiter+0x10c/0x1a0 [ 101.073033] vfswrite+0x2d8/0x400 [ 101.073416] ? allocfd+0x48/0x180 [ 101.073798] ksyswrite+0x5f/0xe0 [ 101.074175] dosyscall64+0x52/0x110 [ 101.074576] entrySYSCALL64after_hwframe+0x4b/0x53

As bondipsecaddsaall and bondipsecdelsaall are only called from bondchangeactiveslave, which requires holding the RTNL lock. And bondipsecaddsa and bondipsecdelsa are xfrm state xdodevstateadd and xdodevstatedelete APIs, which are in user context. So ipseclock doesn't have to be spin lock, change it to mutex, and thus the above issue can be resolved.(CVE-2024-46678)

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

fou: Fix null-ptr-deref in GRO.

We observed a null-ptr-deref in fougroreceive() while shutting down a host. [0]

The NULL pointer is sk->skuserdata, and the offset 8 is of protocol in struct fou.

When fourelease() is called due to netns dismantle or explicit tunnel teardown, udptunnelsockrelease() sets NULL to sk->skuserdata. Then, the tunnel socket is destroyed after a single RCU grace period.

So, in-flight udp4groreceive() could find the socket and execute the FOU GRO handler, where sk->skuserdata could be NULL.

Let's use rcudereferenceskuserdata() in foufromsock() and add NULL checks in FOU GRO handlers.

PF: supervisor read access in kernel mode PF: errorcode(0x0000) - not-present page PGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0 SMP PTI CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x8664 #1 Hardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017 RIP: 0010:fougroreceive (net/ipv4/fou.c:233) [fou] Code: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 <0f> b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42 RSP: 0018:ffffa330c0003d08 EFLAGS: 00010297 RAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010 RDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08 RBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002 R10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400 R13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0 FS: 0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ? showtraceloglvl (arch/x86/kernel/dumpstack.c:259) ? _diebody.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420) ? nocontext (arch/x86/mm/fault.c:752) ? excpagefault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483) ? asmexcpagefault (arch/x86/include/asm/idtentry.h:571) ? fougroreceive (net/ipv4/fou.c:233) [fou] udpgroreceive (include/linux/netdevice.h:2552 net/ipv4/udpoffload.c:559) udp4groreceive (net/ipv4/udpoffload.c:604) inetgroreceive (net/ipv4/afinet.c:1549 (discriminator 7)) devgroreceive (net/core/dev.c:6035 (discriminator 4)) napigroreceive (net/core/dev.c:6170) enacleanrxirq (drivers/amazon/net/ena/enanetdev.c:1558) [ena] enaiopoll (drivers/amazon/net/ena/enanetdev.c:1742) [ena] napipoll (net/core/dev.c:6847) netrxaction (net/core/dev.c:6917) _dosoftirq (arch/x86/include/asm/jumplabel.h:25 include/linux/jumplabel.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299) asmcallirqonstack (arch/x86/entry/entry64.S:809) </IRQ> dosoftirqownstack (arch/x86/include/asm/irqstack.h:27 arch/x86/include/asm/irqstack.h:77 arch/x86/kernel/irq64.c:77) irqexitrcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435) commoninterrupt (arch/x86/kernel/irq.c:239) asmcommoninterrupt (arch/x86/include/asm/idtentry.h:626) RIP: 0010:acpiidledoentry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processoridle.c:114 drivers/acpi/processor_idle.c:575) Code: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 <fa> c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 RSP: 0018:ffffffffb5603e58 EFLAGS: 00000246 RAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900 RDX: ffff93daee800000 RSI: ffff93d ---truncated---(CVE-2024-46763)

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

tcpbpf: fix return value of tcpbpf_sendmsg()

When we cork messages in psock->cork, the last message triggers the flushing will result in sending a skmsg larger than the current message size. In this case, in tcpbpfsendverdict(), 'copied' becomes negative at least in the following case:

468 case _SKDROP: 469 default: 470 skmsgfreepartial(sk, msg, tosend); 471 skmsgapplybytes(psock, tosend); 472 *copied -= (tosend + delta); // <==== HERE 473 return -EACCES;

Therefore, it could lead to the following BUG with a proper value of 'copied' (thanks to syzbot). We should not use negative 'copied' as a return value here.

------------[ cut here ]------------ kernel BUG at net/socket.c:733! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 UID: 0 PID: 3265 Comm: syz-executor510 Not tainted 6.11.0-rc3-syzkaller-00060-gd07b43284ab3 #0 Hardware name: linux,dummy-virt (DT) pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : socksendmsgnosec net/socket.c:733 [inline] pc : socksendmsgnosec net/socket.c:728 [inline] pc : socksendmsg+0x5c/0x60 net/socket.c:745 lr : socksendmsgnosec net/socket.c:730 [inline] lr : _socksendmsg+0x54/0x60 net/socket.c:745 sp : ffff800088ea3b30 x29: ffff800088ea3b30 x28: fbf00000062bc900 x27: 0000000000000000 x26: ffff800088ea3bc0 x25: ffff800088ea3bc0 x24: 0000000000000000 x23: f9f00000048dc000 x22: 0000000000000000 x21: ffff800088ea3d90 x20: f9f00000048dc000 x19: ffff800088ea3d90 x18: 0000000000000001 x17: 0000000000000000 x16: 0000000000000000 x15: 000000002002ffaf x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: ffff8000815849c0 x9 : ffff8000815b49c0 x8 : 0000000000000000 x7 : 000000000000003f x6 : 0000000000000000 x5 : 00000000000007e0 x4 : fff07ffffd239000 x3 : fbf00000062bc900 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 00000000fffffdef Call trace: socksendmsgnosec net/socket.c:733 [inline] _socksendmsg+0x5c/0x60 net/socket.c:745 _syssendmsg+0x274/0x2ac net/socket.c:2597 _syssendmsg+0xac/0x100 net/socket.c:2651 _syssendmsg+0x84/0xe0 net/socket.c:2680 _dosyssendmsg net/socket.c:2689 [inline] _sesyssendmsg net/socket.c:2687 [inline] _arm64syssendmsg+0x24/0x30 net/socket.c:2687 _invokesyscall arch/arm64/kernel/syscall.c:35 [inline] invokesyscall+0x48/0x110 arch/arm64/kernel/syscall.c:49 el0svccommon.constprop.0+0x40/0xe0 arch/arm64/kernel/syscall.c:132 doel0svc+0x1c/0x28 arch/arm64/kernel/syscall.c:151 el0svc+0x34/0xec arch/arm64/kernel/entry-common.c:712 el0t64synchandler+0x100/0x12c arch/arm64/kernel/entry-common.c:730 el0t64sync+0x19c/0x1a0 arch/arm64/kernel/entry.S:598 Code: f9404463 d63f0060 3108441f 54fffe81 (d4210000) ---[ end trace 0000000000000000 ]---(CVE-2024-46783)

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

drm/amdgpu: Fix smatch static checker warning

adev->gfx.imu.funcs could be NULL(CVE-2024-46835)

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

scsi: pm80xx: Set phy->enable_completion only when we wait for it

pm8001phycontrol() populates the enablecompletion pointer with a stack address, sends a PHYLINKRESET / PHYHARDRESET, waits 300 ms, and returns. The problem arises when a phy control response comes late. After 300 ms the pm8001phycontrol() function returns and the passed enablecompletion stack address is no longer valid. Late phy control response invokes complete() on a dangling enable_completion pointer which leads to a kernel crash.(CVE-2024-47666)

In the Linux kernel, the following vulnerability has been resolved: mm: avoid leaving partial pfn mappings around in error case As Jann points out, PFN mappings are special, because unlike normal memory mappings, there is no lifetime information associated with the mapping - it is just a raw mapping of PFNs with no reference counting of a 'struct page'. That's all very much intentional, but it does mean that it's easy to mess up the cleanup in case of errors. Yes, a failed mmap() will always eventually clean up any partial mappings, but without any explicit lifetime in the page table mapping itself, it's very easy to do the error handling in the wrong order. In particular, it's easy to mistakenly free the physical backing store before the page tables are actually cleaned up and (temporarily) have stale dangling PTE entries. To make this situation less error-prone, just make sure that any partial pfn mapping is torn down early, before any other error handling.(CVE-2024-47674)

In the Linux kernel, the following vulnerability has been resolved: jfs: fix out-of-bounds in dbNextAG() and diAlloc() In dbNextAG() , there is no check for the case where bmp->dbnumag is greater or same than MAXAG due to a polluted image, which causes an out-of-bounds. Therefore, a bounds check should be added in dbMount(). And in dbNextAG(), a check for the case where agpref is greater than bmp->dbnumag should be added, so an out-of-bounds exception should be prevented. Additionally, a check for the case where agno is greater or same than MAXAG should be added in diAlloc() to prevent out-of-bounds.(CVE-2024-47723)

In the Linux kernel, the following vulnerability has been resolved: bpf: Zero former ARGPTRTO{LONG,INT} args in case of error For all non-tracing helpers which formerly had ARGPTRTO{LONG,INT} as input arguments, zero the value for the case of an error as otherwise it could leak memory. For tracing, it is not needed given CAPPERFMON can already read all kernel memory anyway hence bpfgetfuncarg() and bpfgetfuncret() is skipped in here. Also, the MTU helpers mtulen pointer value is being written but also read. Technically, the MEMUNINIT should not be there in order to always force init. Removing MEMUNINIT needs more verifier rework though: MEMUNINIT right now implies two things actually: i) write into memory, ii) memory does not have to be initialized. If we lift MEMUNINIT, it then becomes: i) read into memory, ii) memory must be initialized. This means that for bpf*checkmtu() we're readding the issue we're trying to fix, that is, it would then be able to write back into things like .rodata BPF maps. Follow-up work will rework the MEMUNINIT semantics such that the intent can be better expressed. For now just clear the *mtu_len on error path which can be lifted later again.(CVE-2024-47728)

In the Linux kernel, the following vulnerability has been resolved: net/ncsi: Disable the ncsi work before freeing the associated structure The work function can run after the ncsi device is freed, resulting in use-after-free bugs or kernel panic.(CVE-2024-49945)

In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Fix ERRPTR dereference in uvcv4l2.c Fix potential dereferencing of ERRPTR() in findformatbypix() and uvcv4l2enumformat(). Fix the following smatch errors: drivers/usb/gadget/function/uvcv4l2.c:124 findformatbypix() error: 'fmtdesc' dereferencing possible ERRPTR() drivers/usb/gadget/function/uvcv4l2.c:392 uvcv4l2enumformat() error: 'fmtdesc' dereferencing possible ERRPTR() Also, fix similar issue in uvcv4l2tryformat() for potential dereferencing of ERR_PTR().(CVE-2024-50056)

In the Linux kernel, the following vulnerability has been resolved: i3c: master: cdns: Fix use after free vulnerability in cdnsi3cmaster Driver Due to Race Condition In the cdnsi3cmasterprobe function, &master->hjwork is bound with cdnsi3cmasterhj. And cdnsi3cmasterinterrupt can call cndsi3cmasterdemuxibis function to start the work. If we remove the module which will call cdnsi3cmasterremove to make cleanup, it will free master->base through i3cmasterunregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | cdnsi3cmasterhj cdnsi3cmasterremove | i3cmasterunregister(&master->base) | deviceunregister(&master->dev) | devicerelease | //free master->base | | i3cmasterdodaa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in cdnsi3cmaster_remove.(CVE-2024-50061)

In the Linux kernel, the following vulnerability has been resolved: unicode: Don't special case ignorable code points We don't need to handle them separately. Instead, just let them decompose/casefold to themselves.(CVE-2024-50089)

In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Remove broken LDR (literal) uprobe support The simulateldrliteral() and simulateldrswliteral() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory. There are three key problems: 1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()). 2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulateldrliteral() nor simulateldrswliteral() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN. 3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers. Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes. Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulateldrliteral() and simulateldrswliteral() to kprobes. Attempts to place uprobes on LDR (literal) and LDRSW (literal) will be rejected as armprobedecodeinsn() will return INSNREJECTED. In future we can consider introducing working uprobes support for these instructions, but this will require more significant work.(CVE-2024-50099)

In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits 4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn't enforce 32-byte alignment of nCR3. In the absolute worst case scenario, failure to ignore bits 4:0 can result in an out-of-bounds read, e.g. if the target page is at the end of a memslot, and the VMM isn't using guard pages. Per the APM: The CR3 register points to the base address of the page-directory-pointer table. The page-directory-pointer table is aligned on a 32-byte boundary, with the low 5 address bits 4:0 assumed to be 0. And the SDM's much more explicit: 4:0 Ignored Note, KVM gets this right when loading PDPTRs, it's only the nSVM flow that is broken.(CVE-2024-50115)

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix UAF on isosocktimeout conn->sk maybe have been unlinked/freed while waiting for isoconnlock so this checks if the conn->sk is still valid by checking if it part of isosklist.(CVE-2024-50124)

In the Linux kernel, the following vulnerability has been resolved: bpf: Use rawspinlockt in ringbuf The function _bpfringbufreserve is invoked from a tracepoint, which disables preemption. Using spinlockt in this context can lead to a "sleep in atomic" warning in the RT variant. This issue is illustrated in the example below: BUG: sleeping function called from invalid context at kernel/locking/spinlockrt.c:48 inatomic(): 1, irqsdisabled(): 0, nonblock: 0, pid: 556208, name: testprogs preemptcount: 1, expected: 0 RCU nest depth: 1, expected: 1 INFO: lockdep is turned off. Preemption disabled at: [<ffffd33a5c88ea44>] migrateenable+0xc0/0x39c CPU: 7 PID: 556208 Comm: testprogs Tainted: G Hardware name: Qualcomm SA8775P Ride (DT) Call trace: dumpbacktrace+0xac/0x130 showstack+0x1c/0x30 dumpstacklvl+0xac/0xe8 dumpstack+0x18/0x30 _mightresched+0x3bc/0x4fc rtspinlock+0x8c/0x1a4 _bpfringbufreserve+0xc4/0x254 bpfringbufreservedynptr+0x5c/0xdc bpfprogac3d15160d62622atestreadwrite+0x104/0x238 tracecallbpf+0x238/0x774 perfcallbpfenter.isra.0+0x104/0x194 perfsyscallenter+0x2f8/0x510 tracesysenter+0x39c/0x564 syscalltraceenter+0x220/0x3c0 doel0svc+0x138/0x1dc el0svc+0x54/0x130 el0t64synchandler+0x134/0x150 el0t64sync+0x17c/0x180 Switch the spinlock to rawspinlock_t to avoid this error.(CVE-2024-50138)

(CVE-2024-50151)

In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix null-ptr-deref in targetallocdevice() There is a null-ptr-deref issue reported by KASAN: BUG: KASAN: null-ptr-deref in targetallocdevice+0xbc4/0xbe0 [targetcoremod] ... kasanreport+0xb9/0xf0 targetallocdevice+0xbc4/0xbe0 [targetcoremod] coredevsetupvirtuallun0+0xef/0x1f0 [targetcoremod] targetcoreinitconfigfs+0x205/0x420 [targetcoremod] dooneinitcall+0xdd/0x4e0 ... entrySYSCALL64afterhwframe+0x76/0x7e In targetallocdevice(), if allocing memory for dev queues fails, then dev will be freed by dev->transport->freedevice(), but dev->transport is not initialized at that time, which will lead to a null pointer reference problem. Fixing this bug by freeing dev with hba->backend->ops->freedevice().(CVE-2024-50153)

In the Linux kernel, the following vulnerability has been resolved: fbdev: sisfb: Fix strbuf array overflow The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, "%ux%ux8", xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50180)

In the Linux kernel, the following vulnerability has been resolved: x86/entry32: Clear CPU buffers after register restore in NMI return CPU buffers are currently cleared after call to excnmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don't have any sensitive data. Move CLEARCPUBUFFERS after RESTOREALLNMI.(CVE-2024-50193)

In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6030: fix IIO device retrieval from embedded device The dev pointer that is received as an argument in the inilluminanceperiodavailableshow function references the device embedded in the IIO device, not in the i2c client. devtoiiodev() must be used to accessthe right data. The current implementation leads to a segmentation fault on every attempt to read the attribute because indiodev gets a NULL assignment. This bug has been present since the first appearance of the driver, apparently since the last version (V6) before getting applied. A constant attribute was used until then, and the last modifications might have not been tested again.(CVE-2024-50198)

In the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfsfindentry() Syzbot reported that a task hang occurs in vcsopen() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfsfindentry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfsgetfolio() fails. If the filesystem images is corrupted, and the isize of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfscheckfolio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfsfindentry(). The current interface of nilfsfindentry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfsfindentry(), so fix it together.(CVE-2024-50202)

In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: assign dhkey to NULL after kfreesensitive ctrl->dhkey might be used across multiple calls to nvmetsetupdhgroup() for the same controller. So it's better to nullify it after release on error path in order to avoid double free later in nvmetdestroy_auth(). Found by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-50215)

In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data(CVE-2024-50237)

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ntfsfilerelease(CVE-2024-50242)

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix general protection fault in runismappedfull Fixed deleating of a non-resident attribute in ntfscreate_inode() rollback.(CVE-2024-50243)

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in niclear() Checking of NTFSFLAGSLOGREPLAYING added to prevent access to uninitialized bitmap during replay process.(CVE-2024-50244)

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix possible deadlock in miread Mutex lock with another subclass used in nilock_dir().(CVE-2024-50245)

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add rough attr alloc_size check(CVE-2024-50246)

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check if more than chunk-size bytes are written A incorrectly formatted chunk may decompress into more than LZNTCHUNKSIZE bytes and a index out of bounds will occur in smaxoff.(CVE-2024-50247)

In the Linux kernel, the following vulnerability has been resolved: fsdax: daxunshareiter needs to copy entire blocks The code that copies data from srcmap to iomap in daxunshareiter is very very broken, which bfoster's recent fsx changes have exposed. If the pos and len passed to daxfileunshare are not aligned to an fsblock boundary, the iter pos and length in the iter function will reflect this unalignment. daxiomapdirectaccess always returns a pointer to the start of the kmapped fsdax page, even if its pos argument is in the middle of that page. This is catastrophic for data integrity when iter->pos is not aligned to a page, because daddr/saddr do not point to the same byte in the file as iter->pos. Hence we corrupt user data by copying it to the wrong place. If iter->pos + iomaplength() in the _iter function not aligned to a page, then we fail to copy a full block, and only partially populate the destination block. This is catastrophic for data confidentiality because we expose stale pmem contents. Fix both of these issues by aligning copypos/copylen to a page boundary (remember, this is fsdax so 1 fsblock == 1 base page) so that we always copy full blocks. We're not done yet -- there's no call to invalidateinodepages2range, so programs that have the file range mmap'd will continue accessing the old memory mapping after the file metadata updates have completed. Be careful with the return value -- if the unshare succeeds, we still need to return the number of bytes that the iomap iter thinks we're operating on.(CVE-2024-50250)